[Users] LDAP
Yair Zaslavsky
yzaslavs at redhat.com
Sun Feb 26 07:45:23 UTC 2012
On 02/26/2012 09:18 AM, Oved Ourfalli wrote:
> Found the problem.
> We are identifying if the LDAP server is AD or not by checking if the root DSE contains the "defaultNamingContext" attribute.
> This attribute is not in the LDAP standard, thus it appears in AD, and not in IPA and RHDS...
>
> Looking at the rootDSE you provided it looks like it was added to IPA, therefore we identify it as AD.
>
> Can you open us a bug on that upstream?
> Given that issue, I think we should also provide a way to set the ldap provider type (using the engine-manage-domains utility), in order to workaround such issues in the future.
Don't you think that now this key (i.e providerType=IPA) kinda becomes
mandatory?
>
> Thank you,
> Oved
>
> ----- Original Message -----
>> From: "Nathan Stratton" <nathan at robotics.net>
>> To: "Oved Ourfalli" <ovedo at redhat.com>
>> Cc: users at ovirt.org
>> Sent: Friday, February 24, 2012 8:31:02 PM
>> Subject: Re: [Users] LDAP
>>
>> On Fri, 24 Feb 2012, Oved Ourfalli wrote:
>>
>>> The identification of the provider type is done using the following
>>> logic, according to the results from the root DSE query:
>>> * if it contains a defaultNamingContext attribute --> AD
>>> * else
>>> * Check the vendorName attribute
>>> * if it is "389 Project" then it is IPA
>>> * if it is "Red Hat" then it is RHDS.
>>>
>>> We added support for AD, IPA and RHDS. I guess that 389ds has a
>>> different vendor name.
>>>
>>> What does your root DSE query show?
>>> You can run it using ldapsearch, with the options" -LLL -Y GSSAPI
>>> -D <distinguished name of the username> -h <ldap server> -b "" -s
>>> base objectClass=*
>>>
>>> the distinguished name will be something like:
>>> uid=username,dc=example,dc=com
>>
>> [root at ipa-master ~]# ldapsearch -LLL -Y GSSAPI -D
>> uid=nathan,cn=users,cn=accounts,dc=blinkmind,dc=net -h localhost -b
>> "" -s
>> base objectClass=*
>> SASL/GSSAPI authentication started
>> SASL username: admin at BLINKMIND.NET
>> SASL SSF: 56
>> SASL data security layer installed.
>> dn:
>> objectClass: top
>> namingContexts: dc=blinkmind,dc=net
>> defaultnamingcontext: dc=blinkmind,dc=net
>> supportedExtension: 2.16.840.1.113730.3.5.7
>> supportedExtension: 2.16.840.1.113730.3.5.8
>> supportedExtension: 2.16.840.1.113730.3.5.10
>> supportedExtension: 2.16.840.1.113730.3.8.10.3
>> supportedExtension: 1.3.6.1.4.1.4203.1.11.1
>> supportedExtension: 2.16.840.1.113730.3.8.10.1
>> supportedExtension: 2.16.840.1.113730.3.5.3
>> supportedExtension: 2.16.840.1.113730.3.5.12
>> supportedExtension: 2.16.840.1.113730.3.5.5
>> supportedExtension: 2.16.840.1.113730.3.5.6
>> supportedExtension: 2.16.840.1.113730.3.5.9
>> supportedExtension: 2.16.840.1.113730.3.5.4
>> supportedExtension: 1.3.6.1.4.1.1466.20037
>> supportedControl: 2.16.840.1.113730.3.4.2
>> supportedControl: 2.16.840.1.113730.3.4.3
>> supportedControl: 2.16.840.1.113730.3.4.4
>> supportedControl: 2.16.840.1.113730.3.4.5
>> supportedControl: 1.2.840.113556.1.4.473
>> supportedControl: 2.16.840.1.113730.3.4.9
>> supportedControl: 2.16.840.1.113730.3.4.16
>> supportedControl: 2.16.840.1.113730.3.4.15
>> supportedControl: 2.16.840.1.113730.3.4.17
>> supportedControl: 2.16.840.1.113730.3.4.19
>> supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
>> supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
>> supportedControl: 1.2.840.113556.1.4.319
>> supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8
>> supportedControl: 1.3.6.1.4.1.4203.666.5.16
>> supportedControl: 2.16.840.1.113730.3.4.14
>> supportedControl: 2.16.840.1.113730.3.4.20
>> supportedControl: 1.3.6.1.4.1.1466.29539.12
>> supportedControl: 2.16.840.1.113730.3.4.12
>> supportedControl: 2.16.840.1.113730.3.4.18
>> supportedControl: 2.16.840.1.113730.3.4.13
>> supportedSASLMechanisms: EXTERNAL
>> supportedSASLMechanisms: PLAIN
>> supportedSASLMechanisms: GSSAPI
>> supportedSASLMechanisms: ANONYMOUS
>> supportedSASLMechanisms: CRAM-MD5
>> supportedSASLMechanisms: DIGEST-MD5
>> supportedSASLMechanisms: LOGIN
>> supportedLDAPVersion: 2
>> supportedLDAPVersion: 3
>> vendorName: 389 Project
>> vendorVersion: 389-Directory/1.2.10.rc1 B2012.035.328
>> dataversion: 020120223201756
>> netscapemdsuffix: cn=ldap://dc=ipa-master,dc=blinkmind,dc=net:389
>> lastusn: 468
>>
>>
>>> It will help us understand which vendor name is shown in your ldap
>>> server, and we might use it in order to improve the
>>> identification.
>>>
>>> It surprises me that IPA is not identified correctly, as "389
>>> Project" is the vendor name that was used there (unless it was
>>> changed).
>>> As for 389ds, as I said before we added RHDS support, so there
>>> might be changes in the schema, and also probably the vendor name
>>> there is not "Red Hat".
>>
>> Looks like "389 Project"
>>
>> However I still see:
>>
>> -bash-4.2# engine-manage-domains -action=add -domain=blinkmind.net
>> -user=nathan -interactive
>> Enter password:
>>
>> No user in Directory was found for nathan at BLINKMIND.NET. Trying next
>> LDAP server in list
>> Failure while testing domain blinkmind.net. Details: No user
>> information was found for user
>>
>>
>> On my FreeIPA server I see:
>>
>> [24/Feb/2012:18:28:46 +0000] conn=144 op=3 SRCH
>> base="dc=blinkmind,dc=net"
>> scope=2
>> filter="(&(samaccounttype=805306368)(userprincipalname=nathan at BLINKMIND.NET))"
>> attrs="nsUniqueId ipaUniqueID objectguid objectClass
>> javaSerializedData
>> javaClassName javaFactory javaCodebase javaReferenceAddress
>> javaClassNames
>> javaremotelocation"
>> [24/Feb/2012:18:28:46 +0000] conn=144 op=3 RESULT err=0 tag=101
>> nentries=0
>> etime=0 notes=U
>>
>>
>> Entries returned are 0 because userprincipalname=nathan at BLINKMIND.NET
>> does
>> not exist.
>>
>>
>>> <>
>> Nathan Stratton CTO, BlinkMind, Inc.
>> nathan at robotics.net nathan at
>> blinkmind.com
>> http://www.robotics.net
>> http://www.blinkmind.com
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
More information about the Users
mailing list