Learn more about these different git repos.
Other Git URLs
Hello,
I am facing issues on a centos 7 workstation configured following this tutorial : https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
My sssd version is 1.13.0, and ad_gpo_access_control is set to disabled in my sssd.conf on the centos 7 workstation.
sssd-ad-1.13.0-40.el7_2.1.x86_64 krb5-libs-1.13.2-10.el7.x86_64
If I am using my AD account, I can only logon through ssh.
If I am tring to logon through lightdm or tty, session is resetted :
I am also using this sssd configuration with fedora 23, It is well working.
I attached logs when I try to logon through tty.
attachment tty.zip
I'm really curious that it works with ssh and does not work with tty. There is a issue in krb5_child.log.
(Fri Jan 15 14:53:38 2016) [[sssd[krb5_child[10698]]]] [sss_get_ccache_name_for_principal] (0x4000): Location: [FILE:/tmp/krb5cc_12069_XXXXXX] (Fri Jan 15 14:53:38 2016) [[sssd[krb5_child[10698]]]] [sss_get_ccache_name_for_principal] (0x2000): krb5_cc_cache_match failed: [-1765328243][Can't find client principal guigne@LMSAD.POLYTECHNIQUE.FR in cache collection] (Fri Jan 15 14:53:38 2016) [[sssd[krb5_child[10698]]]] [create_ccache] (0x0020): 735: [13][Permission denied] (Fri Jan 15 14:53:38 2016) [[sssd[krb5_child[10698]]]] [map_krb5_error] (0x0020): 1303: [1432158209][Unknown code UUz 1] (Fri Jan 15 14:53:38 2016) [[sssd[krb5_child[10698]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Fri Jan 15 14:53:38 2016) [[sssd[krb5_child[10698]]]] [pack_response_packet] (0x2000): response packet size: [20] (Fri Jan 15 14:53:38 2016) [[sssd[krb5_child[10698]]]] [k5c_send_data] (0x4000): Response sent. (Fri Jan 15 14:53:38 2016) [[sssd[krb5_child[10698]]]] [main] (0x0400): krb5_child completed successfully
Did you authenticate with password + ssh or with public_key or GSSAPI?
If it works with ssh + password please provide log files. Could you also attach sanitized /etc/krb5.conf?
cc: => lslebodn
I wonder if the permissions on /tmp are correct? Maybe stracing krb5 child would help.
I also wonder if ssh works because another authentication mechanism (pubkeys?) is used..
There is no public_key gssapi authentication. Only sssd vs ad authentication.
I attached my logs for ssh authentication, it is working.
Also add the krb5.conf
Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal
3 01/01/1970 01:00:00 host/leda-lms.lmsad.polytechnique.fr@LMSAD.POLYTECHNIQUE.FR 3 01/01/1970 01:00:00 host/leda-lms.lmsad.polytechnique.fr@LMSAD.POLYTECHNIQUE.FR 3 01/01/1970 01:00:00 host/leda-lms.lmsad.polytechnique.fr@LMSAD.POLYTECHNIQUE.FR 3 01/01/1970 01:00:00 host/leda-lms.lmsad.polytechnique.fr@LMSAD.POLYTECHNIQUE.FR 3 01/01/1970 01:00:00 host/leda-lms.lmsad.polytechnique.fr@LMSAD.POLYTECHNIQUE.FR 3 01/01/1970 01:00:00 LEDA-LMS$@LMSAD.POLYTECHNIQUE.FR 3 01/01/1970 01:00:00 LEDA-LMS$@LMSAD.POLYTECHNIQUE.FR 3 01/01/1970 01:00:00 LEDA-LMS$@LMSAD.POLYTECHNIQUE.FR 3 01/01/1970 01:00:00 LEDA-LMS$@LMSAD.POLYTECHNIQUE.FR 3 01/01/1970 01:00:00 LEDA-LMS$@LMSAD.POLYTECHNIQUE.FR
attachment ssh.zip
attachment kbr5.conf
...
drwxrwxrwt. 16 root root 4096 18 janv. 15:54 tmp
I can see the same issue with ccache in krb5_child.log
Could you try to use krb5 ccache in kernel keyring? Put following line into the section "[libdefaults]" in /etc/krb5.conf
default_ccache_name = KEYRING:persistent:%{uid}
I added it in krb5.conf :
... [libdefaults] default_realm = LMSAD.POLYTECHNIQUE.FR dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false
But get the same issues
I tried ssh -> works then tty -> fails
Please find the logs in attached parts for this test.
attachment ssh_tty_2.zip
Can you also share your PAM stack configuration?
Also, does kinit work?
As Jakub mention, could you test kinit on that machine
KRB5_TRACE=/dev/stderr kinit guigne@LMSAD.POLYTECHNIQUE.FR
Please find in attached parts the result of kinit and my /etc/pam.d/password-auth-ac /etc/pam.d/system-auth-ac
attachment kinit.txt
attachment system-auth-ac
attachment password-auth-ac
I used the command :
to set the pam files
May you tell me if the pam files are corrects ? Is it what you call the pam stack ?
Hello, I try the same sssd vs AD configuration on an other centos 7 workstation. I get the same issue for tty login or lightdm login.
But I noticed that the command :
was not enough to enable ssh login access In pam files system-auth-ac and password-auth-ac, references to krb5 were missing (in fedora, references to krb5 are in). To add them, the right command is :
With it, ssh login works But tty login and lightdm login still fails unfortunatly
What is missing in pam configuration for tty and lightdm ? Does the Fedora/RHEL procedure (https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server) can be applied to centos 7 ?
On the 2 centos 7 workstation, the command getent passwd user@... works So sssd service is correctly configured, should something missing in pam configuration for centos 7 ?
Best Regards
Replying to [comment:11 edg91]:
I used the command : authconfig --enablesssd --enablesssdauth --update to set the pam files I can see pam_krb5.so in your pam stack and it might explain why it works sometime even though pam_sss failed.
to set the pam files I can see pam_krb5.so in your pam stack and it might explain why it works sometime even though pam_sss failed.
If you want to remove pam_krb5.so it then you can call authconfig --disablekrb5 --update pam_sss.so shoudl be enough. If we solve this issue.
_comment0: Replying to [comment:11 edg91]:
If you want to remove pam_krb5.so it then you can call ''authconfig --disablekrb5 --update'' => 1453300913588905
I can see a difference between output of kinit (kinit.txt) and equivalent operation in sssd(krb5.child.log) kinit.txt:
[22702] 1453194079.23255: Getting initial credentials for guigne@LMSAD.POLYTECHNIQUE.FR
krb5_child.log:
[10698] 1452866018.310143: Getting initial credentials for guigne\@LMSAD.POLYTECHNIQUE.FR@LMSAD.POLYTECHNIQUE.FR
sssd tried to use enterprise principal.
We can also see that UPN was obtained from AD.
[sdap_save_user] (0x0400): Adding user principal [guigne@LMSAD.POLYTECHNIQUE.FR] to attributes of [guigne].
You might try to set attribute for user principal to non-existing attribute in domain section e.g.
ldap_user_principal = wrongAttribute
I hope it will help
OK finally find the problem
I set to 600 all files : /etc/sssd/sssd.conf, /etc/krb5.keytab, /etc/krb5.conf But the correct posix style is 600 /etc/sssd/sssd.conf and /etc/krb5.keytab
On fedora, 0600 for etc/krb5.conf works...
The correct authconfig command is :
or
The ticket can be closed.
Ahh, that's tricky issue. And the kinit worked because you tested it as root.
I would recommend to change permissions to 644 for krb5.conf also on fedora.
_comment0: Ahh, that's tricky issue. And the kinit worked because you tested it as root.
I would recommend to change permissions to 644 also on fedora. => 1453305624178338 owner: somebody => lslebodn
Fields changed
resolution: => worksforme status: new => closed
It took some time to find out root of the problem and it was not obvious from log files. It might be good to add debug message.
resolution: worksforme => status: closed => reopened
summary: sssd vs AD - authentication issue on centos 7 => Warn if user cannot read krb5.conf
priority: major => minor
patch: 0 => 1
The patch is easy, available and the bug if affecting our users, so moving to 1.13
milestone: NEEDS_TRIAGE => SSSD 1.13.4
rhbz: => todo
master:
sssd-1-13:
resolution: => fixed status: reopened => closed
rhbz: todo => 0
Metadata Update from @edg91: - Issue assigned to lslebodn - Issue set to the milestone: SSSD 1.13.4
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3972
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Log in to comment on this ticket.