#2931 Warn if user cannot read krb5.conf
Closed: Fixed None Opened 3 years ago by edg91.

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.

rpm -q sssd-ad krb5-libs

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 :

  • though lightdm xserver restarts, sssd log gives "sssd[krb5_child ... Unknown code UUz 1"
  • through tty I get a message "Cannot make/remove an entry for the specified session" message and a "sssd[krb5_child ... Permission denied"

I am also using this sssd configuration with fedora 23, It is well working.

I attached logs when I try to logon through tty.


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

klist -kt

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

ll /

...

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

default_ccache_name = KEYRING:persistent:%{uid}

But get the same issues

I tried ssh -> works
then tty -> fails

Please find the logs in attached parts for this test.

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

Hello,

Please find in attached parts the result of kinit and my /etc/pam.d/password-auth-ac /etc/pam.d/system-auth-ac

I used the command :

authconfig --enablesssd --enablesssdauth --update

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 :

authconfig --enablesssd --enablesssdauth --update

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 :

authconfig --enablesssd --enablesssdauth --enablekrb5 --update

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.

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]:

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.

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

644 /etc/krb5.conf

On fedora, 0600 for etc/krb5.conf works...

The correct authconfig command is :

authconfig --enablesssd --enablesssdauth --enablemkhomedir --update

or

authconfig --enablesssd --enablesssdauth --disableldap --disableldapauth --disablekrb5 --update

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

Fields changed

summary: sssd vs AD - authentication issue on centos 7 => Warn if user cannot read krb5.conf

Fields changed

priority: major => minor

Fields changed

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

Fields changed

rhbz: => todo

master:

sssd-1-13:

resolution: => fixed
status: reopened => closed

Fields changed

rhbz: todo => 0

Metadata Update from @edg91:
- Issue assigned to lslebodn
- Issue set to the milestone: SSSD 1.13.4

2 years ago

Login to comment on this ticket.

Metadata