On Wed, 4 Aug 2010, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/04/2010 10:18 AM, Timo Aaltonen wrote:
On Mon, 2 Aug 2010, Patrik Martinsson wrote:
ldap_tls_reqcert = demand ldap_tls_cacert = /etc/openldap/cacerts/CADOUBLE.cer ldap_tls_cacertdir = /etc/openldap/cacerts
I guess this doesn't work with GSSAPI SASL binding yet? Tried to force the authid to FOO$@REALM, but it fails just the same.
it's harder to automatically generate certificates for the clients, that's why I'm interested in getting this working :)
I'm not sure what you're asking for here.
I think what you're talking about is using: ldap_sasl_mech = gssapi ldap_krb5_keytab = /path/to/ldap.keytab
I did that, but it doesn't seem to work, or somethings missing still. It said something like "marking ldap server foo as broken" (sorry no logs, reinstalling the machine).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2010 08:21 AM, Timo Aaltonen wrote:
On Wed, 4 Aug 2010, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/04/2010 10:18 AM, Timo Aaltonen wrote:
On Mon, 2 Aug 2010, Patrik Martinsson wrote:
ldap_tls_reqcert = demand ldap_tls_cacert = /etc/openldap/cacerts/CADOUBLE.cer ldap_tls_cacertdir = /etc/openldap/cacerts
I guess this doesn't work with GSSAPI SASL binding yet? Tried to force the authid to FOO$@REALM, but it fails just the same.
it's harder to automatically generate certificates for the clients, that's why I'm interested in getting this working :)
I'm not sure what you're asking for here.
I think what you're talking about is using: ldap_sasl_mech = gssapi ldap_krb5_keytab = /path/to/ldap.keytab
I did that, but it doesn't seem to work, or somethings missing still. It said something like "marking ldap server foo as broken" (sorry no logs, reinstalling the machine).
Someone else just reported this same issue to me :(
Can you attach the /var/log/sssd/sssd_<domain>.log and /var/log/sssd/ldap_child.log for this?
I suspect you'll see the ldap_child.log report that it couldn't find a KDC for the realm.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Hey,
I got this working today with these settings,
ldap_uri = ldap://foo.bar ldap_sasl_mech = gssapi ldap_krb5_keytab = /etc/krb5.keytab ldap_sasl_authid = nfs/xx.xxxx.xx
Note1, I could not get it to work with my ldaps://foo.bar, but maybe that's normal ? Maybe ssl isn't necessary when its krb ?
Note2, When i join my machine to the ad (thus creating its machine account) i use the following method,
# First make sure of a couple of things. kdestroy rm -rf /etc/krb5.keytab net ads leave -U foo%bar net ads keytab flush -U foo%bar
# Join AD. net ads join createupn="nfs/$HOSTNAME@XX.XXXX.XX" createcomputer="foo" osName="Linux Red Hat Workstation" osVer="6" -U foo%bar
# Now we are joined and have a keytab that looks like this, [root@client openldap]# klist -kte Keytab name: WRFILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 2 08/05/10 15:26:06 host/client.xx.xxxx.xx@XX.XXXX.XX (DES cbc mode with CRC-32) 2 08/05/10 15:26:06 host/client.xx.xxxx.xx@XX.XXXX.XX (DES cbc mode with RSA-MD5) 2 08/05/10 15:26:06 host/client.xx.xxxx.xx@XX.XXXX.XX (ArcFour with HMAC/md5) 2 08/05/10 15:26:06 host/CLIENT@XX.XXXX.XX (DES cbc mode with CRC-32) 2 08/05/10 15:26:06 host/CLIENT@XX.XXXX.XX (DES cbc mode with RSA-MD5) 2 08/05/10 15:26:06 host/CLIENT@XX.XXXX.XX (ArcFour with HMAC/md5) 2 08/05/10 14:18:53 CLIENT$@XX.XXXX.XX (DES cbc mode with CRC-32) 2 08/05/10 14:18:53 CLIENT$@XX.XXXX.XX (DES cbc mode with RSA-MD5) 2 08/05/10 14:18:54 CLIENT$@XX.XXXX.XX (ArcFour with HMAC/md5) 2 08/05/10 14:18:54 nfs/client.xx.xxxx.xx@XX.XXXX.XX (DES cbc mode with CRC-32) 2 08/05/10 14:18:54 nfs/client.xx.xxxx.xx@XX.XXXX.XX (DES cbc mode with RSA-MD5) 2 08/05/10 14:18:54 nfs/client.xx.xxxx.xx@XX.XXXX.XX (ArcFour with HMAC/md5)
Now i would like to use the default setting for 'ldap_sasl_authid' sssd, host/xx.xxxx.xx, but when doing that i get the response, Client 'host/client.xx.xxxx.xx@XX.XXXX.XX' not found in Kerberos database while getting initial credentials.
So then i tried with the nfs/xx.xxxx.xx instead, and that works. (But that's not the way to do it, is it ?)
If i do, kinit -k nfs/xx.xxxx.xx, i get klist -e Ticket cache: FILE:/tmp/krb5cc_0 Default principal: nfs/nfs/xx.xxxx.xx@XX.XXXX.XX
Valid starting Expires Service principal 08/05/10 15:22:45 08/06/10 01:22:45 krbtgt/XX.XXXX.XX@XX.XXXX.XX renew until 08/06/10 15:22:45, Etype (skey, tkt): DES cbc mode with RSA-MD5, ArcFour with HMAC/md5
If i do, kinit -k host/client.xx.xxxx.xx, i get kinit: Client 'host/client.xx.xxxx.xx@XX.XXXX.XX' not found in Kerberos database while getting initial credentials
So i guess that's why sssd is failing when it tries to do kinit with the host as principle.
Ehm, maybe this rather should be on a krb-mailinglist, but i figure i would share and see if anyone has any tip for me here too.
Best regards, Patrik Martinsson, Sweden,.
On 08/05/2010 02:25 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2010 08:21 AM, Timo Aaltonen wrote:
On Wed, 4 Aug 2010, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/04/2010 10:18 AM, Timo Aaltonen wrote:
On Mon, 2 Aug 2010, Patrik Martinsson wrote:
ldap_tls_reqcert = demand ldap_tls_cacert = /etc/openldap/cacerts/CADOUBLE.cer ldap_tls_cacertdir = /etc/openldap/cacerts
I guess this doesn't work with GSSAPI SASL binding yet? Tried to force the authid to FOO$@REALM, but it fails just the same.
it's harder to automatically generate certificates for the clients, that's why I'm interested in getting this working :)
I'm not sure what you're asking for here.
I think what you're talking about is using: ldap_sasl_mech = gssapi ldap_krb5_keytab = /path/to/ldap.keytab
I did that, but it doesn't seem to work, or somethings missing still. It said something like "marking ldap server foo as broken" (sorry no logs, reinstalling the machine).
Someone else just reported this same issue to me :(
Can you attach the /var/log/sssd/sssd_<domain>.log and /var/log/sssd/ldap_child.log for this?
I suspect you'll see the ldap_child.log report that it couldn't find a KDC for the realm.
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxaraUACgkQeiVVYja6o6PB6wCfYrJ+di1t/hOka/WVGuKNcgnC MhwAni9NyIvG76/G9mmTxmr82DKi+joD =iCQk -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2010 09:43 AM, Patrik Martinsson wrote:
If i do, kinit -k host/client.xx.xxxx.xx, i get kinit: Client 'host/client.xx.xxxx.xx@XX.XXXX.XX' not found in Kerberos database while getting initial credentials
That's a server-side issue. It looks to me like you don't have that service principal set up on AD.
Perhaps you need to use host/CLIENT@XX.XXXX.XX instead?
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Hmm, yea thats what i figured too, however if i check in the AD, values for servicePrincipalName is following,
HOST/CLIENT HOST/client.xx.xxxx.xx
And attribute, userPrincipalName, is following, nfs/client.xx.xxxx.xx@XX.XXX.XX
So you would figure this would work, right ? kinit -k HOST/CLIENT kinit -k HOST/client.xx.xxxx.xx
However, it doesn't. It only gives me, Client not found in Kerberos database while getting initial credentials.
I'm very close to get sssd to work as i want, I've got krb auth backend to work so the users obtain theirs ticket, now i want the ldapbind to be kerborized to, but that where am stuck at the moment.
/Patrik
On 08/05/2010 03:48 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2010 09:43 AM, Patrik Martinsson wrote:
If i do, kinit -k host/client.xx.xxxx.xx, i get kinit: Client 'host/client.xx.xxxx.xx@XX.XXXX.XX' not found in Kerberos database while getting initial credentials
That's a server-side issue. It looks to me like you don't have that service principal set up on AD.
Perhaps you need to use host/CLIENT@XX.XXXX.XX instead?
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxawR4ACgkQeiVVYja6o6NFMgCdGhAz9fB/K85XO88nI0T1OrmK TgIAn0J2iyMHt4o9QvzAzHQGy40VsrzB =NMyJ -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2010 10:03 AM, Patrik Martinsson wrote:
Hmm, yea thats what i figured too, however if i check in the AD, values for servicePrincipalName is following,
HOST/CLIENT HOST/client.xx.xxxx.xx
And attribute, userPrincipalName, is following, nfs/client.xx.xxxx.xx@XX.XXX.XX
userPrincipalName is the principal that AD is expecting to have kinit performed against. If you want it to be different, that has to be changed on AD (I'm not well-enough versed in AD to tell you how to do this).
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Ah ok Stephen, thanks anyway for great support on the sssd.
Got to get someone on the AD side to help me figure this stuff out.
/Patrik
On 08/05/2010 04:09 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2010 10:03 AM, Patrik Martinsson wrote:
Hmm, yea thats what i figured too, however if i check in the AD, values for servicePrincipalName is following,
HOST/CLIENT HOST/client.xx.xxxx.xx
And attribute, userPrincipalName, is following, nfs/client.xx.xxxx.xx@XX.XXX.XX
userPrincipalName is the principal that AD is expecting to have kinit performed against. If you want it to be different, that has to be changed on AD (I'm not well-enough versed in AD to tell you how to do this).
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxaxiYACgkQeiVVYja6o6PGngCgnuXMkmQniwib7myotIPVqL3Q 4NUAoLEh/BpGw0r5m3nX5raqgKmXy61y =+26D -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2010 09:43 AM, Patrik Martinsson wrote:
Hey,
I got this working today with these settings,
ldap_uri = ldap://foo.bar ldap_sasl_mech = gssapi ldap_krb5_keytab = /etc/krb5.keytab ldap_sasl_authid = nfs/xx.xxxx.xx
Note1, I could not get it to work with my ldaps://foo.bar, but maybe that's normal ? Maybe ssl isn't necessary when its krb ?
Hmm, it shouldn't be BROKEN, but it would definitely be unnecessary (and slower).
When using SASL-GSSAPI for the LDAP connection, your communication is already encrypted. Wrapping it in LDAPS would just mean that you were wasting processing power encrypting and decrypting twice.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Ok, cool thanks for that.
/Patrik
On 08/05/2010 03:49 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2010 09:43 AM, Patrik Martinsson wrote:
Hey,
I got this working today with these settings,
ldap_uri = ldap://foo.bar ldap_sasl_mech = gssapi ldap_krb5_keytab = /etc/krb5.keytab ldap_sasl_authid = nfs/xx.xxxx.xx
Note1, I could not get it to work with my ldaps://foo.bar, but maybe that's normal ? Maybe ssl isn't necessary when its krb ?
Hmm, it shouldn't be BROKEN, but it would definitely be unnecessary (and slower).
When using SASL-GSSAPI for the LDAP connection, your communication is already encrypted. Wrapping it in LDAPS would just mean that you were wasting processing power encrypting and decrypting twice.
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxawXIACgkQeiVVYja6o6PbLACeJ85g+QbZrub2qNk+tWs9HzMP JsQAn2KtE2tj9qnsv0EJ51LHVCsBSvH/ =DyL+ -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel@lists.fedorahosted.org
-
Patrik Martinsson -
Stephen Gallagher -
Timo Aaltonen