On 02/26/2012 12:57 PM, Oved Ourfalli wrote: > > > ----- Original Message ----- >> From: "Yaniv Kaul" <[email protected]> >> To: "Yair Zaslavsky" <[email protected]> >> Cc: "Oved Ourfalli" <[email protected]>, [email protected] >> Sent: Sunday, February 26, 2012 9:47:00 AM >> Subject: Re: [Users] LDAP >> >> On 02/26/2012 09:46 AM, Yair Zaslavsky wrote: >>> On 02/26/2012 09:45 AM, Yair Zaslavsky wrote: >>>> 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? >>> Or actually, maybe we should have it optional - if set - then this >>> value >>> will be used for providerType, if not - our "auto-deduction" >>> mechanism >>> takes place. >>> >>> Thoughts? >> >> Drop the auto-detection. >> Y. > > The pros for adding the auto-detection is the ease of use. > The cons are that if it is not good enough it may fail due to changes in the > LDAP provider (like what happened in this issue). > I think we should improve that, but also make a way to work-around it, using > special option of setting the provider type. So what do u think about my suggestion? manage-domains can add "explicit provider type" - if does not exist, auto-detection is carried out.
> > >> >>> >>>>> Thank you, >>>>> Oved >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Nathan Stratton"<[email protected]> >>>>>> To: "Oved Ourfalli"<[email protected]> >>>>>> Cc: [email protected] >>>>>> 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@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: [email protected] >>>>>> 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 [email protected]. 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)([email protected]))" >>>>>> 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 >>>>>> [email protected] >>>>>> 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 >>>>>> [email protected] >>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.ovirt.org/mailman/listinfo/users >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.ovirt.org/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/users >> _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
