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$@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@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
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$@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@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@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.
On 14/02/2014 21:13, Dmitri Pal wrote:
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$@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@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@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?
On 02/14/2014 04:19 PM, Richard Connon wrote:
On 14/02/2014 21:13, Dmitri Pal wrote:
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$@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@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@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? _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Please setup debug_level = 7 or higher in the config file and provide logs. This would be the starting point to determine the cause of the problems.
On (14/02/14 21:19), Richard Connon wrote:
On 14/02/2014 21:13, Dmitri Pal wrote:
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$@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.
What does it mean very slow? Do you need to wait 10 seconds?
Did you run "getent passwd user" or "id user"?
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@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
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?
If you don't mind and there is not any conflict you can try to install sssd 1.9.4 from ppa https://launchpad.net/~sssd/+archive/updates/
It will be great if you can send full log files with debug_level 7 in the domain and nss section (like Dimitri wrote in another mail)
LS
On 14/02/2014 21:37, Lukas Slebodnik wrote:
On (14/02/14 21:19), Richard Connon wrote:
On 14/02/2014 21:13, Dmitri Pal wrote:
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$@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.
What does it mean very slow? Do you need to wait 10 seconds?
Did you run "getent passwd user" or "id user"?
Yes it's more than 10 seconds. I ran getent passwd user but id user does the same.
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@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
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?
If you don't mind and there is not any conflict you can try to install sssd 1.9.4 from ppa https://launchpad.net/~sssd/+archive/updates/
I am using debian not ubuntu. I could package 1.9.4 but as I said above I'm hesitant to do so since it would mean tracking sssd upstream myself for security issues.
It will be great if you can send full log files with debug_level 7 in the domain and nss section (like Dimitri wrote in another mail)
Log files produced from starting sssd then running "getent passwd user" with debug_level = 7 in [nss] and [domain/DOMAIN] can be found here: http://www.irconan.co.uk/sssd-log.tar
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (14/02/14 23:11), Richard Connon wrote:
On 14/02/2014 21:37, Lukas Slebodnik wrote:
On (14/02/14 21:19), Richard Connon wrote:
On 14/02/2014 21:13, Dmitri Pal wrote:
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$@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.
What does it mean very slow? Do you need to wait 10 seconds?
Did you run "getent passwd user" or "id user"?
Yes it's more than 10 seconds. I ran getent passwd user but id user does the same.
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@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
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?
If you don't mind and there is not any conflict you can try to install sssd 1.9.4 from ppa https://launchpad.net/~sssd/+archive/updates/
I am using debian not ubuntu. I could package 1.9.4 but as I said above I'm hesitant to do so since it would mean tracking sssd upstream myself for security issues.
It will be great if you can send full log files with debug_level 7 in the domain and nss section (like Dimitri wrote in another mail)
Log files produced from starting sssd then running "getent passwd user" with debug_level = 7 in [nss] and [domain/DOMAIN] can be found here: http://www.irconan.co.uk/sssd-log.tar
[sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ads.domain.tld/CN=Configuration,DC=ads,DC=domain,DC=tld] with fd [22]. [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://ads.domain.tld/CN=Configuration,DC=ads,DC=domain,DC=tld]. [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ads.domain.tld/DC=DomainDnsZones,DC=ads,DC=domain,DC=tld] with fd [22]. [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://ads.domain.tld/DC=DomainDnsZones,DC=ads,DC=domain,DC=tld]. [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ads.domain.tld/DC=ForestDnsZones,DC=ads,DC=domain,DC=tld] with fd [22]. [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://ads.domain.tld/DC=ForestDnsZones,DC=ads,DC=domain,DC=tld].
There was 37 seconds delay due to these failed binds.
Could you try to manually set search bases for users and group? ldap_user_search_base ldap_group_search_base
LS
On 14/02/2014 23:44, Lukas Slebodnik wrote:
On (14/02/14 23:11), Richard Connon wrote:
On 14/02/2014 21:37, Lukas Slebodnik wrote:
On (14/02/14 21:19), Richard Connon wrote:
On 14/02/2014 21:13, Dmitri Pal wrote:
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$@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.
What does it mean very slow? Do you need to wait 10 seconds?
Did you run "getent passwd user" or "id user"?
Yes it's more than 10 seconds. I ran getent passwd user but id user does the same.
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@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
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?
If you don't mind and there is not any conflict you can try to install sssd 1.9.4 from ppa https://launchpad.net/~sssd/+archive/updates/
I am using debian not ubuntu. I could package 1.9.4 but as I said above I'm hesitant to do so since it would mean tracking sssd upstream myself for security issues.
It will be great if you can send full log files with debug_level 7 in the domain and nss section (like Dimitri wrote in another mail)
Log files produced from starting sssd then running "getent passwd user" with debug_level = 7 in [nss] and [domain/DOMAIN] can be found here: http://www.irconan.co.uk/sssd-log.tar
[sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ads.domain.tld/CN=Configuration,DC=ads,DC=domain,DC=tld] with fd [22]. [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://ads.domain.tld/CN=Configuration,DC=ads,DC=domain,DC=tld]. [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ads.domain.tld/DC=DomainDnsZones,DC=ads,DC=domain,DC=tld] with fd [22]. [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://ads.domain.tld/DC=DomainDnsZones,DC=ads,DC=domain,DC=tld]. [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ads.domain.tld/DC=ForestDnsZones,DC=ads,DC=domain,DC=tld] with fd [22]. [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://ads.domain.tld/DC=ForestDnsZones,DC=ads,DC=domain,DC=tld].
There was 37 seconds delay due to these failed binds.
Could you try to manually set search bases for users and group? ldap_user_search_base ldap_group_search_base
Seems obvious now you've pointed it out. That worked wonders, thanks a lot!
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Fri, Feb 14, 2014 at 11:53:09PM +0000, Richard Connon wrote:
On 14/02/2014 23:44, Lukas Slebodnik wrote:
On (14/02/14 23:11), Richard Connon wrote:
On 14/02/2014 21:37, Lukas Slebodnik wrote:
On (14/02/14 21:19), Richard Connon wrote:
On 14/02/2014 21:13, Dmitri Pal wrote:
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$@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.
What does it mean very slow? Do you need to wait 10 seconds?
Did you run "getent passwd user" or "id user"?
Yes it's more than 10 seconds. I ran getent passwd user but id user does the same.
> > 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@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
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?
If you don't mind and there is not any conflict you can try to install sssd 1.9.4 from ppa https://launchpad.net/~sssd/+archive/updates/
I am using debian not ubuntu. I could package 1.9.4 but as I said above I'm hesitant to do so since it would mean tracking sssd upstream myself for security issues.
It will be great if you can send full log files with debug_level 7 in the domain and nss section (like Dimitri wrote in another mail)
Log files produced from starting sssd then running "getent passwd user" with debug_level = 7 in [nss] and [domain/DOMAIN] can be found here: http://www.irconan.co.uk/sssd-log.tar
[sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ads.domain.tld/CN=Configuration,DC=ads,DC=domain,DC=tld] with fd [22]. [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://ads.domain.tld/CN=Configuration,DC=ads,DC=domain,DC=tld]. [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ads.domain.tld/DC=DomainDnsZones,DC=ads,DC=domain,DC=tld] with fd [22]. [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://ads.domain.tld/DC=DomainDnsZones,DC=ads,DC=domain,DC=tld]. [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ads.domain.tld/DC=ForestDnsZones,DC=ads,DC=domain,DC=tld] with fd [22]. [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://ads.domain.tld/DC=ForestDnsZones,DC=ads,DC=domain,DC=tld].
There was 37 seconds delay due to these failed binds.
Could you try to manually set search bases for users and group? ldap_user_search_base ldap_group_search_base
Seems obvious now you've pointed it out. That worked wonders, thanks a lot!
As an alternative 'ldap_referrals = false' which we typically recommend when using the LDAP id provider with AD might help as well.
bye, Sumit
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org