samba - Sep 2011 - Recommended configuration for AD forest with child domains

Greetings,

I have had Samba/Winbind/Kerberos single-sign-on authentication working
for a few years now, for a single domain, and it works great.  It pulls
the RFC2307 populated attributes just like you'd expect, and people get
the IDs mapped according to their attributes in AD.

This works for version 3.2.7 and 3.4.3.  I had to give the domain's
Domain Users group a gid in the range of the idmap config range in order
for it to work in 3.4.3 because for some unexplained reason, you have to
be a member of domain users in order for winbind to even look at your
rfc2307 attributes, but that's another complaint/bug/"feature."

I have tried it with 3.5x and 3.6.0, and can't get it to work no matter
how I tweak smb.conf.  

I am in a multi-domain AD forest, in a child domain.  I need to be able
to give the same single sign-on access to people that live in the parent
domain as well as the peer domain, and since AD has the whole transitive
trust thing, there should be no trust issues.

I can list all of the users in each domain and all of the groups in each
domain, by issuing wbinfo -u or wbinfo -g, so Winbind, through whatever
mechanism it uses, can see all of them.  

However, to look at the RFC2307 attributes to determine whether or not
they should be enumerated with getent group or getent passwd, it appears
the idmap_ad process uses LDAP lookup on the authentication server to
find whether the rfc2307 attributes have been populated.  I don't know
if this is the problem or not, but some observations:

LDAP access to AD, when done on the LDAP port 389, will automatically
set the search base to the domain.  This precludes any lookup of people
not in that domain.

The lookup that is done is done against whatever AD server answers the
knock on the door, whether it has a replica of the Global Catalog or
not, so if by luck of the draw your domain's Infrastructure master is
used as the authentication server, there's no GC to look against, even
if Winbind didn't default to port 389 and looked at port 3268 (the GC
port) to do its idmap lookup.  

So, given those observations, exactly how would someone configure
Samba/Winbind to do SSO authentication using AD RFC2307 in a
multi-domain parent/child domain AD forest such that you could have
people authenticating from the Samba server's domain as well as the
other trusted domains in the forest?

I have made sure that the GC included attributes have the necessary
RFC2307 attributes included.  They're not by default so you have to make
sure they do get populated into the GC (at least according to the
idmap_adex man page)

Speaking of which, I tried using idmap_adex with 3.5x and 3.6.0, but
although the users/groups enumerate just fine with wbinfo, I am not
getting any idmapping through NSS.  I have seen comments that
idmap_adex' features were being rolled into idmap_ad (no need to have
more than one idmap for a given infrastructure) but no word as to when
that will happen for Samba 3, if at all, or what us poor
multi-domain-forest suckers like me are supposed to do in the meantime.

Thanks,

Jim.



This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the sender and delete it.
Please note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of the company.
No employee or agent is authorized to conclude any binding agreement on behalf
of?Visa Lighting with another party by email without express written
confirmation by?an authorized representative of the Company.
Finally, the recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage caused by
any virus transmitted by this email.

2011-09-16 21:21 keltez?ssel, Jim Stalewski ?rta:
> Greetings,
>
> I have had Samba/Winbind/Kerberos single-sign-on authentication working
> for a few years now, for a single domain, and it works great.  It pulls
> the RFC2307 populated attributes just like you'd expect, and people get
> the IDs mapped according to their attributes in AD.
>
> This works for version 3.2.7 and 3.4.3.  I had to give the domain's
> Domain Users group a gid in the range of the idmap config range in order
> for it to work in 3.4.3 because for some unexplained reason, you have to
> be a member of domain users in order for winbind to even look at your
> rfc2307 attributes, but that's another
complaint/bug/"feature."
>
> I have tried it with 3.5x and 3.6.0, and can't get it to work no matter
> how I tweak smb.conf.  
>
> I am in a multi-domain AD forest, in a child domain.  I need to be able
> to give the same single sign-on access to people that live in the parent
> domain as well as the peer domain, and since AD has the whole transitive
> trust thing, there should be no trust issues.
>
> I can list all of the users in each domain and all of the groups in each
> domain, by issuing wbinfo -u or wbinfo -g, so Winbind, through whatever
> mechanism it uses, can see all of them.  
>
> However, to look at the RFC2307 attributes to determine whether or not
> they should be enumerated with getent group or getent passwd, it appears
> the idmap_ad process uses LDAP lookup on the authentication server to
> find whether the rfc2307 attributes have been populated.  I don't know
> if this is the problem or not, but some observations:
>
> LDAP access to AD, when done on the LDAP port 389, will automatically
> set the search base to the domain.  This precludes any lookup of people
> not in that domain.
>
> The lookup that is done is done against whatever AD server answers the
> knock on the door, whether it has a replica of the Global Catalog or
> not, so if by luck of the draw your domain's Infrastructure master is
> used as the authentication server, there's no GC to look against, even
> if Winbind didn't default to port 389 and looked at port 3268 (the GC
> port) to do its idmap lookup.  
>
> So, given those observations, exactly how would someone configure
> Samba/Winbind to do SSO authentication using AD RFC2307 in a
> multi-domain parent/child domain AD forest such that you could have
> people authenticating from the Samba server's domain as well as the
> other trusted domains in the forest?
>
> I have made sure that the GC included attributes have the necessary
> RFC2307 attributes included.  They're not by default so you have to
make
> sure they do get populated into the GC (at least according to the
> idmap_adex man page)
>
> Speaking of which, I tried using idmap_adex with 3.5x and 3.6.0, but
> although the users/groups enumerate just fine with wbinfo, I am not
> getting any idmapping through NSS.  I have seen comments that
> idmap_adex' features were being rolled into idmap_ad (no need to have
> more than one idmap for a given infrastructure) but no word as to when
> that will happen for Samba 3, if at all, or what us poor
> multi-domain-forest suckers like me are supposed to do in the meantime.
>
> Thanks,
>
> Jim.
>
>
>
> This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the sender and delete it.
Please note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of the company.
> No employee or agent is authorized to conclude any binding agreement on
behalf of Visa Lighting with another party by email without express written
confirmation by an authorized representative of the Company.
> Finally, the recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage caused by
any virus transmitted by this email.
>
>
>
You could try to switch to idmap_adex which was created explicitly to
answer the multidomain forest problem. Please read
http://www.samba.org/samba/docs/man/manpages-3/idmap_adex.8.html before
trying to deploy as it needs schema modifications for AD: "Note that you
must add the uidNumber, gidNumber, and uid attributes to the partial
attribute set of the forest global catalog servers. This can be done
using the Active Directory Schema Management MMC plugin (schmmgmt.dll).".

Good Luck!

Geza