[SSSD-users] Slow convergence between sssd and windows 2008 r2 ad server

Jakub Hrozek jhrozek at redhat.com
Fri May 2 08:13:43 UTC 2014


On Fri, May 02, 2014 at 08:47:48AM +0200, Paul Liljenberg wrote:
> >On Wed, Apr 23, 2014 at 08:10:47AM +0200, Paul Liljenberg wrote:
> >>* Notice: I sent this email to the list using another mail address, which i
> *>>* believe whas not verified properly. If this emali is properly sent to the
> *>>* list you can disregard moderating the message.
> *>> >>* Hello
> *>> >>* Im setting up a single signon solution for about 1200 servers. The
> *>>* situation as it seems is that we are setting up all users in a windows 2008
> *>>* r2 active directory, adding proper unix permissions. A user with proper
> *>>* priveliges to read active directory is being used by sssd to read which
> *>>* users is allowed in and not. If the users does not have a home directory
> *>>* they are being created automatically. So whats the issue here? Access to
> *>>* the system does not happen instantanely and i believe its because sssd is
> *>>* polling active directory every 120 seconds. It seems as if it has issues
> *>>* remaining its state and it is just as if it would loose its local database.
> *>>* I would like to be able to have users being logged directly after a user is
> *>>* being added to active directory. Is this possible and how could this be
> *>>* achieved?
> *
> >I would encourage you to turn enumeration off. Enumeration is a background
> >task that periodically downloads and saves all users from the server,
> >which can be very intensitve especially for large environments.
> 
> >Also, is there a reason to use a bind user and a password and not a
> >keytab and then leverage GSSAPI?
> 
> >We have some howtos on enrolling a client with AD for pre-1.9 clients:
> >https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Servero
> 
> >And also for 1.9 and later (recommended):
> >https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
> 
> 
> Ive edit the configuration to not use enumeration. The goal is to use
> GSSAPI to. For some reason it refuses logins. It does not give me any
> helpful ouput to fix it.
> 
> conf:
> 
> [sssd]
> config_file_version = 2
> domains = INT.HOME.LAN
> services = nss, pam
> debug_level = 0
> 
> [nss]
> filter_groups = root
> filter_users = root
> reconnection_retries = 3
> 
> [pam]
> reconnection_retries = 3
> 
> [domain/INT.HOME.LAN]
> # Unless you know you need referrals, turn them off
> ldap_referrals = false
> # Uncomment if you need offline logins
> cache_credentials = true
> enumerate = false
> 
> id_provider = ldap
> auth_provider = krb5
> chpass_provider = krb5
> access_provider = ldap
> 
> # Uncomment if service discovery is not working
> ldap_uri = ldap://vagrant-2008r2.int.home.lan
> 
> # Comment out if not using SASL/GSSAPI to bind
> ldap_sasl_mech = GSSAPI
> # Uncomment and adjust if the default principal host/fqdn at REALM is not
> available
> #ldap_sasl_authid = nfs/client.ad.example.com at
> AD.EXAMPLE.COM<http://ad.example.com/>
> 
> # Define these only if anonymous binds are not allowed and no keytab is
> available
> # Enabling use_start_tls is very important, otherwise the bind password is
> transmitted
> # over the network in the clear
> #ldap_id_use_start_tls = True
> #ldap_default_bind_dn = CN=test,CN=Users,DC=int,DC=home,DC=local
> #ldap_default_authtok_type = password
> #ldap_default_authtok = secretpassword
> 
> ldap_schema = rfc2307bis
> 
> ldap_user_search_base = CN=Users,DC=int,DC=home,DC=lan
> ldap_user_object_class = user
> 
> ldap_user_home_directory = unixHomeDirectory
> ldap_user_principal = userPrincipalName
> 
> ldap_group_search_base = CN=linuxadmins,DC=int,DC=home,DC=lan
> ldap_group_object_class = group
> 
> #ldap_access_filter = memberOf=cn=linuxadmins,dc=int,dc=home,dc=lan
> 
> ldap_access_order = expire
> ldap_account_expire_policy = ad
> ldap_force_upper_case_realm = true
> #ldap_krb5_init_creds = true
> 
> # Uncomment if dns discovery of your AD servers isn't working.
> #krb5_server = 192.168.3.11
> krb5_realm = INT.HOME.LAN
> #krb5_keytab = /etc/krb5.keytab
> 
> # Probably required with sssd 1.8.x and newer
> krb5_canonicalize = false
> 
> # Perhaps you need to redirect to certain attributes?
> #ldap_user_object_class = user
> #ldap_user_name = sAMAccountName
> #ldap_user_uid_number = msSFU30UidNumber
> #ldap_user_gid_number = msSFU30GidNumber
> #ldap_user_gecos = displayName
> #ldap_user_home_directory = msSFU30HomeDirectory
> #ldap_user_shell = msSFU30LoginShell
> #ldap_user_principal = userPrincipalName
> #ldap_group_object_class = group
> #ldap_group_name = cn
> #ldap_group_gid_number = msSFU30GidNumber
> 
> 
> error output:
> 

Did you trim the debug log maybe? It seems incomplete..

