Hello,
is it possible to create an Active Directory forest with multible subdomains and make those informations available for one Linux machine? Right now, we have one domain and it is possible to do authentication against the Active Directory, while using OpenLDAP, PAM and Kerberos.
But now, another department would like to have its own directory/sub-domain. This means: uid=xyz will be located on different directory servers within the Active Directory forest. That means, there are UIDs with different BASEDNs.
CN=userA,OU=Users,DC=example,DC=local from AD1 and CN=userB,OU=Users,DC=sub,DC=example,DC=local from AD2 shall both be able to access a Linux box via SSH. No problem?
Regards, Aiko
Aiko Barz wrote:
Hello,
is it possible to create an Active Directory forest with multible subdomains and make those informations available for one Linux machine? Right now, we have one domain and it is possible to do authentication against the Active Directory, while using OpenLDAP, PAM and Kerberos.
But now, another department would like to have its own directory/sub-domain. This means: uid=xyz will be located on different directory servers within the Active Directory forest. That means, there are UIDs with different BASEDNs.
CN=userA,OU=Users,DC=example,DC=local from AD1 and CN=userB,OU=Users,DC=sub,DC=example,DC=local from AD2 shall both be able to access a Linux box via SSH. No problem?
Regards, Aiko
There's nothing in OpenLDAP that would prevent this. This is a question more suited to either the pam_ldap or nss_ldap mailing lists. The only problem is you might have cn=userA representing two different users in both domains at once, and you'll have to have some kind of policy for dealing with those situations.
On Tue, 2008-01-22 at 01:14 -0800, Howard Chu wrote:
Aiko Barz wrote:
Hello,
is it possible to create an Active Directory forest with multible subdomains and make those informations available for one Linux machine? Right now, we have one domain and it is possible to do authentication against the Active Directory, while using OpenLDAP, PAM and Kerberos.
But now, another department would like to have its own directory/sub-domain. This means: uid=xyz will be located on different directory servers within the Active Directory forest. That means, there are UIDs with different BASEDNs.
CN=userA,OU=Users,DC=example,DC=local from AD1 and CN=userB,OU=Users,DC=sub,DC=example,DC=local from AD2 shall both be able to access a Linux box via SSH. No problem?
Regards, Aiko
There's nothing in OpenLDAP that would prevent this. This is a question more suited to either the pam_ldap or nss_ldap mailing lists. The only problem is you might have cn=userA representing two different users in both domains at once, and you'll have to have some kind of policy for dealing with those situations.
This is really the kind of thing that Samba and winbind does best. Winbind understands the topology, and creates accounts like AD1\userA and AD2\userB so that there is no possibility of conflict.
Andrew Bartlett
On Tuesday 22 January 2008 22:38:13 Andrew Bartlett wrote:
On Tue, 2008-01-22 at 01:14 -0800, Howard Chu wrote:
There's nothing in OpenLDAP that would prevent this. This is a question more suited to either the pam_ldap or nss_ldap mailing lists. The only problem is you might have cn=userA representing two different users in both domains at once, and you'll have to have some kind of policy for dealing with those situations.
This is really the kind of thing that Samba and winbind does best. Winbind understands the topology, and creates accounts like AD1\userA and AD2\userB so that there is no possibility of conflict.
And it's a band-aid over the fact that there is no standard for multi-realm user identification under Unix.
Regards, Buchan
Buchan Milne wrote:
On Tuesday 22 January 2008 22:38:13 Andrew Bartlett wrote:
On Tue, 2008-01-22 at 01:14 -0800, Howard Chu wrote:
There's nothing in OpenLDAP that would prevent this. This is a question more suited to either the pam_ldap or nss_ldap mailing lists. The only problem is you might have cn=userA representing two different users in both domains at once, and you'll have to have some kind of policy for dealing with those situations.
This is really the kind of thing that Samba and winbind does best. Winbind understands the topology, and creates accounts like AD1\userA and AD2\userB so that there is no possibility of conflict.
And it's a band-aid over the fact that there is no standard for multi-realm user identification under Unix.
Not for lack of trying... Kerberos, AFS, DCE ... I think it's somewhat ironic that Windows today is built around a technology (DCE) that was developed for and forgotten by the Unix world a decade ago. (Particularly since I was one of the guys who first implemented DCE/DFS support on Windows95 way back when.) Talk about coming full circle.
On Tue, Jan 22, 2008 at 01:14:47AM -0800, Howard Chu wrote:
Aiko Barz wrote:
Hello,
is it possible to create an Active Directory forest with multible subdomains and make those informations available for one Linux machine? Right now, we have one domain and it is possible to do authentication against the Active Directory, while using OpenLDAP, PAM and Kerberos.
There's nothing in OpenLDAP that would prevent this. This is a question more suited to either the pam_ldap or nss_ldap mailing lists. The only problem is you might have cn=userA representing two different users in both domains at once, and you'll have to have some kind of policy for dealing with those situations.
Hello,
I was testing a subdomain configuration and I wondered: What happened to the -C switch? And will there be support for following referrals with credentials?
Debian/Testing:
$ ldapsearch -h 2>&1| grep "-C" | wc -l 0
$ ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.7 (Jan 22 2008 00:11:57) $ buildd@ninsei:/build/buildd/openldap2.3-2.4.7/debian/build/clients/tools (LDAP library: OpenLDAP 20407)
So long, Aiko
Aiko Barz wrote:
On Tue, Jan 22, 2008 at 01:14:47AM -0800, Howard Chu wrote:
Aiko Barz wrote:
Hello,
is it possible to create an Active Directory forest with multible subdomains and make those informations available for one Linux machine? Right now, we have one domain and it is possible to do authentication against the Active Directory, while using OpenLDAP, PAM and Kerberos.
There's nothing in OpenLDAP that would prevent this. This is a question more suited to either the pam_ldap or nss_ldap mailing lists. The only problem is you might have cn=userA representing two different users in both domains at once, and you'll have to have some kind of policy for dealing with those situations.
Hello,
I was testing a subdomain configuration and I wondered: What happened to the -C switch? And will there be support for following referrals with credentials?
Doing so is a security vulnerability, so that support was dropped from all of the bundled tools quite a long time ago. Referrals in general are a stupid, poorly designed, insecure feature of LDAP which is why OpenLDAP provides so many secure alternatives to them (chaining, glued back-ldap, etc.).
Server topology information belongs solidly in the server, and should never be explicitly exposed to clients. Clients have no way to know which servers can be trusted (beyond, presumably, the initial one they contacted), nor when a referral might cross an administrative boundary (and thus require a different set of credentials). This is all knowledge that a server administrator already has, and it should only ever be dealt with on the server side.
The fact that ActiveDirectory is entirely glued together with referrals is just one of many flaws in its design.
On Mon, Jan 28, 2008 at 08:23:23AM -0800, Howard Chu wrote:
I was testing a subdomain configuration and I wondered: What happened to the -C switch? And will there be support for following referrals with credentials?
Doing so is a security vulnerability, so that support was dropped from all of the bundled tools quite a long time ago. Referrals in general are a stupid, poorly designed, insecure feature of LDAP which is why OpenLDAP provides so many secure alternatives to them (chaining, glued back-ldap, etc.).
Server topology information belongs solidly in the server, and should never be explicitly exposed to clients. Clients have no way to know which servers can be trusted (beyond, presumably, the initial one they contacted), nor when a referral might cross an administrative boundary (and thus require a different set of credentials). This is all knowledge that a server administrator already has, and it should only ever be dealt with on the server side.
The fact that ActiveDirectory is entirely glued together with referrals is just one of many flaws in its design.
I appreciate your clear words.
Thanks, Aiko
openldap-technical@openldap.org