[Samba] change in AD authentication behaviour since 3.0.24
Neal A. Lucier
nlucier at math.purdue.edu
Thu Feb 21 00:06:50 GMT 2008
Robert Cohen wrote:
> On 20/2/08 4:11 PM, "Neal A. Lucier" <nlucier at math.purdue.edu> wrote:
>>Robert Cohen wrote:
> Ok, I thought winbind was only relevant if you were using AD as a NSS (name
> service source). We have all the users in the name service from LDAP or
> NIS+. We're only getting the passwords from AD.
> I guess this could be an unusual combination and could be whats causing our
This is exactly what we are doing, and until 3.0.25 setting up idmap to work in
this environment was a bit convoluted, but now it is extremely simple, mainly
because an "nss" backend was introduced to idmap. Generally speaking idmap is
for authorization; however, there is some interplay with authentication.
So, to be clear, your nsswitch on the machine is only look at LDAP or NIS+, and
in AD you have all the same users with the same username?
You need IDmap to map the uid of the owner of the files (which is coming from
LDAP/NIS+) to the SID of the user that is accessing via Samba (which is coming
from AD). There are many ways to do this, by putting the SID in LDAP, the uid
in AD, using local .tdb files, or a local mapping. The simpliest (given that my
assumptions about your environment are correct) is:
winbind use default domain = yes
idmap domains = XX
idmap config XX:backend = nss
idmap config XX:readonly = yes
idmap config XX:default = no
The only setting I'm not sure exactly what is does is the ":default = no", but
IIRC that says if someone from another domain that is not defined by "idmap
domains = " tries to connect than idmap should not use this backend as the
> And allow trusted domains = no doesn't make any difference.
Sorry, I was thinking of "winbind trusted domains only" which has been obsoleted
by the idmap_nss backend.
More information about the samba