> (Fri May  2 08:45:01 2014) [sssd[nss]] [nss_cmd_getpwnam] (0x0100):
> Requesting info for [paul1] from [<ALL>]
> (Fri May  2 08:45:01 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [paul1 at INT.HOME.LAN]

The frontend searches for paul1 in INT.HOME.LAN ^

> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [be_get_account_info]
> (0x0100): Got request for [4097][1][name=paul1]

Queries the backend ^

> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of
> 'vagrant-2008r2.int.home.lan' in files
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [set_server_common_status] (0x0100): Marking server
> 'vagrant-2008r2.int.home.lan' as 'resolving name'
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record
> of 'vagrant-2008r2.int.home.lan' in files
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [resolv_gethostbyname_next] (0x0200): No more address families to retry
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of
> 'vagrant-2008r2.int.home.lan' in DNS
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [set_server_common_status] (0x0100): Marking server
> 'vagrant-2008r2.int.home.lan' as 'name resolved'
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [be_resolve_server_done] (0x0200): Found address for server
> vagrant-2008r2.int.home.lan: [192.168.3.2] TTL 3600

Backend resolved DNS, starts connecting ^

> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [get_naming_context]
> (0x0200): Using value from [defaultNamingContext] as naming context.
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base]
> (0x0100): Setting option [ldap_search_base] to [DC=int,DC=home,DC=lan].
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [common_parse_search_base] (0x0100): Search base added:
> [DEFAULT][DC=int,DC=home,DC=lan][SUBTREE][]
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base]
> (0x0100): Setting option [ldap_netgroup_search_base] to
> [DC=int,DC=home,DC=lan].
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [common_parse_search_base] (0x0100): Search base added:
> [NETGROUP][DC=int,DC=home,DC=lan][SUBTREE][]
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base]
> (0x0100): Setting option [ldap_sudo_search_base] to [DC=int,DC=home,DC=lan].
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [common_parse_search_base] (0x0100): Search base added:
> [SUDO][DC=int,DC=home,DC=lan][SUBTREE][]
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base]
> (0x0100): Setting option [ldap_service_search_base] to
> [DC=int,DC=home,DC=lan].
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [common_parse_search_base] (0x0100): Search base added:
> [SERVICE][DC=int,DC=home,DC=lan][SUBTREE][]
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sdap_set_search_base]
> (0x0100): Setting option [ldap_autofs_search_base] to
> [DC=int,DC=home,DC=lan].
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [common_parse_search_base] (0x0100): Search base added:
> [AUTOFS][DC=int,DC=home,DC=lan][SUBTREE][]
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [fo_resolve_service_send] (0x0100): Trying to resolve service 'KERBEROS'
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of
> 'client' in files
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolve_srv_cont]
> (0x0100): Searching for servers via SRV query '_KERBEROS._udp.int.home.lan'
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [resolv_getsrv_send]
> (0x0100): Trying to resolve SRV record of '_KERBEROS._udp.int.home.lan'
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [set_srv_data_status]
> (0x0100): Marking SRV lookup of service 'KERBEROS' as 'resolved'
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [be_resolve_server_done] (0x0200): Found address for server
> vagrant-2008r2.int.home.lan: [192.168.3.2] TTL 3600
> (Fri May  2 08:45:01 2014) [[sssd[ldap_child[5745]]]]
> [select_principal_from_keytab] (0x0200): trying to select the most
> appropriate principal from keytab
> (Fri May  2 08:45:01 2014) [[sssd[ldap_child[5745]]]]
> [select_principal_from_keytab] (0x0200): Selected principal:
> CLIENT$@INT.HOME.LAN
> (Fri May  2 08:45:01 2014) [[sssd[ldap_child[5745]]]]
> [ldap_child_get_tgt_sync] (0x0100): Principal name is:
> [CLIENT$@INT.HOME.LAN]
> (Fri May  2 08:45:01 2014) [[sssd[ldap_child[5745]]]]
> [ldap_child_get_tgt_sync] (0x0200): Loaded 4 enctypes from keytab for
> CLIENT$@INT.HOME.LAN
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [sasl_bind_send]
> (0x0100): Executing sasl bind mech: GSSAPI, user: (null)
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [child_sig_handler]
> (0x0100): child [5745] finished successfully.
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [fo_set_port_status]
> (0x0100): Marking port 389 of server 'vagrant-2008r2.int.home.lan' as
> 'working'
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]]
> [set_server_common_status] (0x0100): Marking server
> 'vagrant-2008r2.int.home.lan' as 'working'

Backend authenticated with the server successfully. Here I would expect
to see the LDAP search for the user, is it not there?

> (Fri May  2 08:45:01 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [paul1 at INT.HOME.LAN]
> (Fri May  2 08:45:01 2014) [sssd[be[INT.HOME.LAN]]] [acctinfo_callback]
> (0x0100): Request processed. Returned 0,0,Success
> (Fri May  2 08:45:04 2014) [sssd] [service_send_ping] (0x0100): Pinging
> INT.HOME.LAN
> (Fri May  2 08:45:04 2014) [sssd] [service_send_ping] (0x0100): Pinging nss
> (Fri May  2 08:45:04 2014) [sssd] [service_send_ping] (0x0100): Pinging pam



More information about the sssd-users mailing list