On 02/14/2014 04:00 PM, Richard Connon wrote:
> Hi,
>
> I'm using sssd 1.8.4 (debian package) as a client for a samba4 domain,
> currently with one DC. The domain has unix UIDs and GIDs stored so no
> idmapping is required.
>
> The config I have (so far) is this:
>
> [sssd]
> config_file_version = 2
> services = nss, pam
> domains = DOMAIN
>
> [nss]
>
> [pam]
>
> [domain/DOMAIN]
> auth_provider = krb5
> chgpass_provider = krb5
> dns_search_domain = ads.domain.tld
> id_provider = ldap
> krb5_realm = ADS.DOMAIN.TLD
> ldap_sasl_authid = HOST$(a)ADS.DOMAIN.TLD
> ldap_sasl_mech = GSSAPI
> ldap_schema = rfc2307bis
> ldap_user_name = sAMAccountName
>
>
> So far NSS seems to be working (kind of) but is very slow to retrieve
> each user/group the first time and is very slow for queries where the
> user/group does not exist.
>
> The only messages appearing in any relevant logs are the following 2:
> In sssd_DOMAIN.log:
> (Fri Feb 14 18:07:37 2014) [sssd[be[DOMAIN]]] [load_backend_module]
> (0x0010): Error (2) in module (ldap) initialization
> (sssm_ldap_autofs_init)!
> In syslog file auth.log:
> Feb 14 19:20:06 unifi sssd_be: GSSAPI Error: Miscellaneous failure (see
> text) (Matching credential (ldap/ads.domain.tld(a)DOMAIN.TLD) not found)
>
> The former seems to be quite harmless but the latter repeats quite
> frequently and seems to suggest SSSD is trying to use an invalid
> kerberos ticket for the LDAP connection.
> This principal name is invalid for two reasons, first there is no LDAP
> service on "ads.domain.tld" it is on "dc02.ads.domain.tld",
second
> "DOMAIN.TLD" is not the name of my realm, it is "ADS.DOMAIN.TLD"
>
> Does anyone have any idea what causes the latency in responding to NSS
> queries and whether I need to worry about the GSSAPI errors?
>
> Finally I have not yet succeeded in getting this setup to work for PAM.
> I haven't been able to try very easily due to the NSS latency issues.
>
> Thanks in advance,
> Richard
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Any chance you can use a later version of SSSD? Samba DC acts as AD and
SSSD 1.9 and later have special features for AD integration. It would be
much easier to configure.
I suspect that the issue is related to resolving group memberships and
with 1.9 there are some tricks that take advantage of AD being on the
other side rather than generic LDAP. I of cause assume that Samba DC
implemented same controls and capabilities that help with group lookups
as the AD.
Using 1.9 or later would be possible but I wanted to give 1.8.x as good
a go as I could. Given sssd is so integral to system security I'm
hesitant to stray away from packages maintained by my distribution.
I believe the rfc2307bis schema option in 1.8 should be sufficient to
handle the group memberships in my DC LDAP schema.
The issues I'm seeing don't seem to be relating to group memberships
since they affect passwd lookups the same as group ones. Do you have
reason to believe this is related to the problem?