Hello list,
this is my first try here.
I've a problem with a sssd_ad setup with a samba 4 ad domain.
Samba domain is created with rfc2307 scheme. sssd works, getent passwd shows users and groups with UNIX-attributes from the ad, but login is impossible.
The setup is based on openSUSE 13.1 with sssd updated to version 1.12 and the sernet samba packages version 4.1.11.
My sssd configuration:
-------------------------------------------------- [sssd] services = nss,pam config_file_version = 2 domains = invis-ad.loc debug_level = 5
[nss]
[pam]
[domain/invis-ad.loc] # Using id_provider=ad sets the best defaults on its own id_provider = ad # In sssd, the default access provider is always 'permit'. The AD access # provider by default checks for account expiration access_provider = ad
# Authentication auth_provider = ad
# Uncomment to use POSIX attributes on the server ldap_id_mapping = false
# Uncomment if the client machine hostname doesn't match the computer object on the DC. ad_hostname = invisad.invis-ad.loc
# Uncomment if DNS SRV resolution is not working ad_server = invisad.invis-ad.loc
# Uncomment if the domain section is named differently than your Samba domain ad_domain = invis-ad.loc
# Enumeration is discouraged for performance reasons. enumerate = true
--------------------------------------------------------------------------------------------------------------------------------- nsswitch.conf .... passwd compat sss group compat sss .....
----------------------------------------------------------------------------------------------------------------------
getent passwd:
.... hbecker:*:10000:10000:Heinz Becker:/home/hbecker:/bin/bash
This is exactly what is stored in the ad.
The pam configuration:
common-auth ------------------------------------------------------------------------------------------------------------------ #%PAM-1.0 auth required pam_env.so auth sufficient pam_unix.so try_first_pass auth sufficient pam_sss.so use_first_pass
common-account ------------------------------------------------------------------------------------------------------------------- #%PAM-1.0 account requisite pam_unix.so try_first_pass account sufficient pam_localuser.so account [default=bad success=ok user_unknown=ignore] pam_sss.so
common-password ------------------------------------------------------------------------------------------------------------------- password requisite pam_cracklib.so password sufficient pam_unix.so use_authtok nullok try_first_pass password sufficient pam_sss.so use_authtok
common-session -------------------------------------------------------------------------------------------------------------------- #%PAM-1.0 session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_sss.so session optional pam_umask.so session optional pam_systemd.so session optional pam_env.so
---------------------------------------------------------------------------------------------------------------------
Here the logs from different login tries:
1. non-existing user
2014-08-28T15:52:29.560167+02:00 invisad login: pam_unix(login:auth): check pass; user unknown 2014-08-28T15:52:29.560490+02:00 invisad login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= 2014-08-28T15:52:29.567475+02:00 invisad login: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=oierwe 2014-08-28T15:52:29.569417+02:00 invisad login: pam_sss(login:auth): received for user oierwe: 10 (User not known to the underlying authentication module) 2014-08-28T15:52:29.572497+02:00 invisad login: pam_unix(login:account): could not identify user (from getpwnam(oierwe)) 2014-08-28T15:52:29.573783+02:00 invisad login: User not known to the underlying authentication module
seems to be ok.
2. existing user, wrong password
2014-08-28T15:53:33.988971+02:00 invisad login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=hbecker 2014-08-28T15:53:34.090927+02:00 invisad [sssd[krb5_child[16213]]]: #020 2014-08-28T15:53:34.101970+02:00 invisad login: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=hbecker 2014-08-28T15:53:34.103406+02:00 invisad login: pam_sss(login:auth): received for user hbecker: 17 (Failure setting user credentials) 2014-08-28T15:53:34.104581+02:00 invisad login: pam_sss(login:account): Access denied for user hbecker: 4 (System error) 2014-08-28T15:53:34.105607+02:00 invisad login: System error
seems to be ok.
3. existing user, correct password:
2014-08-28T15:54:39.661506+02:00 invisad login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=hbecker 2014-08-28T15:54:39.780648+02:00 invisad [sssd[krb5_child[16218]]]: #020 2014-08-28T15:54:39.791159+02:00 invisad login: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=hbecker 2014-08-28T15:54:39.793320+02:00 invisad login: pam_sss(login:auth): received for user hbecker: 4 (System error) 2014-08-28T15:54:39.795032+02:00 invisad login: pam_sss(login:account): Access denied for user hbecker: 4 (System error) 2014-08-28T15:54:39.796398+02:00 invisad login: System error
2 times "system error", definitely not the expected result.
Any ideas?
With hope for help, regards
Stefan
On (28/08/14 16:00), Stefan Schäfer wrote:
Hello list,
this is my first try here.
I've a problem with a sssd_ad setup with a samba 4 ad domain.
Samba domain is created with rfc2307 scheme. sssd works, getent passwd shows users and groups with UNIX-attributes from the ad, but login is impossible.
The setup is based on openSUSE 13.1 with sssd updated to version 1.12 and the sernet samba packages version 4.1.11.
My sssd configuration:
[sssd] services = nss,pam config_file_version = 2 domains = invis-ad.loc debug_level = 5
[nss]
[pam]
[domain/invis-ad.loc] # Using id_provider=ad sets the best defaults on its own id_provider = ad # In sssd, the default access provider is always 'permit'. The AD access # provider by default checks for account expiration access_provider = ad
# Authentication auth_provider = ad
# Uncomment to use POSIX attributes on the server ldap_id_mapping = false
# Uncomment if the client machine hostname doesn't match the computer object on the DC. ad_hostname = invisad.invis-ad.loc
# Uncomment if DNS SRV resolution is not working ad_server = invisad.invis-ad.loc
# Uncomment if the domain section is named differently than your Samba domain ad_domain = invis-ad.loc
# Enumeration is discouraged for performance reasons. enumerate = true
nsswitch.conf .... passwd compat sss group compat sss .....
getent passwd:
.... hbecker:*:10000:10000:Heinz Becker:/home/hbecker:/bin/bash
This is exactly what is stored in the ad.
The pam configuration:
common-auth
#%PAM-1.0 auth required pam_env.so auth sufficient pam_unix.so try_first_pass auth sufficient pam_sss.so use_first_pass
common-account
#%PAM-1.0 account requisite pam_unix.so try_first_pass account sufficient pam_localuser.so account [default=bad success=ok user_unknown=ignore] pam_sss.so
common-password
password requisite pam_cracklib.so password sufficient pam_unix.so use_authtok nullok try_first_pass password sufficient pam_sss.so use_authtok
common-session
#%PAM-1.0 session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_sss.so session optional pam_umask.so session optional pam_systemd.so session optional pam_env.so
Here the logs from different login tries:
- non-existing user
2014-08-28T15:52:29.560167+02:00 invisad login: pam_unix(login:auth): check pass; user unknown 2014-08-28T15:52:29.560490+02:00 invisad login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= 2014-08-28T15:52:29.567475+02:00 invisad login: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=oierwe 2014-08-28T15:52:29.569417+02:00 invisad login: pam_sss(login:auth): received for user oierwe: 10 (User not known to the underlying authentication module) 2014-08-28T15:52:29.572497+02:00 invisad login: pam_unix(login:account): could not identify user (from getpwnam(oierwe)) 2014-08-28T15:52:29.573783+02:00 invisad login: User not known to the underlying authentication module
seems to be ok.
- existing user, wrong password
2014-08-28T15:53:33.988971+02:00 invisad login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=hbecker 2014-08-28T15:53:34.090927+02:00 invisad [sssd[krb5_child[16213]]]: #020 2014-08-28T15:53:34.101970+02:00 invisad login: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=hbecker 2014-08-28T15:53:34.103406+02:00 invisad login: pam_sss(login:auth): received for user hbecker: 17 (Failure setting user credentials) 2014-08-28T15:53:34.104581+02:00 invisad login: pam_sss(login:account): Access denied for user hbecker: 4 (System error)
sssd should not return 4 (System error).
Could you put debug_level = 7 into domain section (in /etc/sssd/sssd.conf) then restart sssd; login as samba user;
You should find a reason in sssd_invis-ad.loc.log file (/var/log/sssd) why sssd returned 4 (System error)
LS
On (28/08/14 16:13), Lukas Slebodnik wrote:
On (28/08/14 16:00), Stefan Schäfer wrote:
Hello list,
this is my first try here.
I've a problem with a sssd_ad setup with a samba 4 ad domain.
Samba domain is created with rfc2307 scheme. sssd works, getent passwd shows users and groups with UNIX-attributes from the ad, but login is impossible.
The setup is based on openSUSE 13.1 with sssd updated to version 1.12 and the sernet samba packages version 4.1.11.
My sssd configuration:
[sssd] services = nss,pam config_file_version = 2 domains = invis-ad.loc debug_level = 5
[nss]
[pam]
[domain/invis-ad.loc] # Using id_provider=ad sets the best defaults on its own id_provider = ad # In sssd, the default access provider is always 'permit'. The AD access # provider by default checks for account expiration access_provider = ad
# Authentication auth_provider = ad
# Uncomment to use POSIX attributes on the server ldap_id_mapping = false
# Uncomment if the client machine hostname doesn't match the computer object on the DC. ad_hostname = invisad.invis-ad.loc
# Uncomment if DNS SRV resolution is not working ad_server = invisad.invis-ad.loc
# Uncomment if the domain section is named differently than your Samba domain ad_domain = invis-ad.loc
# Enumeration is discouraged for performance reasons. enumerate = true
nsswitch.conf .... passwd compat sss group compat sss .....
getent passwd:
.... hbecker:*:10000:10000:Heinz Becker:/home/hbecker:/bin/bash
This is exactly what is stored in the ad.
The pam configuration:
common-auth
#%PAM-1.0 auth required pam_env.so auth sufficient pam_unix.so try_first_pass auth sufficient pam_sss.so use_first_pass
common-account
#%PAM-1.0 account requisite pam_unix.so try_first_pass account sufficient pam_localuser.so account [default=bad success=ok user_unknown=ignore] pam_sss.so
common-password
password requisite pam_cracklib.so password sufficient pam_unix.so use_authtok nullok try_first_pass password sufficient pam_sss.so use_authtok
common-session
#%PAM-1.0 session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_sss.so session optional pam_umask.so session optional pam_systemd.so session optional pam_env.so
Here the logs from different login tries:
- non-existing user
2014-08-28T15:52:29.560167+02:00 invisad login: pam_unix(login:auth): check pass; user unknown 2014-08-28T15:52:29.560490+02:00 invisad login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= 2014-08-28T15:52:29.567475+02:00 invisad login: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=oierwe 2014-08-28T15:52:29.569417+02:00 invisad login: pam_sss(login:auth): received for user oierwe: 10 (User not known to the underlying authentication module) 2014-08-28T15:52:29.572497+02:00 invisad login: pam_unix(login:account): could not identify user (from getpwnam(oierwe)) 2014-08-28T15:52:29.573783+02:00 invisad login: User not known to the underlying authentication module
seems to be ok.
- existing user, wrong password
2014-08-28T15:53:33.988971+02:00 invisad login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=hbecker 2014-08-28T15:53:34.090927+02:00 invisad [sssd[krb5_child[16213]]]: #020 2014-08-28T15:53:34.101970+02:00 invisad login: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=hbecker 2014-08-28T15:53:34.103406+02:00 invisad login: pam_sss(login:auth): received for user hbecker: 17 (Failure setting user credentials) 2014-08-28T15:53:34.104581+02:00 invisad login: pam_sss(login:account): Access denied for user hbecker: 4 (System error)
sssd should not return 4 (System error).
Could you put debug_level = 7 into domain section (in /etc/sssd/sssd.conf) then restart sssd; login as samba user;
You should find a reason in sssd_invis-ad.loc.log file (/var/log/sssd) why sssd returned 4 (System error)
For wrong pasword you should se something similar. [sssd[be[example.test]]] [simple_bind_done] (0x0400): Bind result: Invalid credentials(49), no errmsg set [sssd[be[example.test]]] [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password migration not possible. [sssd[be[example.test]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, <NULL>) [Success] [sssd[be[example.test]]] [be_pam_handler_callback] (0x0100): Sending result [8][example.test] [sssd[be[example.test]]] [be_pam_handler_callback] (0x0100): Sent result [8][example.test] ^^^ value of pam error code
LS
Am 28.08.2014 16:18, schrieb Lukas Slebodnik:
Could you put debug_level = 7 into domain section (in /etc/sssd/sssd.conf) then restart sssd; login as samba user;
You should find a reason in sssd_invis-ad.loc.log file (/var/log/sssd) why sssd returned 4 (System error)
I increased the debug_level to 7, but in the sssd_invis-ad.loc.log didn't appear a single entry.
The same is to the other log files sssd_pam.log and sssd_nss.log. The only log are these in /var/log/messages.
Seems that for sssd everything is ok and pam causes the problem?
Stefan
On 28/08/14 15:41, Stefan Schäfer wrote:
Am 28.08.2014 16:18, schrieb Lukas Slebodnik:
Could you put debug_level = 7 into domain section (in
/etc/sssd/sssd.conf)
then restart sssd; login as samba user;
You should find a reason in sssd_invis-ad.loc.log file (/var/log/sssd) why sssd returned 4 (System error)
I increased the debug_level to 7, but in the sssd_invis-ad.loc.log didn't appear a single entry.
The same is to the other log files sssd_pam.log and sssd_nss.log. The only log are these in /var/log/messages.
Seems that for sssd everything is ok and pam causes the problem?
Stefan
You need to put the debug level into each section of the sssd.conf, not just once.
Rowland
Am 28.08.2014 16:44, schrieb Rowland Penny:
On 28/08/14 15:41, Stefan Schäfer wrote:
Am 28.08.2014 16:18, schrieb Lukas Slebodnik:
Could you put debug_level = 7 into domain section (in
/etc/sssd/sssd.conf)
then restart sssd; login as samba user;
You should find a reason in sssd_invis-ad.loc.log file (/var/log/sssd) why sssd returned 4 (System error)
I increased the debug_level to 7, but in the sssd_invis-ad.loc.log didn't appear a single entry.
The same is to the other log files sssd_pam.log and sssd_nss.log. The only log are these in /var/log/messages.
Seems that for sssd everything is ok and pam causes the problem?
Stefan
You need to put the debug level into each section of the sssd.conf, not just once.
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
OK, look better ;-)
Here's the log extract:
(Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=hbecker] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [be_req_set_domain] (0x0400): Changing request domain from [invis-ad.loc] to [invis-ad.loc] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [DC=invis-ad,DC=loc] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=hbecker)(objectclass=user)(sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0))))][DC=invis-ad,DC=loc]. (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=Heinz Becker,CN=Users,DC=invis-ad,DC=loc]. (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_search_user_process] (0x0400): Search for users, returned 1 results. (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_save_user] (0x0400): Save user (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_get_primary_name] (0x0400): Processing object hbecker (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_save_user] (0x0400): Processing user hbecker (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_save_user] (0x0400): Original memberOf is not available for [hbecker]. (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_save_user] (0x0400): Adding user principal [hbecker@INVIS-AD.LOC] to attributes of [hbecker]. (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [sdap_save_user] (0x0400): Storing info for user hbecker (Thu Aug 28 16:51:23 2014) [sssd[be[invis-ad.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [be_get_account_info] (0x0100): Got request for [3][1][name=hbecker] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [be_req_set_domain] (0x0400): Changing request domain from [invis-ad.loc] to [invis-ad.loc] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [DC=invis-ad,DC=loc] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=hbecker)(objectclass=user)(&(uidNumber=*)(!(uidNumber=0))))][DC=invis-ad,DC=loc]. (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=Heinz Becker,CN=Users,DC=invis-ad,DC=loc]. (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_save_user] (0x0400): Save user (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_primary_name] (0x0400): Processing object hbecker (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_save_user] (0x0400): Processing user hbecker (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_save_user] (0x0400): Original memberOf is not available for [hbecker]. (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_save_user] (0x0400): Adding user principal [hbecker@INVIS-AD.LOC] to attributes of [hbecker]. (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_save_user] (0x0400): Storing info for user hbecker (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter][CN=Heinz Becker,CN=Users,DC=invis-ad,DC=loc]. (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [tokenGroups] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=Heinz Becker,CN=Users,DC=invis-ad,DC=loc]. (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_ad_tokengroups_initgr_posix_tg_done] (0x1000): Processing membership SID [S-1-5-21-2977797608-3586008738-4122126317-513] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_ad_tokengroups_initgr_posix_tg_done] (0x1000): Processing membership SID [S-1-5-32-545] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_ad_tokengroups_initgr_posix_tg_done] (0x0080): Domain not found for SID S-1-5-32-545 (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for [hbecker] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [DC=invis-ad,DC=loc] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(gidNumber=10000)(objectclass=group)(name=*)(&(gidNumber=*)(!(gidNumber=0))))][DC=invis-ad,DC=loc]. (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [groupType] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=Domain Users,CN=Users,DC=invis-ad,DC=loc]. (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_groups_process] (0x0400): Search for groups, returned 1 results. (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_has_deref_support] (0x0400): The server supports deref method ASQ (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_nested_group_recv] (0x0400): 0 users found in the hash table (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_nested_group_recv] (0x0400): 1 groups found in the hash table (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_primary_name] (0x0400): Processing object Domain Users (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_save_group] (0x0400): Processing group Domain Users (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_process_ghost_members] (0x0400): The group has 0 members (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_process_ghost_members] (0x0400): Group has 0 members (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_save_group] (0x0400): Storing info for group Domain Users (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_get_primary_name] (0x0400): Processing object Domain Users (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_save_grpmem] (0x0400): Processing group Domain Users (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [sdap_save_grpmem] (0x0400): Adding member users to group [Domain Users] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [be_req_set_domain] (0x0400): Changing request domain from [invis-ad.loc] to [invis-ad.loc] (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [be_pam_handler] (0x0100): Got request with the following data (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): domain: invis-ad.loc (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): user: hbecker (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): service: login (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): tty: tty2 (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): ruser: (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): rhost: (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): authtok type: 1 (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): priv: 1 (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): cli_pid: 18269 (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [krb5_pam_handler] (0x1000): Wait queue of user [hbecker] is empty, running request immediately. (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [switch_creds] (0x0200): Switch user to [10000][10000]. (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [switch_creds] (0x0200): Switch user to [0][0]. (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [get_server_status] (0x1000): Status of server 'invisad.invis-ad.loc' is 'working' (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [get_port_status] (0x1000): Port status of port 0 for server 'invisad.invis-ad.loc' is 'working' (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [get_server_status] (0x1000): Status of server 'invisad.invis-ad.loc' is 'working' (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [be_resolve_server_process] (0x0200): Found address for server invisad.invis-ad.loc: [192.168.201.10] TTL 7200 (Thu Aug 28 16:51:27 2014) [sssd[be[invis-ad.loc]]] [write_pipe_handler] (0x0400): All data has been sent! (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [read_pipe_handler] (0x0400): EOF received, client finished (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [check_wait_queue] (0x1000): Wait queue for user [hbecker] is empty. (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [be_pam_handler_callback] (0x0100): Sending result [4][invis-ad.loc] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [be_pam_handler_callback] (0x0100): Sent result [4][invis-ad.loc] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [be_req_set_domain] (0x0400): Changing request domain from [invis-ad.loc] to [invis-ad.loc] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [be_pam_handler] (0x0100): Got request with the following data (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): domain: invis-ad.loc (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): user: hbecker (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): service: login (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): tty: tty2 (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): ruser: (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): rhost: (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): authtok type: 0 (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): priv: 1 (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [pam_print_data] (0x0100): cli_pid: 18269 (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [sdap_access_send] (0x0400): Performing access check for user [hbecker] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [sdap_account_expired_ad] (0x0400): Performing AD access check for user [hbecker] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [ad_gpo_connect_done] (0x0400): sam_account_name is invisad.invis-ad.loc$ (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=user)(sAMAccountName=invisad.invis-ad.loc$))][dc=invis-ad,dc=loc]. (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [distinguishedName] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [ad_gpo_target_dn_retrieval_done] (0x0040): No DN retrieved for policy target. (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed. (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, No such file or directory) [Internal Error (System error)] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [be_pam_handler_callback] (0x0100): Sending result [4][invis-ad.loc] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [be_pam_handler_callback] (0x0100): Sent result [4][invis-ad.loc] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [child_sig_handler] (0x1000): Waiting for child [18288]. (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [child_sig_handler] (0x0100): child [18288] finished successfully.
Seems that there is a problem with Group-Policies. I haven’t set any Group-Policies.
Any Idea how to get this working?
Stefan
On (28/08/14 16:56), Stefan Schäfer wrote:
Am 28.08.2014 16:44, schrieb Rowland Penny:
On 28/08/14 15:41, Stefan Schäfer wrote:
Am 28.08.2014 16:18, schrieb Lukas Slebodnik:
Could you put debug_level = 7 into domain section (in
/etc/sssd/sssd.conf)
then restart sssd; login as samba user;
You should find a reason in sssd_invis-ad.loc.log file (/var/log/sssd) why sssd returned 4 (System error)
I increased the debug_level to 7, but in the sssd_invis-ad.loc.log didn't appear a single entry.
The same is to the other log files sssd_pam.log and sssd_nss.log. The only log are these in /var/log/messages.
Seems that for sssd everything is ok and pam causes the problem?
Stefan
You need to put the debug level into each section of the sssd.conf, not just once.
Rowland
//snip
(0x0400): Performing access check for user [hbecker] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [sdap_account_expired_ad] (0x0400): Performing AD access check for user [hbecker] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [ad_gpo_connect_done] (0x0400): sam_account_name is invisad.invis-ad.loc$ (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=user)(sAMAccountName=invisad.invis-ad.loc$))][dc=invis-ad,dc=loc]. (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [distinguishedName] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [ad_gpo_target_dn_retrieval_done] (0x0040): No DN retrieved for policy target. (Thu Aug 28 16:51:28 2014) [sssd[be[invis-ad.loc]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.
I thought it. There is problem with retrieving GPO from samba.
there was bug in 1.12.0 that access control from GPO in permissive did not work.
You can try to disable GPO:
ad_gpo_access_control = disabled
LS
On Thu, 2014-08-28 at 16:56 +0200, Stefan Schäfer wrote: .
Any Idea how to get this working?
We think your stack is wrong. Here is one which works:
auth sufficient pam_unix2.so auth required pam_sss.so use_first_pass account requisite pam_unix2.so account sufficient pam_localuser.so account required pam_sss.so use_first_pass
Do you have the order right?
Am 28.08.2014 17:11, schrieb steve:
On Thu, 2014-08-28 at 16:56 +0200, Stefan Schäfer wrote: .
Any Idea how to get this working?
We think your stack is wrong. Here is one which works:
auth sufficient pam_unix2.so auth required pam_sss.so use_first_pass account requisite pam_unix2.so account sufficient pam_localuser.so account required pam_sss.so use_first_pass
Do you have the order right?
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
PAM works. The problem was caused by a bug in sssd 1.12. "ad_gpo_access_control = disabled" solved the problem.
Stefan
On Thu, 28 Aug 2014, Stefan Schäfer wrote:
PAM works. The problem was caused by a bug in sssd 1.12. "ad_gpo_access_control = disabled" solved the problem.
Sure, glad you found a fix. Unless you've a good reason not to, I'd always advise setting up your pam stack via authconfig, that way you can reasonably assume it's correct.
jh
Am 28.08.2014 17:28, schrieb John Hodrien:
Sure, glad you found a fix. Unless you've a good reason not to, I'd always advise setting up your pam stack via authconfig, that way you can reasonably assume it's correct.
authconfig is part of fedora and red hat, but not of openSUSE and sles. Here you have to configure this with yast or by hand. YaST didn't know anything about sssd_ad yet.
Stefan
On (28/08/14 16:41), Stefan Schäfer wrote:
Am 28.08.2014 16:18, schrieb Lukas Slebodnik:
Could you put debug_level = 7 into domain section (in /etc/sssd/sssd.conf) then restart sssd; login as samba user;
You should find a reason in sssd_invis-ad.loc.log file (/var/log/sssd) why sssd returned 4 (System error)
I increased the debug_level to 7, but in the sssd_invis-ad.loc.log didn't appear a single entry.
The same is to the other log files sssd_pam.log and sssd_nss.log. The only log are these in /var/log/messages.
Seems that for sssd everything is ok and pam causes the problem?
I don't think so.
Are you sure you did not see similar line? [sssd[be[invis-ad.loc]]] [be_pam_handler_callback] (0x0100): Sent result [4][invis-ad.loc]
yuo can try to search name of function (be_pam_handler_callback)
LS
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
John Hodrien -
Lukas Slebodnik -
Rowland Penny -
Stefan Schäfer -
steve