>From a performance perspective which one should be faster = AD as an LDAP Or AD as a KDC
Paulo -----Original Message----- From: Indexer [mailto:[email protected]] Sent: Monday, November 15, 2010 12:59 PM To: Paulo Jorge N. Correia (paucorre) Cc: [email protected] Subject: Re: Pass-Through authentication -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/11/2010, at 23:04, Paulo Jorge N. Correia (paucorre) wrote: > > # Hernani Correia, Users, cisco.com > dn: CN=Paulo Correia,CN=Users,DC=consolidated,DC=com > objectClass: top > objectClass: person > objectClass: organizationalPerson > cn: Hernani Correia > sn: Correia > givenName: Hernani > userPassword: {sasl}[email protected] > userPrincipalName: [email protected] > mail: [email protected] > > # Hernani Correia, Users, cisco.com > dn: CN= William Brown,CN=Users,DC=consolidated,DC=com > objectClass: top > objectClass: person > objectClass: organizationalPerson > cn: William Brown > sn: Brown > givenName: William > userPassword: {sasl}[email protected] > userPrincipalName: [email protected] > mail: [email protected] > > I need to bind based on the domain not a single bind in SASL. > > Can you help ? Its good to know for sure what you wanted to do. Jonathan seemed to have a solution for you. My answer is to stop using AD as LDAP for authentication, and start treating them as KDC's. For example on my own server, I have multiple KDC's listed, for users, as in your situation, and each user works. uid=william,ou=Users userPassword: {sasl}[email protected] uid=michael,ou=Users userPassword: {sasl}[email protected] In my setup i have in slapd.conf (the sasl slapd.conf) pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux Then i launch saslauthd with '-a kerberos5' , and there should be a relevant option for this on your distribution of choice. Finally, i configure my servers krb5.conf (generally /etc/krb5.conf). Default settings are fine for this to use a AD kdc this is my AD krb5 centre [realms] CHOCOLATE.LAN = { kdc = beatrice.chocolate.lan } [domain_realm] .firstyear.id.au = CHOCOLATE.LAN Then, the @REALM attribute on userPassword will respect the relevant KDC (or in this case ADDC) of choice for a user. Note: Yes, my home krb5 and ldap are chocolate.lan. I couldnt be bothered accessing my work servers. > > Paulo > > > > -----Original Message----- > From: Indexer [mailto:[email protected]] > Sent: Monday, November 15, 2010 11:44 AM > To: Paulo Jorge N. Correia (paucorre) > Cc: [email protected] > Subject: Re: Pass-Through authentication > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 15/11/2010, at 04:59, Paulo Jorge N. Correia (paucorre) wrote: > >> Hi all, >> >> I'm just starting with openLDAP and saslauth, and I'm trying to >> replicate what I can achieve with ADAM/AD LDS in Windows platform. >> >> >> >> I'm trying to use openldap to aggregate user information from several >> AD servers under different forests. >> >> >> >> So single point of contact from an LDAP perspective for an >> organization, and then openldap should pass-through the >> authentication > >> request that receives to the AD DC of the respective user. >> >> >> >> This works well with saslauthd for a single domain, but if I need to >> do this with multiple domains, I don't know how to configure > saslauthd. > > Windows, and AD utilise kerberos. Just treat your AD servers as KRB5 > realms, and it works. both MIT and Hemidal can work with this, so > following the passthrough instructions for these will work > > Alternatively, you can use AD as an ldap server, but it follows much > the same principals. > > http://www.openldap.org/doc/admin24/security.html > > > >> >> >> >> Can someone help ? >> >> >> >> Thank you, >> >> Paulo >> > > William Brown > > pgp.mit.edu > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > > iQIcBAEBAgAGBQJM4R0OAAoJEHF16AnLoz6JlK8QAK0YtQX1y6J/yH1dq36zyr0x > p6gA7j6/pWwqzspUcC5srESejrx76Yn9wGOGku3epCu4QwcEtx9MOVPdhmBT9hCk > wXUnvP+4ePpo2wAMvrrkv+K0FfNbAQVJt44zGzrGxRrfSVPqkU+B0nsFYCbxjUF0 > NHS3p+XRftqnQNOnsH3aNgB5HDnA5romlq3ikdSyUQRIZpt+BD7ueu07BVG5qhFN > 6L/rT8JfLI2X/Liw70LeZg1XifZDyOMXfbaj84Q6JeyObdQidPYXKev9Nlm5CDt/ > qOh1ZYTPoUuz7oLRjjNEnHXXiSeGB3DeHxoY+wsgnNd9AnLPKHn4xxFz65DQAUva > LtJxxFpVOE4uTCTx+Sl58v3qfn87CtxX/EdHw1th25E3L+zh3LCfVG9uRApbwYeI > Sb7BH8N7varUnrm1ZoqSZ1EO31jrBNjfqOwXMs7jLJBLlEobPUuX3mk5TehgyrD8 > 0zLPbaVIzN5Dq/PTG7pT27D/9ABbqTGr0lpridxyDQSzPrBP4Pvx6EdmxqDbuY3n > jDW7F3Xixxg0gPoi+/5A9XO7x0nf3TUnV4s9n3gFiRMAAQWs3gks7kgup/+1Rv7k > NvDoA7D1j3oaxd2/o+moHRA9Ko7xY5NqJuyJVXRUdKFwiohxN+t1mlsqF4X3oFTv > xGxKYpsUBdZMKHONbA7v > =X3CH > -----END PGP SIGNATURE----- William Brown pgp.mit.edu -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iQIcBAEBAgAGBQJM4S6eAAoJEHF16AnLoz6JXggQAL2visI6hJ4Aqx2gW8NQ9pUn 9CZ3oBPJdaBYQvrnLyqAjGQYZ7fUsYrypuYZMTGVD0mWSfhzs7KT0FIhHAEPuGiu rdH3bfQFb/kkRn2GST2q6rf5DThOZBVLE9jIkGtTnJlHhF/h9lP0WDnKguxsYYaX WuPropxzq5V947sEPGWQC7cAwSTlrcrfhlDjBiOWrXj11SAryE3HRFhZKNz6A/hu wajxBGxAPpKFtw0vPczMIzlbWi/wi7TmcudWHd5ce+LRy7YMJ6ndgKWd/4O2ReNi zIX/flzAupmCYDXD4Y9zhVotOo1jBN7Iv4V2I63vxq/uxdMihHhNIwtSOnP5EHuq VBOEJZz9dnJl7IOC8pwtwX0vdpOV7G4Wr6d3R0OQoE2bUGrNBNGKwPBG5gkiQN4v Uv/OrDJ07+PKSQ+g0CE8iubtyhnX2neU1QTDjZ3PPGkG+l1dyrGp6juv2NfAD5N+ Jlsg5xuxqTbJ+/1mm4szwJEqHrCFBNEeWblCagPdVWVb7x3I7fNpSKCeZgVqC7P4 OWkst3bUY6Ebk6q3qg2B/AQ1snp0EFE9FcqFG+0VQK9KvnRwV6/RTcy05/7fQg+g 7wNdL2VBb/9pYuFi9r23IFuOCkCpu1UJIHTeOCbK2N+RmFQHiGPWOp11LEyVZTRk j2WQWYQWWbltqAe5jVnO =zd2D -----END PGP SIGNATURE-----
