9 a.m.
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
--
www.invis-server.org
Stefan Schäfer
Ludwigstr. 1-3
63679 Schotten
9:13 a.m.
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:
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)
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
9:18 a.m.
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:
>
>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)
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
9:41 a.m.
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
--
www.invis-server.org
Stefan Schäfer
Ludwigstr. 1-3
63679 Schotten
9:44 a.m.
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
9:49 a.m.
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
9:56 a.m.
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(a)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(a)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(a)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
--
www.invis-server.org
Stefan Schäfer
Ludwigstr. 1-3
63679 Schotten
10:05 a.m.
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
10:11 a.m.
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?
10:15 a.m.
Am 28.08.2014 17:05, schrieb Lukas Slebodnik:
You can try to disable GPO:
ad_gpo_access_control = disabled
LS
That's it!
Thanks a lot.
Stefan
--
www.invis-server.org
Stefan Schäfer
Ludwigstr. 1-3
63679 Schotten
10:20 a.m.
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(a)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
--
www.invis-server.org
Stefan Schäfer
Ludwigstr. 1-3
63679 Schotten
10:28 a.m.
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
10:38 a.m.
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
--
www.invis-server.org
Stefan Schäfer
Ludwigstr. 1-3
63679 Schotten
11 a.m.
Am 28.08.2014 17:41, schrieb John Hodrien:
Perhaps pam-config?
Your point ;-)
Stefan
--
www.invis-server.org
Stefan Schäfer
Ludwigstr. 1-3
63679 Schotten
3528
days inactive
3528
days old
sssd-users@lists.fedorahosted.org
16 comments
6 participants
participants (6)
-
Jakub Hrozek -
John Hodrien -
Lukas Slebodnik -
Rowland Penny -
Stefan Schäfer -
steve