Created attachment 4111 [details]
Full logs and config of the reported issue.

Also tracked at https://bugzilla.samba.org/show_bug.cgi?id=6322

You have the string NT_STXXUS_MEDIA_WRITE_PROTECTED in your logfile. This is definitely not upstream Samba, I don't see where this could come from in Samba. Please contact your vendor for the patches.

Thanks,

Volker

That's NT_STATUS_MEDIA_WRITE_PROTECTED, not NT_STXXUS_MEDIA_WRITE_PROTECTED

The XX is an artifact of
  sed -i 's/AT/XX/g' *
which I did to fuzz the domain name, where the last component is AT. My bad.

However, that does not explain why it does work with samba 3.2.3. 

Right, currently the AD backend does only work properly when
configured with an explicit domain configuration like this:

idmap config DOMAIN : backend = ad
idmap config DOMAIN : range = 10000-49999
idmap config DOMAIN : schema_mode = rfc2307

with default config using the tdb backend as a fallback
for other domains like BUILTIN and trusted, e.g.:

idmap backend = tdb
idmap uid = 50000-99999
idmap gid = 50000-99999

I am afraid this is not properly documented so this can be
considered a bug in the man pages. And of course it is a feature
lacking from the idmap_ad module, that it can not be run as the
default idmap backend. This is due to the internal structure of
the idmap_ad connection manager and the way the idmap code handles
the default domain. I had the plan of extending this, so that
idmap_ad could also be used as default backend, but I did not find
the time yet.

Strangely, Günther Deschner has reportet a setup like this to
be working (idmap_ad as default). Putting Günther on cc...

Michael Adam's solution works, thanks. 

I tried adding a writable backend before, but apparently didn't get the details right. Before, it would allocate new (and incorrect) mappings in the tdb backend, instead of resolving the mappings from AD. 

I'm not totally sure in how far Michael Adam's configuration differs from what I've tried. Apparently I missed the part about the ranges, which have to be mutually exclusive. I think I left the ranges as they were in the old configuration and assumed winbind would know what to do. I used to think of the ranges more as a hint to winbind, since the uids and gids are already fixed in the AD leaving winbind exactly zero choice.

I suggest adding a notice to the manpage "idmap_ad", along the lines of:
"Note: The configuration of idmap_ad have changed considerably since the Samba 3.2. Idmap_ad now *requires* an additional, writable idmap-backend. See the examples-section below. The UID-ranges assigned to idmap_ad must be disjoint of the ragnes assigned to the writable backend."

(In reply to comment #6)
> Michael Adam's solution works, thanks. 

Thanks for the feedback.

> I tried adding a writable backend before, but apparently didn't get the details
> right. Before, it would allocate new (and incorrect) mappings in the tdb
> backend, instead of resolving the mappings from AD. 
> 
> I'm not totally sure in how far Michael Adam's configuration differs from what
> I've tried. Apparently I missed the part about the ranges, which have to be
> mutually exclusive. I think I left the ranges as they were in the old
> configuration and assumed winbind would know what to do. I used to think of the
> ranges more as a hint to winbind, since the uids and gids are already fixed in
> the AD leaving winbind exactly zero choice.
> 
> I suggest adding a notice to the manpage "idmap_ad", along the lines of:
> "Note: The configuration of idmap_ad have changed considerably since the Samba
> 3.2. Idmap_ad now *requires* an additional, writable idmap-backend. See the
> examples-section below. The UID-ranges assigned to idmap_ad must be disjoint of
> the ragnes assigned to the writable backend."

Thanks for the suggestion, too.
It is right that we should make this more clear in the docs.

Should we make this doc-request a real bug?

Michael

Created attachment 6123 [details]
manpage update for idmap_ad

I pushed this manpage update to idmap_ad to master and v3-6-test.
Should we add it to 3.5.7, too?

There seems to be one more change in 3.5.x idmap, which should be changed or at least documented:

The mapping seems to work only if the primary windows group of the account has unix attributes.

We synchronize our accounts from a novell edirectory to AD.

Most of the users have the gidNumber 10000 (group campususer) as primary unix group

The driver makes them to member and primary group of "Domain Users" which has no unix attributes.

Then for example "wbinfo -i" returns:

[root@z-sv-test samba]# wbinfo -i AD\\pcadmin
Could not get info for user AD\pcadmin
[root@z-sv-test samba]# 


If we add campususer (which has unix attributes) as the  primary group to a user, wbinfo then works:

[root@z-sv-test samba]# wbinfo -i AD\\Guinea.Pig
AD\guinea.pig:*:10007:10000:Guinea Pig:/home/g/Guinea.Pig:/bin/bash
[root@z-sv-test samba]#


This is definitly a different behavior to samba up until 3.4.x, where idmapping just took the gidnumber attribute of the user (and not the primary windows group).

There seems to be another change in 3.5.x idmap, which breaks getent behavior:

'getent group' & 'getent passwd' --> only shows local groups and local users.

root@co5itis01:~ # getent passwd domainuser

--> shows correct entry for this domainuser.

root@co5itis01:~ # getent group domaingroup

--> shows also correct domaingroup info.

wbinfo resolves everything correctly.

Seems to be broken since 3.5.x.

Michael: does comment 9 need to be documented or is this unintended behaviour?

Michael, there is bug #8694, which is about the comment #9 case. I'll close this one, hope that's okay.