[SSSD] Active Directory integration issues
R.L.
kalischt at gmail.com
Wed Mar 21 09:05:53 UTC 2012
Hello
Thanks. No, using msktutil.
The computer record in ad looks exactly equivalent to others created manually using ktpass.exe.
r.
On 21/03/2012, at 7:23 PM, Ondrej Valousek <webserv at s3group.cz> wrote:
> How did you create the computer account in AD? Manually or using Samba?
> Ondrej
>
> On 03/21/2012 07:05 AM, Rolf Loudon wrote:
>>
>> Hello
>>
>> I've installed sssd 1.5 on an ubuntu 11.10 server. I've followed the howto at
>> https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Server
>>
>> I wish to use SASL as the authentication to the AD KDC. I add the computer account to the domain and test it as described with
>> kinit -k -t /etc/krb5.keytab host/myhostname.domain.name at REALM.NAME
>> then
>> ldapsearch -h ad.kdc -b "dc=domainpart1,dc=domainpart2,dc=domainpart3" -Y GSSAPI cn=someuser
>>
>> and that all works fine.
>>
>> When I use this setup within sssd there are a two main issues.
>>
>> Firstly the logs tell me that the principal is not found in the KDC database. But when I inspect it using ADSI Edit I see the SPN and UPN values that I expect to see and that match the principal it says it cannot find. Likewise these principals can be seen from klist -kte /etc/krb5/keytab (though it doesn't complain about not finding anything in the key tab)
>>
>> I can get round that issue temporarily by specifying the principal name using ldap_sasl_authid. I'd still like to know what is wrong in that instance.
>>
>>
>> Secondly the ldap_search_base strangely affects the authentication and the user lookup. I don't know if the searching is subtree or not. I can't see a parameter to make this explicit.
>>
>> If I set ldap_search_base (or ldap_user_search_base) to dc=domainpart1,dc=domainpart2,dc=domainpart3 then I get errors about ldap_sasl_interactive_bind_s failing.
>> however if I set the ldap_search_base to cn=users,dc=domainpart1,dc=domainpart2,dc=domainpart3 then those errors go away and the lookup is done.
>>
>> The problem is that the users do not live in cn=users,dc=domainpart1,dc=domainpart2,dc=domainpart3 they are in an OU elsewhere. They can be found via a subtree search (as per the ldapsearch example above) if the search base is set to higher up the tree at just the domain components specification.
>>
>> But if I set the search base that way, then the sasl bind fails.
>>
>> Using both ldap_search_base and ldap_user_search_base makes no difference.
>>
>> Is there are way to separately define where the ldap_sasl_bind looks (unless I misunderstand it needs to look for the computer account, which is in cn=computers,dc=... which is also not within cn=users,dc=... so its still confusing me) so that the search base can be set so the user lookup will work.
>>
>> I can successfully lookup the user if I use a simple bind with ldap_default_bind_dn and ldap_default_authtok rather than sasl. And can show that the ldap_search_base affects this lookup in the above way.
>>
>> Really appreciate any pointers to these two problems.
>>
>> many thanks
>>
>> r.
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/sssd-devel
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120321/f778ed61/attachment.html>
More information about the sssd-devel
mailing list