Hi all,
I just upgraded more servers, and doing some tests I found that my setup for kerberos/ldap authentication against Active Directory is no more working. I don't know why... I followed some times ago scott Lowe blog for this setup : http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/
And it was working correctly until the upgrade. What is curious is that id command and getent passwd works correctly : # id pean uid=9808(pean) gid=5027(ida) groupes=5027(ida),10(wheel),100(users),5024(info)
# getent passwd |grep pean pean:*:9808:5027:pean:/home/pean:/bin/bash
'pean' es an AD account. But when I try to autenticate, even locally :
So LDAP is correctly found. It is the password that seems problematic...
]$ su - pean Mot de passe : Mot de passe : su: incorrect password
Here is the content of my system-auth-ac pam module : ]$ cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth sufficient pam_krb5.so auth required pam_deny.so
account sufficient pam_unix.so account sufficient pam_krb5.so account sufficient pam_succeed_if.so uid < 100 quiet account required pam_deny.so
password requisite pam_cracklib.so retry=3 password sufficient pam_unix.so nullok use_authtok md5 shadow password required pam_deny.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 session required pam_limits.so session required pam_unix.so
Has anyone an idea where to look ? I noticed that 5.6 introduced sssd, and I know that in RHEL 6.0 TLS/SSL authentication is mandatory for LDAP authentication...
Thans for the help.
Alain
Le 10/04/2011 17:31, Alain Péan a écrit :
Hi all,
I just upgraded more servers, and doing some tests I found that my setup for kerberos/ldap authentication against Active Directory is no more working. I don't know why... I followed some times ago scott Lowe blog for this setup : http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/
And it was working correctly until the upgrade. What is curious is that id command and getent passwd works correctly : # id pean uid=9808(pean) gid=5027(ida) groupes=5027(ida),10(wheel),100(users),5024(info)
# getent passwd |grep pean pean:*:9808:5027:pean:/home/pean:/bin/bash
'pean' es an AD account. But when I try to autenticate, even locally :
So LDAP is correctly found. It is the password that seems problematic...
]$ su - pean Mot de passe : Mot de passe : su: incorrect password
Here is the content of my system-auth-ac pam module : ]$ cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth sufficient pam_krb5.so auth required pam_deny.so
account sufficient pam_unix.so account sufficient pam_krb5.so account sufficient pam_succeed_if.so uid< 100 quiet account required pam_deny.so
password requisite pam_cracklib.so retry=3 password sufficient pam_unix.so nullok use_authtok md5 shadow password required pam_deny.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 session required pam_limits.so session required pam_unix.so
Has anyone an idea where to look ? I noticed that 5.6 introduced sssd, and I know that in RHEL 6.0 TLS/SSL authentication is mandatory for LDAP authentication...
Thans for the help.
Alain
After further verification, it seems to be related to ticket granting. Here is what I have in /var/log/messages : su: pam_krb5[7200]: TGT failed verification using keytab and key for 'host/bardeen.lab-lpp.local@LAB-LPP.LOCAL': Cannot find ticket for requested realm
Alain
On Sun, 10 Apr 2011, Alain Péan wrote:
After further verification, it seems to be related to ticket granting. Here is what I have in /var/log/messages : su: pam_krb5[7200]: TGT failed verification using keytab and key for 'host/bardeen.lab-lpp.local@LAB-LPP.LOCAL': Cannot find ticket for requested realm
I've yet to do a full upgrade to 5.6, but I have upgraded pam_krb5 to peek at this, and it works fine for me (tested against 2003 and 2008 DCs).
Contents of your /etc/krb5.conf and the output of 'klist -ke' could be instructive.
jh
Le 12/04/2011 13:46, John Hodrien a écrit :
On Sun, 10 Apr 2011, Alain Péan wrote:
After further verification, it seems to be related to ticket granting. Here is what I have in /var/log/messages : su: pam_krb5[7200]: TGT failed verification using keytab and key for 'host/bardeen.lab-lpp.local@LAB-LPP.LOCAL': Cannot find ticket for requested realm
I've yet to do a full upgrade to 5.6, but I have upgraded pam_krb5 to peek at this, and it works fine for me (tested against 2003 and 2008 DCs).
Contents of your /etc/krb5.conf and the output of 'klist -ke' could be instructive.
jh
Hi John,
Thnks for your answer. Here are the content of /etc/krb5.conf and klist -ke. I agree that there can be siomething missing, that was working before...
]# cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5lib.log
[libdefaults] ticket_lifetime = 24000 default_realm = LAB-LPP.LOCAL default_tk_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc dns_lookup_realm = true dns_lookup_kdc = true
[realms] LAB-LPP.LOCAL = { kdc = pc-lpp1.lab-lpp.local:88 kdc = pc-lpp2.lab-lpp.local:88 kdc = pc-lpp3.lab-lpp.local:88 kdc = pc-lpp4.lab-lpp.local:88 kdc = pc-lppx.lab-lpp.local:88 admin_server = pc-lpp1.lab-lpp.local:749 default_domain = LAB-LPP.LOCAL }
[domain_realm] .lab-lpp.local = LAB-LPP.LOCAL lab-lpp.local = LAB-LPP.LOCAL
and : ]# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 HOST/centos-test.test-lpp.local@TEST-LPP.LOCAL (DES cbc mode with CRC-32) 2 host/centos-test.test-lpp.local@TEST-LPP.LOCAL (DES cbc mode with CRC-32) 2 host/centos-test.test-lpp.local@TEST-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 host/centos-test.test-lpp.local@TEST-LPP.LOCAL (ArcFour with HMAC/md5) 2 host/centos-test@TEST-LPP.LOCAL (DES cbc mode with CRC-32) 2 host/centos-test@TEST-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 host/centos-test@TEST-LPP.LOCAL (ArcFour with HMAC/md5) 2 CENTOS-TEST$@TEST-LPP.LOCAL (DES cbc mode with CRC-32) 2 CENTOS-TEST$@TEST-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 CENTOS-TEST$@TEST-LPP.LOCAL (ArcFour with HMAC/md5) 2 HOST/centos-test.test-lpp.local@TEST-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 HOST/centos-test.test-lpp.local@TEST-LPP.LOCAL (ArcFour with HMAC/md5) 2 HOST/centos-test@TEST-LPP.LOCAL (DES cbc mode with CRC-32) 2 HOST/centos-test@TEST-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 HOST/centos-test@TEST-LPP.LOCAL (ArcFour with HMAC/md5)
It is a local domain because it spans multiple real DNS domains.
Alain
Le 12/04/2011 14:35, Alain Péan a écrit :
Le 12/04/2011 13:46, John Hodrien a écrit :
On Sun, 10 Apr 2011, Alain Péan wrote:
After further verification, it seems to be related to ticket granting. Here is what I have in /var/log/messages : su: pam_krb5[7200]: TGT failed verification using keytab and key for 'host/bardeen.lab-lpp.local@LAB-LPP.LOCAL': Cannot find ticket for requested realm
I've yet to do a full upgrade to 5.6, but I have upgraded pam_krb5 to peek at this, and it works fine for me (tested against 2003 and 2008 DCs).
Contents of your /etc/krb5.conf and the output of 'klist -ke' could be instructive.
jh
Hi John,
Thnks for your answer. Here are the content of /etc/krb5.conf and klist -ke. I agree that there can be siomething missing, that was working before...
]# cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5lib.log
[libdefaults] ticket_lifetime = 24000 default_realm = LAB-LPP.LOCAL default_tk_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc dns_lookup_realm = true dns_lookup_kdc = true
[realms] LAB-LPP.LOCAL = { kdc = pc-lpp1.lab-lpp.local:88 kdc = pc-lpp2.lab-lpp.local:88 kdc = pc-lpp3.lab-lpp.local:88 kdc = pc-lpp4.lab-lpp.local:88 kdc = pc-lppx.lab-lpp.local:88 admin_server = pc-lpp1.lab-lpp.local:749 default_domain = LAB-LPP.LOCAL }
[domain_realm] .lab-lpp.local = LAB-LPP.LOCAL lab-lpp.local = LAB-LPP.LOCAL
and : ]# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal
2 HOST/centos-test.test-lpp.local@TEST-LPP.LOCAL (DES cbc mode withCRC-32) 2 host/centos-test.test-lpp.local@TEST-LPP.LOCAL (DES cbc mode with CRC-32) 2 host/centos-test.test-lpp.local@TEST-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 host/centos-test.test-lpp.local@TEST-LPP.LOCAL (ArcFour with HMAC/md5) 2 host/centos-test@TEST-LPP.LOCAL (DES cbc mode with CRC-32) 2 host/centos-test@TEST-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 host/centos-test@TEST-LPP.LOCAL (ArcFour with HMAC/md5) 2 CENTOS-TEST$@TEST-LPP.LOCAL (DES cbc mode with CRC-32) 2 CENTOS-TEST$@TEST-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 CENTOS-TEST$@TEST-LPP.LOCAL (ArcFour with HMAC/md5) 2 HOST/centos-test.test-lpp.local@TEST-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 HOST/centos-test.test-lpp.local@TEST-LPP.LOCAL (ArcFour with HMAC/md5) 2 HOST/centos-test@TEST-LPP.LOCAL (DES cbc mode with CRC-32) 2 HOST/centos-test@TEST-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 HOST/centos-test@TEST-LPP.LOCAL (ArcFour with HMAC/md5)
It is a local domain because it spans multiple real DNS domains.
Alain
Sorrry, little error with the output of klit -ke, because I am testing on a test AD domain at this moment. On the first machine, output is : # klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 host/appleton.lab-lpp.local@LAB-LPP.LOCAL (DES cbc mode with CRC-32) 2 host/appleton.lab-lpp.local@LAB-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 host/appleton.lab-lpp.local@LAB-LPP.LOCAL (ArcFour with HMAC/md5) 2 host/appleton@LAB-LPP.LOCAL (DES cbc mode with CRC-32) 2 host/appleton@LAB-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 host/appleton@LAB-LPP.LOCAL (ArcFour with HMAC/md5) 2 APPLETON$@LAB-LPP.LOCAL (DES cbc mode with CRC-32) 2 APPLETON$@LAB-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 APPLETON$@LAB-LPP.LOCAL (ArcFour with HMAC/md5)
Alain
On Tue, 12 Apr 2011, Alain Péan wrote:
Sorrry, little error with the output of klit -ke, because I am testing on a test AD domain at this moment. On the first machine, output is : # klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal
2 host/appleton.lab-lpp.local@LAB-LPP.LOCAL (DES cbc mode with CRC-32) 2 host/appleton.lab-lpp.local@LAB-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 host/appleton.lab-lpp.local@LAB-LPP.LOCAL (ArcFour with HMAC/md5) 2 host/appleton@LAB-LPP.LOCAL (DES cbc mode with CRC-32) 2 host/appleton@LAB-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 host/appleton@LAB-LPP.LOCAL (ArcFour with HMAC/md5) 2 APPLETON$@LAB-LPP.LOCAL (DES cbc mode with CRC-32) 2 APPLETON$@LAB-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 APPLETON$@LAB-LPP.LOCAL (ArcFour with HMAC/md5)
You're still lightly mixing machines though, as your error before referred to 'bardeen' not appleton. I'm not certain that I've seen a complete picture here.
I think disabling validate would still get you back to your old behaviour, but that there's something wrong with the keytabs on these machines.
jh
Le 12/04/2011 16:28, John Hodrien a écrit :
On Tue, 12 Apr 2011, Alain Péan wrote:
Sorrry, little error with the output of klit -ke, because I am testing on a test AD domain at this moment. On the first machine, output is : # klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal
2 host/appleton.lab-lpp.local@LAB-LPP.LOCAL (DES cbc mode with CRC-32) 2 host/appleton.lab-lpp.local@LAB-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 host/appleton.lab-lpp.local@LAB-LPP.LOCAL (ArcFour with HMAC/md5) 2 host/appleton@LAB-LPP.LOCAL (DES cbc mode with CRC-32) 2 host/appleton@LAB-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 host/appleton@LAB-LPP.LOCAL (ArcFour with HMAC/md5) 2 APPLETON$@LAB-LPP.LOCAL (DES cbc mode with CRC-32) 2 APPLETON$@LAB-LPP.LOCAL (DES cbc mode with RSA-MD5) 2 APPLETON$@LAB-LPP.LOCAL (ArcFour with HMAC/md5)
You're still lightly mixing machines though, as your error before referred to 'bardeen' not appleton. I'm not certain that I've seen a complete picture here.
I think disabling validate would still get you back to your old behaviour, but that there's something wrong with the keytabs on these machines.
jh
John,
Thanks for your hint. You are true that error message and 'klist -ke' come from different servers.
In fact, I solved the problem using the authconfig command, but I wonder if it is really correct, as I mixed kerberos and ldap. Here is the authconfig command for my test domain :
# authconfig --enablekrb5 --krb5kdc=pc-2003-test.test-lpp.local,dc1-test.test-lpp.local --krb5adminserver=pc-2003-test.test-lpp.local --krb5realm=TEST-LPP.LOCAL --enablekrb5kdcdns --enablekrb5realmdns --enableldap --enableldapauth --ldapserver=pc-2003-test.test-lpp.local,dc1-test.test-lpp.local --ldapbasedn="dc=test-lpp,dc=local" --enablemkhomedir --update
My /etc/krb5.conf is then the following : ]# cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5lib.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults] ticket_lifetime = 24000 default_realm = TEST-LPP.LOCAL default_tk_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc dns_lookup_realm = true dns_lookup_kdc = true
[realms] TEST-LPP.LOCAL = { kdc = pc-2003-test.test-lpp.local kdc = dc1-test.test-lpp.local admin_server = pc-2003-test.test-lpp.local default_domain = TEST-LPP.LOCAL kpasswd_server = pc-2003-test.test-lpp.local kdc = * }
[domain_realm] .test-lpp.local = TEST-LPP.LOCAL test-lpp.local = TEST-LPP.LOCAL
[kdc] profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }
But both kerberos and ldap appear in /etc/pam.d/system-auth-ac : # cat /etc/pam.d/system-auth-ac #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_krb5.so use_first_pass auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account [default=bad success=ok user_unknown=ignore] pam_krb5.so account required pam_permit.so
password requisite pam_cracklib.so retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_krb5.so use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so skel=/etc/skel/ umask=0022 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_krb5.so session optional pam_ldap.so
I tried to remove the lines with pam_ldap.so and adding in /etc/krb5.conf, as you suggested : [appdefaults] pam = { novalidate = true }
But it failed.
With the authconfig configuration, I can authenticate against Active Directory.
So, it works now, but I am not sure it is completly correct.
Thanks for your help !
Alain
On Tue, 12 Apr 2011, Alain Péan wrote:
In fact, I solved the problem using the authconfig command, but I wonder if it is really correct, as I mixed kerberos and ldap. Here is the authconfig command for my test domain :
Using kerberos and ldap is a perfectly reasonable thing to want to do, but you need to be sure you're doing what you want.
# authconfig --enablekrb5 --krb5kdc=pc-2003-test.test-lpp.local,dc1-test.test-lpp.local --krb5adminserver=pc-2003-test.test-lpp.local --krb5realm=TEST-LPP.LOCAL --enablekrb5kdcdns --enablekrb5realmdns --enableldap --enableldapauth --ldapserver=pc-2003-test.test-lpp.local,dc1-test.test-lpp.local --ldapbasedn="dc=test-lpp,dc=local" --enablemkhomedir --update
I'd have thought you want kerberos authentication and ldap user information. --enableldapauth I suspect is wrong. You've switched your kerberos REALM from the original file you mailed.
My /etc/krb5.conf is then the following : ]# cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5lib.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults] ticket_lifetime = 24000 default_realm = TEST-LPP.LOCAL default_tk_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc dns_lookup_realm = true dns_lookup_kdc = true
[realms] TEST-LPP.LOCAL = { kdc = pc-2003-test.test-lpp.local kdc = dc1-test.test-lpp.local admin_server = pc-2003-test.test-lpp.local default_domain = TEST-LPP.LOCAL kpasswd_server = pc-2003-test.test-lpp.local kdc = * }
[domain_realm] .test-lpp.local = TEST-LPP.LOCAL test-lpp.local = TEST-LPP.LOCAL
[kdc] profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }
That now looks plausible given what you mailed for the keytab (i.e. the realms match now).
But both kerberos and ldap appear in /etc/pam.d/system-auth-ac :
That's because you enabled ldap auth. You probably don't want that.
I tried to remove the lines with pam_ldap.so and adding in /etc/krb5.conf, as you suggested : [appdefaults] pam = { novalidate = true }
But it failed.
Assuming the keytab setup is the same is was before, you shouldn't need to bother with that. I think it should have been validate = false rather than novalidate = true, I'd misunderstood the manpage.
But if you leave that off, what fails now?
jh
Le 12/04/2011 18:29, John Hodrien a écrit :
On Tue, 12 Apr 2011, Alain Péan wrote:
In fact, I solved the problem using the authconfig command, but I wonder if it is really correct, as I mixed kerberos and ldap. Here is the authconfig command for my test domain :
Using kerberos and ldap is a perfectly reasonable thing to want to do, but you need to be sure you're doing what you want.
# authconfig --enablekrb5 --krb5kdc=pc-2003-test.test-lpp.local,dc1-test.test-lpp.local --krb5adminserver=pc-2003-test.test-lpp.local --krb5realm=TEST-LPP.LOCAL --enablekrb5kdcdns --enablekrb5realmdns --enableldap --enableldapauth --ldapserver=pc-2003-test.test-lpp.local,dc1-test.test-lpp.local --ldapbasedn="dc=test-lpp,dc=local" --enablemkhomedir --update
I'd have thought you want kerberos authentication and ldap user information. --enableldapauth I suspect is wrong. You've switched your kerberos REALM from the original file you mailed.
My /etc/krb5.conf is then the following : ]# cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5lib.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults] ticket_lifetime = 24000 default_realm = TEST-LPP.LOCAL default_tk_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc dns_lookup_realm = true dns_lookup_kdc = true
[realms] TEST-LPP.LOCAL = { kdc = pc-2003-test.test-lpp.local kdc = dc1-test.test-lpp.local admin_server = pc-2003-test.test-lpp.local default_domain = TEST-LPP.LOCAL kpasswd_server = pc-2003-test.test-lpp.local kdc = * }
[domain_realm] .test-lpp.local = TEST-LPP.LOCAL test-lpp.local = TEST-LPP.LOCAL
[kdc] profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }
That now looks plausible given what you mailed for the keytab (i.e. the realms match now).
But both kerberos and ldap appear in /etc/pam.d/system-auth-ac :
That's because you enabled ldap auth. You probably don't want that.
I tried to remove the lines with pam_ldap.so and adding in /etc/krb5.conf, as you suggested : [appdefaults] pam = { novalidate = true }
But it failed.
Assuming the keytab setup is the same is was before, you shouldn't need to bother with that. I think it should have been validate = false rather than novalidate = true, I'd misunderstood the manpage.
But if you leave that off, what fails now?
jh
Indeed, nothing fails now. I want my users to authenticate against Active directory, and it works, and I would like them to be able to use their kerberos credentials, if they need, to access domain ressources, as shares. But I have still to see a problem there..
Thanks again for your help and your comments !
Alain
On Tue, 12 Apr 2011, Alain Péan wrote:
Indeed, nothing fails now. I want my users to authenticate against Active directory, and it works, and I would like them to be able to use their kerberos credentials, if they need, to access domain ressources, as shares. But I have still to see a problem there..
Thanks again for your help and your comments !
So is it all working after taking out the ldap auth? With it in you'll not be generating kerberos tickets if there's anything wrong with your kerberos setup.
jh
Le 12/04/2011 22:03, John Hodrien a écrit :
On Tue, 12 Apr 2011, Alain Péan wrote:
Indeed, nothing fails now. I want my users to authenticate against Active directory, and it works, and I would like them to be able to use their kerberos credentials, if they need, to access domain ressources, as shares. But I have still to see a problem there..
Thanks again for your help and your comments !
So is it all working after taking out the ldap auth? With it in you'll not be generating kerberos tickets if there's anything wrong with your kerberos setup.
jh
No, you are right, things do not work as I expect. When I disable ldapauth, I cannot authenticate. So kerberos is not working. I have kerberos error messages with samba when I try to join AD domain with net ads join. But net rpc join succeeds. # net ads join -U pean -d3 .... [2011/04/12 22:19:45.797972, 3] libads/sasl.c:790(ads_sasl_spnego_bind) ads_sasl_spnego_bind: got server principal name = pc-2003-test$@TEST-LPP.LOCAL [2011/04/12 22:19:45.798331, 3] libsmb/clikrb5.c:698(ads_krb5_mk_req) ads_krb5_mk_req: krb5_cc_get_principal failed (No credentials cache found) [2011/04/12 22:19:45.811493, 1] libsmb/clikrb5.c:710(ads_krb5_mk_req) ads_krb5_mk_req: smb_krb5_get_credentials failed for pc-2003-test$@TEST-LPP.LOCAL (Cannot find ticket for requested realm) ....
Why 'no credential cache found' ? I would like to solve this annoying problem. Why it is no more working after upgrading to 5.6 ?
Alain
On Tue, 12 Apr 2011, Alain Péan wrote:
Le 12/04/2011 22:03, John Hodrien a écrit :
On Tue, 12 Apr 2011, Alain Péan wrote:
Indeed, nothing fails now. I want my users to authenticate against Active directory, and it works, and I would like them to be able to use their kerberos credentials, if they need, to access domain ressources, as shares. But I have still to see a problem there..
Thanks again for your help and your comments !
So is it all working after taking out the ldap auth? With it in you'll not be generating kerberos tickets if there's anything wrong with your kerberos setup.
jh
No, you are right, things do not work as I expect. When I disable ldapauth, I cannot authenticate. So kerberos is not working. I have kerberos error messages with samba when I try to join AD domain with net ads join. But net rpc join succeeds. # net ads join -U pean -d3 .... [2011/04/12 22:19:45.797972, 3] libads/sasl.c:790(ads_sasl_spnego_bind) ads_sasl_spnego_bind: got server principal name = pc-2003-test$@TEST-LPP.LOCAL [2011/04/12 22:19:45.798331, 3] libsmb/clikrb5.c:698(ads_krb5_mk_req) ads_krb5_mk_req: krb5_cc_get_principal failed (No credentials cache found) [2011/04/12 22:19:45.811493, 1] libsmb/clikrb5.c:710(ads_krb5_mk_req) ads_krb5_mk_req: smb_krb5_get_credentials failed for pc-2003-test$@TEST-LPP.LOCAL (Cannot find ticket for requested realm) ....
Why 'no credential cache found' ? I would like to solve this annoying problem. Why it is no more working after upgrading to 5.6 ?
I'm afraid you've cooked my brain with all the realms you've mentioned, so I'm not entirely clear what's going on.
It's complaining about your kdc.
Is pc-2003-test the KDC for the TEST-LPP.LOCAL realm, or is it KDC for the LAB-LPP.LOCAL realm? Is its FQDN pc-2003-test.test-lpp.local?
Without worrying about the join, does 'kinit <username>' work?
jh
Le 13/04/2011 11:35, John Hodrien a écrit :
On Tue, 12 Apr 2011, Alain Péan wrote:
Le 12/04/2011 22:03, John Hodrien a écrit :
On Tue, 12 Apr 2011, Alain Péan wrote:
Indeed, nothing fails now. I want my users to authenticate against Active directory, and it works, and I would like them to be able to use their kerberos credentials, if they need, to access domain ressources, as shares. But I have still to see a problem there..
Thanks again for your help and your comments !
So is it all working after taking out the ldap auth? With it in you'll not be generating kerberos tickets if there's anything wrong with your kerberos setup.
jh
No, you are right, things do not work as I expect. When I disable ldapauth, I cannot authenticate. So kerberos is not working. I have kerberos error messages with samba when I try to join AD domain with net ads join. But net rpc join succeeds. # net ads join -U pean -d3 .... [2011/04/12 22:19:45.797972, 3] libads/sasl.c:790(ads_sasl_spnego_bind) ads_sasl_spnego_bind: got server principal name = pc-2003-test$@TEST-LPP.LOCAL [2011/04/12 22:19:45.798331, 3] libsmb/clikrb5.c:698(ads_krb5_mk_req) ads_krb5_mk_req: krb5_cc_get_principal failed (No credentials cache found) [2011/04/12 22:19:45.811493, 1] libsmb/clikrb5.c:710(ads_krb5_mk_req) ads_krb5_mk_req: smb_krb5_get_credentials failed for pc-2003-test$@TEST-LPP.LOCAL (Cannot find ticket for requested realm) ....
Why 'no credential cache found' ? I would like to solve this annoying problem. Why it is no more working after upgrading to 5.6 ?
I'm afraid you've cooked my brain with all the realms you've mentioned, so I'm not entirely clear what's going on.
It's complaining about your kdc.
Is pc-2003-test the KDC for the TEST-LPP.LOCAL realm, or is it KDC for the LAB-LPP.LOCAL realm? Is its FQDN pc-2003-test.test-lpp.local?
Without worrying about the join, does 'kinit <username>' work?
jh
Hi John,
There are only two realms I mentionned, LAB-LPP.LOCAL, and TEST-LPP.LOCAL. I am currently doing test with the latter, and indeed, pc-2003-test is the AD DC, so the KDC for TEST-LPP.LOCAL. The fdqn is also pc-2003-test.test-lpp.local.
'kinit <username>' works, [root@centos-test etc]# kinit pean Password for pean@TEST-LPP.LOCAL: [root@centos-test etc]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: pean@TEST-LPP.LOCAL
Valid starting Expires Service principal 04/13/11 11:41:09 04/13/11 18:21:09 krbtgt/TEST-LPP.LOCAL@TEST-LPP.LOCAL
Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached
But nevertheless, it is asking for password when I issue the 'net ads join -U pean' command...
As you understood, my KDC server is a windows 2003 R2 Active directory server. I don't understand where it is looking for the credentials. I tried to create the krb5.keytab with ktpass on the windows server, and replace the one on the centos-test, but it does not work either. There is something, perhaps obvious, I miss. I also tried with 'validate = true' in /etc/krb5.conf, but with no success.
I found also that there is a 'krb5.conf.TEST-LPP' file in /var/lib/samba/smb_krb5, and this one is certainly used by samba (I replaced old version with samba3x, 3.5.4, and put 'kerberos method = secrets and keytab', instead of 'use kerberos keytab = true' that I used previously.
I don't know if you have, or anyone else, an idea ?
Alain
On Wed, 13 Apr 2011, Alain Péan wrote:
Hi John,
There are only two realms I mentionned, LAB-LPP.LOCAL, and TEST-LPP.LOCAL. I am currently doing test with the latter, and indeed, pc-2003-test is the AD DC, so the KDC for TEST-LPP.LOCAL. The fdqn is also pc-2003-test.test-lpp.local.
'kinit <username>' works, [root@centos-test etc]# kinit pean Password for pean@TEST-LPP.LOCAL: [root@centos-test etc]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: pean@TEST-LPP.LOCAL
Valid starting Expires Service principal 04/13/11 11:41:09 04/13/11 18:21:09 krbtgt/TEST-LPP.LOCAL@TEST-LPP.LOCAL
Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached
But nevertheless, it is asking for password when I issue the 'net ads join -U pean' command...
As you understood, my KDC server is a windows 2003 R2 Active directory server. I don't understand where it is looking for the credentials. I tried to create the krb5.keytab with ktpass on the windows server, and replace the one on the centos-test, but it does not work either. There is something, perhaps obvious, I miss. I also tried with 'validate = true' in /etc/krb5.conf, but with no success.
Have you tried with validate = false?
I'd expect that to work, but it's not what you want to be doing long term.
I found also that there is a 'krb5.conf.TEST-LPP' file in /var/lib/samba/smb_krb5, and this one is certainly used by samba (I replaced old version with samba3x, 3.5.4, and put 'kerberos method = secrets and keytab', instead of 'use kerberos keytab = true' that I used previously.
Does that config file conflict in any way with the system krb5.conf?
I don't know if you have, or anyone else, an idea ?
Ah, I'm using samba-common-3.0.33 for the join not samba3x, so there's possibly some subtle differences.
The join is reliant on /etc/samba/smb.conf (and presumably that krb5.conf.TEST-LPP) though, so you'd need to double check that's all correct.
jh
Le 13/04/2011 12:03, John Hodrien a écrit :
On Wed, 13 Apr 2011, Alain Péan wrote:
Hi John,
There are only two realms I mentionned, LAB-LPP.LOCAL, and TEST-LPP.LOCAL. I am currently doing test with the latter, and indeed, pc-2003-test is the AD DC, so the KDC for TEST-LPP.LOCAL. The fdqn is also pc-2003-test.test-lpp.local.
'kinit <username>' works, [root@centos-test etc]# kinit pean Password for pean@TEST-LPP.LOCAL: [root@centos-test etc]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: pean@TEST-LPP.LOCAL
Valid starting Expires Service principal 04/13/11 11:41:09 04/13/11 18:21:09 krbtgt/TEST-LPP.LOCAL@TEST-LPP.LOCAL
Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached
But nevertheless, it is asking for password when I issue the 'net ads join -U pean' command...
As you understood, my KDC server is a windows 2003 R2 Active directory server. I don't understand where it is looking for the credentials. I tried to create the krb5.keytab with ktpass on the windows server, and replace the one on the centos-test, but it does not work either. There is something, perhaps obvious, I miss. I also tried with 'validate = true' in /etc/krb5.conf, but with no success.
Have you tried with validate = false?
I'd expect that to work, but it's not what you want to be doing long term.
I just tried, before reading your answer, and indeed, it works ! I can now connect without ldap, only kerberos in system-auth-ac (/etc/pam.d).
I found also that there is a 'krb5.conf.TEST-LPP' file in /var/lib/samba/smb_krb5, and this one is certainly used by samba (I replaced old version with samba3x, 3.5.4, and put 'kerberos method = secrets and keytab', instead of 'use kerberos keytab = true' that I used previously.
Does that config file conflict in any way with the system krb5.conf?
No, it is the newer syntax of 3.5.4, it's all.
I don't know if you have, or anyone else, an idea ?
Ah, I'm using samba-common-3.0.33 for the join not samba3x, so there's possibly some subtle differences.
No, it was the same with 3.0.33. I only tried with 3.5.4, when I saw that it failed with the previous version.
The join is reliant on /etc/samba/smb.conf (and presumably that krb5.conf.TEST-LPP) though, so you'd need to double check that's all correct.
I'll try know, with the change in /etc/krb5.conf (validate = false), if it works now.
Thanks for your help !
Alain
On Wed, 13 Apr 2011, Alain Péan wrote:
I'll try know, with the change in /etc/krb5.conf (validate = false), if it works now.
It won't (or at least it shouldn't). Validate is essential as it confirms that the KDC providing the TGT to the user is the same KDC that you registered with when you joined the domain. If you don't have that check, I believe it's hideously insecure.
But the samba join is affected by many things. /etc/hosts, /etc/krb5.conf, /etc/samba/smb.conf are all well worth double checking for correctness.
So you've still got problems that need sorting. If validate doesn't work, then there are keytab issues. The keytab only needs to contain a valid principal for the domain, it doesn't even need to be a credential for that machine. Normally it *would* be for that machine, since you'd generate it through a 'net ads join' with an appropriate smb.conf.
Thanks for your help !
No problem.
jh
Le 13/04/2011 14:05, John Hodrien a écrit :
On Wed, 13 Apr 2011, Alain Péan wrote:
I'll try know, with the change in /etc/krb5.conf (validate = false), if it works now.
It won't (or at least it shouldn't). Validate is essential as it confirms that the KDC providing the TGT to the user is the same KDC that you registered with when you joined the domain. If you don't have that check, I believe it's hideously insecure.
You are right. It fails...
But the samba join is affected by many things. /etc/hosts, /etc/krb5.conf, /etc/samba/smb.conf are all well worth double checking for correctness.
So you've still got problems that need sorting. If validate doesn't work, then there are keytab issues. The keytab only needs to contain a valid principal for the domain, it doesn't even need to be a credential for that machine. Normally it *would* be for that machine, since you'd generate it through a 'net ads join' with an appropriate smb.conf.
Here are the appropriate files, enough simple : # cat /etc/samba/smb.conf # Test domaine test-lpp
# Global Parameters [global] workgroup = TEST-LPP netbios name = centos-test server string = Samba Server %v security = ads realm = TEST-LPP.LOCAL #use kerberos keytab = true kerberos method = secrets and keytab passdb backend = tdbsam password server = * encrypt passwords = true client use spnego = no load printers = yes printing = cups printcap name = cups admin users = pean
# Partages [homes] comment = Home Directories read only = no browseable = no
(samba3x, 3.5.4). I added passdb backend = tdbsam following the original smb.conf file, but I don't know if this is necessary. It was not there previously.
# cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 134.x1.y1.z1 centos-test.test-lpp.local centos-test
# Serveur de domaine test-lpp.local 134.x2.y2.z2 pc-2003-test.test-lpp.local pc-2003-test 134.x3.y3.z3 dc1-test.test-lpp.local dc1-test
# cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5lib.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults] ticket_lifetime = 24000 default_realm = TEST-LPP.LOCAL default_tk_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc dns_lookup_realm = true dns_lookup_kdc = true
[realms] TEST-LPP.LOCAL = { kdc = pc-2003-test.test-lpp.local:88 kdc = dc1-test.test-lpp.local:88 #admin_server = pc-2003-test.test-lpp.local:749 default_domain = TEST-LPP.LOCAL kpasswd_server = pc-2003-test.test-lpp.local kdc = * }
[domain_realm] .test-lpp.local = TEST-LPP.LOCAL test-lpp.local = TEST-LPP.LOCAL
[kdc] profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false validate = false }
If you see something wrong, let me know ! The resolv.conf file contains the name of the domain (search test-lpp.local), and the addresses of the AD servers of this domain, and only them... selinux and iptables are disabled....
Alain
On Tue, 12 Apr 2011, Alain Péan wrote:
Hi John,
Thnks for your answer. Here are the content of /etc/krb5.conf and klist -ke. I agree that there can be siomething missing, that was working before...
The keytab isn't valid for the host as it doesn't contain a usable principal for doing a validation of the KDC. The pam_krb5 rpm has sensibly changed the default for validate from false to true. Try adding:
[appdefaults] pam = { novalidate = true }
I /think/ that'd work, but you'd be less secure than if you just sorted out your keytab. Get a real principal for your domain into the keytab, and validate will work. You're using LAB-LPP.LOCAL, but only have principals from TEST-LPP.LOCAL in your keytab.
jh
-
Alain Péan -
John Hodrien