----- Original Message ----- > From: "Yair Zaslavsky" <yzasl...@redhat.com> > To: "Oved Ourfalli" <ov...@redhat.com> > Cc: users@ovirt.org > Sent: Sunday, February 26, 2012 1:09:16 PM > Subject: Re: [Users] LDAP > > On 02/26/2012 12:57 PM, Oved Ourfalli wrote: > > > > > > ----- Original Message ----- > >> From: "Yaniv Kaul" <yk...@redhat.com> > >> To: "Yair Zaslavsky" <yzasl...@redhat.com> > >> Cc: "Oved Ourfalli" <ov...@redhat.com>, users@ovirt.org > >> 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. > I agree with it. It looks to me like the right way to go.
> > > > > >> > >>> > >>>>> Thank you, > >>>>> Oved > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Nathan Stratton"<nat...@robotics.net> > >>>>>> To: "Oved Ourfalli"<ov...@redhat.com> > >>>>>> Cc: users@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@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: ad...@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 nat...@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=nat...@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=nat...@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@ovirt.org > >>>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>>>> > >>>> _______________________________________________ > >>>> Users mailing list > >>>> Users@ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/users > >>> _______________________________________________ > >>> Users mailing list > >>> Users@ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/users > >> > >> _______________________________________________ > >> Users mailing list > >> Users@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/users > >> > > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users