Issues with GSSAPI kerberos authentication - realm undefined? - 389-users

List overview All Threads
Download

newer

Issues with GSSAPI kerberos authentication - realm undefined?

older

New Instance errors

Announcing 389 Directory Server...

Kyle Brantley

12 Apr 2020 12 Apr '20

5:41 p.m.

I'm trying to move over from OpenLDAP, as it seems that 389-ds is better supported in the RH family of products.

I've followed the RH docs to configure kerberos[1] as well as checking to ensure that the auth mechanisms are enabled and I've poked around with the SASL identity mappings. From what I can tell, all of these are setup correctly.

However, every single time, the realm isn't populated with the kerberos realm and instead, only the username is passed. This results in the SASL mapping that matches the realm (correctly) failing to match:

DEBUG - do_bind - BIND dn="" method=163 version=3 DEBUG - ids_sasl_listmech - sasl library mechs: GSS-SPNEGO,GSSAPI,DIGEST-MD5,CRAM-MD5,PLAIN,LOGIN,ANONYMOUS DEBUG - ids_sasl_log - (5): GSSAPI server step 3 DEBUG - ids_sasl_canon_user - (user=kyletest, realm=) DEBUG - sasl_map_domap - Trying map [Kerberos uid mapping] DEBUG - sasl_map_check - regex: (.*)@(.*).(.*), id: kyletest, didn't match

I've trimmed the above to just the more relevant log lines, but it's very clear that the value for "realm" is en empty string.

What do I need to do in order to have the realm be made visible to the SASL mapping component? I've searched the docs, both the fedora and the pagure bug trackers, searched all of the nsslapd-* attributes to see if I'm missing something, and tried on both centos8 and F31 (same results). I don't see anything obvious missing here (but I might just not know where to be looking).

F31 package: 389-ds-base-1.4.2.11-1.fc31.x86_64 CentOS8 package: 389-ds-base-1.4.2.9-1.module_el8+8314+9ac085f5.x86_64

- Kerberos setup: [root@ldaptest ~]# cat /etc/sysconfig/dirsrv-app KRB5_KTNAME=/etc/dirsrv/krb5.keytab [root@ldaptest ~]# kinit -kt /etc/dirsrv/krb5.keytab ldap/$HOSTNAME [root@ldaptest ~]# klist Ticket cache: KCM:0:9594 Default principal: ldap/ldaptest.averageurl.com@AVERAGEURL.COM

- klist after attempting an ldapwhoami: [root@ldaptest ~]# klist Ticket cache: KCM:0:39355 Default principal: kyletest@AVERAGEURL.COM

Valid starting Expires Service principal 04/12/2020 10:33:44 04/13/2020 10:33:40 krbtgt/AVERAGEURL.COM@AVERAGEURL.COM 04/12/2020 10:33:51 04/13/2020 10:33:40 ldap/ldaptest.averageurl.com@AVERAGEURL.COM

- SASL mapping: nsSaslMapRegexString: (.*)@(.*).(.*) nsSaslMapFilterTemplate: (cn=\1) nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

- Alternative SASL mapping that I'd prefer to use: nsSaslMapRegexString: (.*)@AVERAGEURL.COM nsSaslMapFilterTemplate: (cn=\1) nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

Thanks, --Kyle

[1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht...

Show replies by date

Mark Reynolds

13 Apr 13 Apr

7:30 p.m.

New subject: Issues with GSSAPI kerberos authentication - realm undefined?

Sorry not a kerberos expert but this is old doc I used to use to get it working. I would double check your /etc/krb5.conf first though.

Here is that doc

===================================================================

SASL and DS KDC Server

- HOST.DOMAIN.COM is usually "localhost.localdomain" for internal testing. Make sure the hostname is lowercase!

[1] ssh krbuser@internal.redhat.com (password redhat) [2] sudo /usr/kerberos/sbin/kadmin.local -r EXAMPLE.COM [3] addprinc -randkey ldap/HOST.DOMAIN.COM@EXAMPLE.COM [4] ktadd -k /opt/ldap.HOST.DOMAIN.COM.keytab ldap/HOST.DOMAIN.COM@EXAMPLE.COM [5] addprinc sasltest -> use redhat as password [6] ktadd -k /opt/sasltest.keytab sasltest@EXAMPLE.COM [7] addprinc t001 --> use redhat as password [8] ktadd -k /opt/ldap.t001.keytab t001@EXAMPLE.COM [9] exit [10] sudo chmod 777 /opt/ldap.HOST.DOMAIN.COM.keytab [11] sudo chmod 777 /opt/ldap.t001.keytab [12] sudo chmod 777 /opt/sasltest.keytab

DS Server

- Get the keytabs

[1] cd /etc/dirsrv [2] wget ftp://internal.redhat.com/opt/ldap.HOST.DOMAIN.COM.keytab [3] wget ftp://internal.redhat.com/opt/sasltest.keytab [4] wget ftp://internal.redhat.com/opt/ldap.t001.keytab

- Edit */etc/krb5.conf*, make sure these settings are included

[libdefaults]

default_realm: EXAMPLE.COM allow_weak_crypto = true (or 'yes')

[realms]

EXAMPLE.COM = { kdc = internal.redhat.com:88 admin_server = internal.redhat.com:749 default_domain = example.com }

[domain_realm] .redhat.com = EXAMPLE.COM redhat.com = EXAMPLE.COM .example.com = EXAMPLE.COM example.com = EXAMPLE.COM

- Edit /etc/sysconfig/dirsrv-INSTANCE

Add these two lines to

KRB5_CONFIG=/etc/krb5.conf KRB5_KTNAME=/etc/dirsrv/ldap.HOST.DOMAIN.COM.keytab

- Edit the dse.ldif/ldapmodify. This assumes there is a backend: dc=example,dc=com

dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=config changetype: modify add: passwordstoragescheme passwordstoragescheme: clear

- Add our user:

dn: uid=t001,ou=people,dc=example,dc=com uid: t001 givenName: test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: 001 cn: test 001 mail: t001@example.com

Testing

[1] cd /etc/dirsrv [2] kinit -k -t ./ldap.t001.keytab t001@EXAMPLE.COM [3] klist

Ticket cache: FILE:/tmp/krb5cc_0 Default principal: t001@EXAMPLE.COM

Valid starting Expires Service principal 02/08/10 14:29:33 02/09/10 14:29:33 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 02/08/10 14:29:33

[4] ldapsearch -h HOST.DOMAIN.COM -p 389 -b "dc=example,dc=com" -v -LLL -Y GSSAPI "uid=*" dn

[5] klist

Ticket cache: FILE:/tmp/krb5cc_0 Default principal: t001@EXAMPLE.COM

Valid starting Expires Service principal 02/08/10 16:52:14 02/09/10 16:52:14 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 02/08/10 16:52:14 02/08/10 16:52:20 02/09/10 16:52:14 ldap/HOST.DOMAIN.COM@EXAMPLE.COM renew until 02/08/10 16:52:14

Troubleshooting

[1] To verify the DS server does use the user kerberos ticket for authentication, log on kdc server (internal.redhat.com), and tail -f /var/log/krb5kdc.log You should see following msgs in log:

- The first msg means the usr "t001" does get valid kerberos ticket from kdc server - The second msg means the server which use "ldap/internal.redhat.com@EXAMPLE.COM" is connect with kdc for user authentication

Feb 08 16:46:14 internal.redhat.com krb5kdc[2726](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.16.96.80: ISSUE: authtime 1265665574, etypes {rep=1 tkt=16 ses=16}, t001@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM

Feb 08 16:48:34 internal.redhat.com krb5kdc[2726](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.16.96.80: ISSUE: authtime 1265665574, etypes {rep=16 tkt=16 ses=16}, t001@EXAMPLE.COM for ldap/HOST.DOMAIN.COM.com@EXAMPLE.COM

[2] ldapsearch issues

[a] make sure you use -h "<FQDN>"

[b] error:

ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unknown error)

cause: /etc/sysconfig/dirsrv-INSTANCE, the KRB5_KTNAME was incorrect

[c] other errors, if you have verified the kerberos ticket is being used(see [1]), then recheck your sasl mappings in dse.ldif

[3] DS error logging, turn on "trace function calls" (nsslapd-errorlog-level: 1), this might provide more information.

================================================================

HTH, Mark

On 4/12/20 12:41 PM, Kyle Brantley wrote:

...

I'm trying to move over from OpenLDAP, as it seems that 389-ds is better supported in the RH family of products.

I've followed the RH docs to configure kerberos[1] as well as checking to ensure that the auth mechanisms are enabled and I've poked around with the SASL identity mappings. From what I can tell, all of these are setup correctly.

However, every single time, the realm isn't populated with the kerberos realm and instead, only the username is passed. This results in the SASL mapping that matches the realm (correctly) failing to match:

DEBUG - do_bind - BIND dn="" method=163 version=3 DEBUG - ids_sasl_listmech - sasl library mechs: GSS-SPNEGO,GSSAPI,DIGEST-MD5,CRAM-MD5,PLAIN,LOGIN,ANONYMOUS DEBUG - ids_sasl_log - (5): GSSAPI server step 3 DEBUG - ids_sasl_canon_user - (user=kyletest, realm=) DEBUG - sasl_map_domap - Trying map [Kerberos uid mapping] DEBUG - sasl_map_check - regex: (.*)@(.*).(.*), id: kyletest, didn't match

I've trimmed the above to just the more relevant log lines, but it's very clear that the value for "realm" is en empty string.

What do I need to do in order to have the realm be made visible to the SASL mapping component? I've searched the docs, both the fedora and the pagure bug trackers, searched all of the nsslapd-* attributes to see if I'm missing something, and tried on both centos8 and F31 (same results). I don't see anything obvious missing here (but I might just not know where to be looking).

F31 package: 389-ds-base-1.4.2.11-1.fc31.x86_64 CentOS8 package: 389-ds-base-1.4.2.9-1.module_el8+8314+9ac085f5.x86_64

Kerberos setup:

[root@ldaptest ~]# cat /etc/sysconfig/dirsrv-app KRB5_KTNAME=/etc/dirsrv/krb5.keytab [root@ldaptest ~]# kinit -kt /etc/dirsrv/krb5.keytab ldap/$HOSTNAME [root@ldaptest ~]# klist Ticket cache: KCM:0:9594 Default principal: ldap/ldaptest.averageurl.com@AVERAGEURL.COM

klist after attempting an ldapwhoami:

[root@ldaptest ~]# klist Ticket cache: KCM:0:39355 Default principal: kyletest@AVERAGEURL.COM

Valid starting Expires Service principal 04/12/2020 10:33:44 04/13/2020 10:33:40 krbtgt/AVERAGEURL.COM@AVERAGEURL.COM 04/12/2020 10:33:51 04/13/2020 10:33:40 ldap/ldaptest.averageurl.com@AVERAGEURL.COM

SASL mapping:

nsSaslMapRegexString: (.*)@(.*).(.*) nsSaslMapFilterTemplate: (cn=\1) nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

Alternative SASL mapping that I'd prefer to use:

nsSaslMapRegexString: (.*)@AVERAGEURL.COM nsSaslMapFilterTemplate: (cn=\1) nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

Thanks, --Kyle

[1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....

-- 389 Directory Server Development Team

Mark Reynolds

7:33 p.m.

New subject: Issues with GSSAPI kerberos authentication - realm undefined?

On 4/13/20 2:30 PM, Mark Reynolds wrote:

...

Sorry not a kerberos expert but this is old doc I used to use to get it working. I would double check your /etc/krb5.conf first though.

Here is that doc

I wanted to add this this document was for doing internal testing, so permission changes and password storage schemes changes should probably not be done in production. The hope is that it will help figure out what is wrong in your setup...

Mark

...

===================================================================

SASL and DS KDC Server

- HOST.DOMAIN.COM is usually "localhost.localdomain" for internal testing. Make sure the hostname is lowercase!

[1] ssh krbuser@internal.redhat.com (password redhat)    [2] sudo /usr/kerberos/sbin/kadmin.local -r EXAMPLE.COM    [3] addprinc -randkey ldap/HOST.DOMAIN.COM@EXAMPLE.COM    [4] ktadd -k /opt/ldap.HOST.DOMAIN.COM.keytab ldap/HOST.DOMAIN.COM@EXAMPLE.COM    [5] addprinc sasltest -> use redhat as password    [6] ktadd -k /opt/sasltest.keytab sasltest@EXAMPLE.COM    [7] addprinc t001 --> use redhat as password    [8] ktadd -k /opt/ldap.t001.keytab t001@EXAMPLE.COM    [9] exit    [10] sudo chmod 777 /opt/ldap.HOST.DOMAIN.COM.keytab    [11] sudo chmod 777 /opt/ldap.t001.keytab    [12] sudo chmod 777 /opt/sasltest.keytab

DS Server

- Get the keytabs

[1] cd /etc/dirsrv    [2] wget ftp://internal.redhat.com/opt/ldap.HOST.DOMAIN.COM.keytab    [3] wget ftp://internal.redhat.com/opt/sasltest.keytab    [4] wget ftp://internal.redhat.com/opt/ldap.t001.keytab

- Edit */etc/krb5.conf*, make sure these settings are included

[libdefaults]

default_realm: EXAMPLE.COM       allow_weak_crypto = true (or 'yes')

[realms]

EXAMPLE.COM = {       kdc = internal.redhat.com:88       admin_server = internal.redhat.com:749       default_domain = example.com     }

[domain_realm]      .redhat.com = EXAMPLE.COM      redhat.com = EXAMPLE.COM      .example.com = EXAMPLE.COM      example.com = EXAMPLE.COM

- Edit /etc/sysconfig/dirsrv-INSTANCE

Add these two lines to

KRB5_CONFIG=/etc/krb5.conf          KRB5_KTNAME=/etc/dirsrv/ldap.HOST.DOMAIN.COM.keytab

- Edit the dse.ldif/ldapmodify. This assumes there is a backend: dc=example,dc=com

dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=config changetype: modify add: passwordstoragescheme passwordstoragescheme: clear

- Add our user:

dn: uid=t001,ou=people,dc=example,dc=com uid: t001 givenName: test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: 001 cn: test 001 mail: t001@example.com

Testing

[1] cd /etc/dirsrv    [2] kinit -k -t ./ldap.t001.keytab t001@EXAMPLE.COM    [3] klist

Ticket cache: FILE:/tmp/krb5cc_0      Default principal: t001@EXAMPLE.COM

Valid starting     Expires            Service principal      02/08/10 14:29:33 02/09/10 14:29:33 krbtgt/EXAMPLE.COM@EXAMPLE.COM          renew until 02/08/10 14:29:33

[4] ldapsearch -h HOST.DOMAIN.COM -p 389 -b "dc=example,dc=com" -v -LLL -Y GSSAPI "uid=*" dn

[5] klist

Ticket cache: FILE:/tmp/krb5cc_0     Default principal: t001@EXAMPLE.COM

Valid starting     Expires            Service principal     02/08/10 16:52:14 02/09/10 16:52:14 krbtgt/EXAMPLE.COM@EXAMPLE.COM         renew until 02/08/10 16:52:14     02/08/10 16:52:20 02/09/10 16:52:14 ldap/HOST.DOMAIN.COM@EXAMPLE.COM         renew until 02/08/10 16:52:14

Troubleshooting

[1] To verify the DS server does use the user kerberos ticket for authentication, log on kdc server (internal.redhat.com), and tail -f /var/log/krb5kdc.log You should see following msgs in log:

- The first msg means the usr "t001" does get valid kerberos ticket from kdc server         - The second msg means the server which use "ldap/internal.redhat.com@EXAMPLE.COM" is connect with kdc for user authentication

Feb 08 16:46:14 internal.redhat.com krb5kdc[2726](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.16.96.80: ISSUE: authtime 1265665574, etypes {rep=1 tkt=16 ses=16}, t001@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM

Feb 08 16:48:34 internal.redhat.com krb5kdc[2726](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.16.96.80: ISSUE: authtime 1265665574, etypes {rep=16 tkt=16 ses=16}, t001@EXAMPLE.COM for ldap/HOST.DOMAIN.COM.com@EXAMPLE.COM

[2] ldapsearch issues

[a] make sure you use -h "<FQDN>"

[b] error:

ldap_sasl_interactive_bind_s: Invalid credentials (49)             additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unknown error)

cause: /etc/sysconfig/dirsrv-INSTANCE, the KRB5_KTNAME was incorrect

[c] other errors, if you have verified the kerberos ticket is being used(see [1]), then recheck your sasl mappings in dse.ldif

[3] DS error logging, turn on "trace function calls" (nsslapd-errorlog-level: 1), this might provide more information.

================================================================

HTH, Mark

On 4/12/20 12:41 PM, Kyle Brantley wrote:

...
I'm trying to move over from OpenLDAP, as it seems that 389-ds is better supported in the RH family of products.

I've followed the RH docs to configure kerberos[1] as well as checking to ensure that the auth mechanisms are enabled and I've poked around with the SASL identity mappings. From what I can tell, all of these are setup correctly.

However, every single time, the realm isn't populated with the kerberos realm and instead, only the username is passed. This results in the SASL mapping that matches the realm (correctly) failing to match:

DEBUG - do_bind - BIND dn="" method=163 version=3 DEBUG - ids_sasl_listmech - sasl library mechs: GSS-SPNEGO,GSSAPI,DIGEST-MD5,CRAM-MD5,PLAIN,LOGIN,ANONYMOUS DEBUG - ids_sasl_log - (5): GSSAPI server step 3 DEBUG - ids_sasl_canon_user - (user=kyletest, realm=) DEBUG - sasl_map_domap - Trying map [Kerberos uid mapping] DEBUG - sasl_map_check - regex: (.*)@(.*).(.*), id: kyletest, didn't match

I've trimmed the above to just the more relevant log lines, but it's very clear that the value for "realm" is en empty string.

What do I need to do in order to have the realm be made visible to the SASL mapping component? I've searched the docs, both the fedora and the pagure bug trackers, searched all of the nsslapd-* attributes to see if I'm missing something, and tried on both centos8 and F31 (same results). I don't see anything obvious missing here (but I might just not know where to be looking).

F31 package: 389-ds-base-1.4.2.11-1.fc31.x86_64 CentOS8 package: 389-ds-base-1.4.2.9-1.module_el8+8314+9ac085f5.x86_64

Kerberos setup:

[root@ldaptest ~]# cat /etc/sysconfig/dirsrv-app KRB5_KTNAME=/etc/dirsrv/krb5.keytab [root@ldaptest ~]# kinit -kt /etc/dirsrv/krb5.keytab ldap/$HOSTNAME [root@ldaptest ~]# klist Ticket cache: KCM:0:9594 Default principal: ldap/ldaptest.averageurl.com@AVERAGEURL.COM

klist after attempting an ldapwhoami:

[root@ldaptest ~]# klist Ticket cache: KCM:0:39355 Default principal: kyletest@AVERAGEURL.COM

Valid starting       Expires              Service principal 04/12/2020 10:33:44 04/13/2020 10:33:40 krbtgt/AVERAGEURL.COM@AVERAGEURL.COM 04/12/2020 10:33:51 04/13/2020 10:33:40 ldap/ldaptest.averageurl.com@AVERAGEURL.COM

SASL mapping:

nsSaslMapRegexString: (.*)@(.*).(.*) nsSaslMapFilterTemplate: (cn=\1) nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

Alternative SASL mapping that I'd prefer to use:

nsSaslMapRegexString: (.*)@AVERAGEURL.COM nsSaslMapFilterTemplate: (cn=\1) nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

Thanks, --Kyle

[1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....

--

389 Directory Server Development Team

389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....

-- 389 Directory Server Development Team

Kyle Brantley

7:46 p.m.

New subject: Issues with GSSAPI kerberos authentication - realm undefined?

Thanks, Mark. I can tell that it’s an internal troubleshooting doc – and that’s great, thank you!

However, I… I don’t believe that I have any issues with my kerberos setup. The authentication from a pure krb5 perspective is happening appropriately. The tickets are being issued and I see the logs on the KDC confirming as much.

We have the pre-auth event:

kdc.averageurl.com krb5kdc[2432](info): AS_REQ (1 etypes {aes128-cts-hmac-sha1-96(17)}) 2001:470:xx:dae4: NEEDED_PREAUTH: kyletest@AVERAGEURL.COM for krbtgt/AVERAGEURL.COM@AVERAGEURL.COM, Additional pre-authentication required

The issuance of the kgbtgt ticket:

kdc.averageurl.com krb5kdc[2432](info): AS_REQ (1 etypes {aes128-cts-hmac-sha1-96(17)}) 2001:470:xx:dae4: ISSUE: authtime 1586803255, etypes {rep=aes128-cts-hmac-sha1-96(17), tkt=aes256-cts-hmac-sha1-96(18), ses=aes128-cts-hmac-sha1-96(17)}, kyletest@AVERAGEURL.COM for krbtgt/AVERAGEURL.COM@AVERAGEURL.COM

And finally, the ticket for ldap/ being issued as well:

kdc.averageurl.com krb5kdc[2433](info): TGS_REQ (1 etypes {aes128-cts-hmac-sha1-96(17))}) 2001:470:xx:dae4: ISSUE: authtime 1586803255, etypes {rep=aes128-cts-hmac-sha1-96(17), tkt=aes256-cts-hmac-sha1-96(18), ses=aes128-cts-hmac-sha1-96(17)}, kyletest@AVERAGEURL.COM for ldap/ldaptest.averageurl.com@AVERAGEURL.COM

The issue appears to be specific to what 389-ds is seeing as the realm:

DEBUG - ids_sasl_canon_user - (user=kyletest, realm=)

For reasons unknown to me, the realm isn’t being populated internally within 389-ds when the SASL mapping is taking place, even though kerberos is working as it should be.

(This is the type of thing that I suspect needs to go on the bug tracker – but given how relatively little I know about administration of 389-ds I definitely wanted to check here in detail before I went over there.)

Thanks,

--Kyle

From: Mark Reynolds mreynolds@redhat.com Sent: Monday, April 13, 2020 12:34 PM To: General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org; Kyle Brantley kyle@averageurl.com Subject: [389-users] Re: Issues with GSSAPI kerberos authentication - realm undefined?

On 4/13/20 2:30 PM, Mark Reynolds wrote:

Sorry not a kerberos expert but this is old doc I used to use to get it working. I would double check your /etc/krb5.conf first though.

Here is that doc

Mark

===================================================================

SASL and DS KDC Server

- HOST.DOMAIN.COM is usually "localhost.localdomain" for internal testing. Make sure the hostname is lowercase!

[1] ssh krbuser@internal.redhat.com mailto:krbuser@internal.redhat.com (password redhat) [2] sudo /usr/kerberos/sbin/kadmin.local -r EXAMPLE.COM [3] addprinc -randkey ldap/HOST.DOMAIN.COM@EXAMPLE.COM mailto:ldap/HOST.DOMAIN.COM@EXAMPLE.COM [4] ktadd -k /opt/ldap.HOST.DOMAIN.COM.keytab ldap/HOST.DOMAIN.COM@EXAMPLE.COM mailto:ldap/HOST.DOMAIN.COM@EXAMPLE.COM [5] addprinc sasltest -> use redhat as password [6] ktadd -k /opt/sasltest.keytab sasltest@EXAMPLE.COM mailto:sasltest@EXAMPLE.COM [7] addprinc t001 --> use redhat as password [8] ktadd -k /opt/ldap.t001.keytab t001@EXAMPLE.COM mailto:t001@EXAMPLE.COM [9] exit [10] sudo chmod 777 /opt/ldap.HOST.DOMAIN.COM.keytab [11] sudo chmod 777 /opt/ldap.t001.keytab [12] sudo chmod 777 /opt/sasltest.keytab

DS Server

- Get the keytabs

[1] cd /etc/dirsrv [2] wget ftp://internal.redhat.com/opt/ldap.HOST.DOMAIN.COM.keytab [3] wget ftp://internal.redhat.com/opt/sasltest.keytab [4] wget ftp://internal.redhat.com/opt/ldap.t001.keytab

- Edit /etc/krb5.conf, make sure these settings are included

[libdefaults]

default_realm: EXAMPLE.COM allow_weak_crypto = true (or 'yes')

[realms]

EXAMPLE.COM = { kdc = internal.redhat.com:88 admin_server = internal.redhat.com:749 default_domain = example.com }

[domain_realm] .redhat.com = EXAMPLE.COM redhat.com = EXAMPLE.COM .example.com = EXAMPLE.COM example.com = EXAMPLE.COM

- Edit /etc/sysconfig/dirsrv-INSTANCE

Add these two lines to

KRB5_CONFIG=/etc/krb5.conf KRB5_KTNAME=/etc/dirsrv/ldap.HOST.DOMAIN.COM.keytab

- Edit the dse.ldif/ldapmodify. This assumes there is a backend: dc=example,dc=com

dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=config changetype: modify add: passwordstoragescheme passwordstoragescheme: clear

- Add our user:

Testing

[1] cd /etc/dirsrv [2] kinit -k -t ./ldap.t001.keytab t001@EXAMPLE.COM mailto:t001@EXAMPLE.COM [3] klist

Ticket cache: FILE:/tmp/krb5cc_0 FILE://tmp/krb5cc_0 Default principal: t001@EXAMPLE.COM mailto:t001@EXAMPLE.COM

Valid starting Expires Service principal 02/08/10 14:29:33 02/09/10 14:29:33 krbtgt/EXAMPLE.COM@EXAMPLE.COM mailto:krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 02/08/10 14:29:33

[4] ldapsearch -h HOST.DOMAIN.COM -p 389 -b "dc=example,dc=com" -v -LLL -Y GSSAPI "uid=*" dn

[5] klist

Ticket cache: FILE:/tmp/krb5cc_0 FILE://tmp/krb5cc_0 Default principal: t001@EXAMPLE.COM mailto:t001@EXAMPLE.COM

Valid starting Expires Service principal 02/08/10 16:52:14 02/09/10 16:52:14 krbtgt/EXAMPLE.COM@EXAMPLE.COM mailto:krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 02/08/10 16:52:14 02/08/10 16:52:20 02/09/10 16:52:14 ldap/HOST.DOMAIN.COM@EXAMPLE.COM mailto:ldap/HOST.DOMAIN.COM@EXAMPLE.COM renew until 02/08/10 16:52:14

Troubleshooting

[1] To verify the DS server does use the user kerberos ticket for authentication, log on kdc server (internal.redhat.com), and tail -f /var/log/krb5kdc.log You should see following msgs in log:

- The first msg means the usr "t001" does get valid kerberos ticket from kdc server - The second msg means the server which use mailto:ldap/internal.redhat.com@EXAMPLE.COM "ldap/internal.redhat.com@EXAMPLE.COM" is connect with kdc for user authentication

[2] ldapsearch issues

[a] make sure you use -h "<FQDN>"

[b] error:

ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unknown error)

cause: /etc/sysconfig/dirsrv-INSTANCE, the KRB5_KTNAME was incorrect

[c] other errors, if you have verified the kerberos ticket is being used(see [1]), then recheck your sasl mappings in dse.ldif

[3] DS error logging, turn on "trace function calls" (nsslapd-errorlog-level: 1), this might provide more information.

================================================================

HTH, Mark

On 4/12/20 12:41 PM, Kyle Brantley wrote:

I'm trying to move over from OpenLDAP, as it seems that 389-ds is better supported in the RH family of products.

I've trimmed the above to just the more relevant log lines, but it's very clear that the value for "realm" is en empty string.

F31 package: 389-ds-base-1.4.2.11-1.fc31.x86_64 CentOS8 package: 389-ds-base-1.4.2.9-1.module_el8+8314+9ac085f5.x86_64

- klist after attempting an ldapwhoami: [root@ldaptest ~]# klist Ticket cache: KCM:0:39355 Default principal: kyletest@AVERAGEURL.COM mailto:kyletest@AVERAGEURL.COM

Valid starting Expires Service principal 04/12/2020 10:33:44 04/13/2020 10:33:40 krbtgt/AVERAGEURL.COM@AVERAGEURL.COM mailto:krbtgt/AVERAGEURL.COM@AVERAGEURL.COM 04/12/2020 10:33:51 04/13/2020 10:33:40 ldap/ldaptest.averageurl.com@AVERAGEURL.COM mailto:ldap/ldaptest.averageurl.com@AVERAGEURL.COM

- SASL mapping: nsSaslMapRegexString: (.*)@(.*).(.*) nsSaslMapFilterTemplate: (cn=\1) nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

- Alternative SASL mapping that I'd prefer to use: nsSaslMapRegexString: (.*)@AVERAGEURL.COM nsSaslMapFilterTemplate: (cn=\1) nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

Thanks, --Kyle

[1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....

Mark Reynolds

7:58 p.m.

New subject: Issues with GSSAPI kerberos authentication - realm undefined?

On 4/13/20 2:46 PM, Kyle Brantley wrote:

...

Thanks, Mark. I can tell that it’s an internal troubleshooting doc – and that’s great, thank you!

However, I… I don’t believe that I have any issues with my kerberos setup. The authentication from a pure krb5 perspective is happening appropriately. The tickets are being issued and I see the logs on the KDC confirming as much.

We have the pre-auth event:

kdc.averageurl.com krb5kdc[2432](info): AS_REQ (1 etypes {aes128-cts-hmac-sha1-96(17)}) 2001:470:xx:dae4: NEEDED_PREAUTH: kyletest@AVERAGEURL.COM for krbtgt/AVERAGEURL.COM@AVERAGEURL.COM, Additional pre-authentication required

The issuance of the kgbtgt ticket:

kdc.averageurl.com krb5kdc[2432](info): AS_REQ (1 etypes {aes128-cts-hmac-sha1-96(17)}) 2001:470:xx:dae4: ISSUE: authtime 1586803255, etypes {rep=aes128-cts-hmac-sha1-96(17), tkt=aes256-cts-hmac-sha1-96(18), ses=aes128-cts-hmac-sha1-96(17)}, kyletest@AVERAGEURL.COM for krbtgt/AVERAGEURL.COM@AVERAGEURL.COM

And finally, the ticket for ldap/ being issued as well:

kdc.averageurl.com krb5kdc[2433](info): TGS_REQ (1 etypes {aes128-cts-hmac-sha1-96(17))}) 2001:470:xx:dae4: ISSUE: authtime 1586803255, etypes {rep=aes128-cts-hmac-sha1-96(17), tkt=aes256-cts-hmac-sha1-96(18), ses=aes128-cts-hmac-sha1-96(17)}, kyletest@AVERAGEURL.COM for ldap/ldaptest.averageurl.com@AVERAGEURL.COM

The issue appears to be specific to what 389-ds is seeing as the realm:

DEBUG - ids_sasl_canon_user - (user=kyletest, realm=)

For reasons unknown to me, the realm isn’t being populated internally within 389-ds when the SASL mapping is taking place, even though kerberos is working as it should be.

The realm gets set by the cyrus-sasl library, the DS code has no control over it.

Did you enable trace function call logging from the troubleshooting section of that doc?

ldapmodify -D "cn=directory manager" -W dn: cn=config changetype: modify replace: nsslapd-errorlog-level nsslapd-errorlog-level: 1

But beware, this is dramatically slow the server down. So enable it, run your test, and then set the nsslapd-errorlog-level to "0" when you are done. Please share the error log output from this test.

Thanks,

Mark

...

Thanks,

--Kyle

*From:* Mark Reynolds mreynolds@redhat.com *Sent:* Monday, April 13, 2020 12:34 PM *To:* General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org; Kyle Brantley kyle@averageurl.com *Subject:* [389-users] Re: Issues with GSSAPI kerberos authentication

realm undefined?

On 4/13/20 2:30 PM, Mark Reynolds wrote:

Sorry not a kerberos expert but this is old doc I used to use to
get it working.  I would double check your /etc/krb5.conf first
though.

Here is that doc

Mark

===================================================================

SASL and DS
KDC Server


     - HOST.DOMAIN.COM is usually "localhost.localdomain" for
internal testing.  Make sure the hostname is lowercase!

   [1]  ssh krbuser@internal.redhat.com
<mailto:krbuser@internal.redhat.com> (password redhat)
   [2]  sudo /usr/kerberos/sbin/kadmin.local -r EXAMPLE.COM
   [3]  addprinc -randkey ldap/HOST.DOMAIN.COM@EXAMPLE.COM
<mailto:ldap/HOST.DOMAIN.COM@EXAMPLE.COM>
   [4]  ktadd -k /opt/ldap.HOST.DOMAIN.COM.keytab
ldap/HOST.DOMAIN.COM@EXAMPLE.COM
<mailto:ldap/HOST.DOMAIN.COM@EXAMPLE.COM>
   [5]  addprinc sasltest  -> use redhat as password
   [6]  ktadd -k /opt/sasltest.keytab sasltest@EXAMPLE.COM
<mailto:sasltest@EXAMPLE.COM>
   [7]  addprinc t001  --> use redhat as password
   [8]  ktadd -k /opt/ldap.t001.keytab t001@EXAMPLE.COM
<mailto:t001@EXAMPLE.COM>
   [9]  exit
   [10] sudo chmod 777 /opt/ldap.HOST.DOMAIN.COM.keytab
   [11] sudo chmod 777 /opt/ldap.t001.keytab
   [12] sudo chmod 777 /opt/sasltest.keytab



DS Server


   - Get the keytabs

   [1]  cd /etc/dirsrv
   [2]  wget ftp://internal.redhat.com/opt/ldap.HOST.DOMAIN.COM.keytab
   [3]  wget ftp://internal.redhat.com/opt/sasltest.keytab
   [4]  wget ftp://internal.redhat.com/opt/ldap.t001.keytab

   - Edit */etc/krb5.conf*, make sure these settings are included

    [libdefaults]

      default_realm: EXAMPLE.COM
      allow_weak_crypto = true (or 'yes')

    [realms]

    EXAMPLE.COM = {
      kdc = internal.redhat.com:88
      admin_server = internal.redhat.com:749
      default_domain = example.com
    }

    [domain_realm]
     .redhat.com = EXAMPLE.COM
     redhat.com = EXAMPLE.COM
     .example.com = EXAMPLE.COM
     example.com = EXAMPLE.COM

  - Edit /etc/sysconfig/dirsrv-INSTANCE

       Add these two lines to

         KRB5_CONFIG=/etc/krb5.conf
         KRB5_KTNAME=/etc/dirsrv/ldap.HOST.DOMAIN.COM.keytab

  - Edit the dse.ldif/ldapmodify.  This assumes there is a
backend:  dc=example,dc=com

dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
changetype: modify
replace: nsSaslMapBaseDNTemplate
nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config
changetype: modify
replace: nsSaslMapBaseDNTemplate
nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config
changetype: modify
replace: nsSaslMapBaseDNTemplate
nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config
changetype: modify
replace: nsSaslMapBaseDNTemplate
nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=config
changetype: modify
add: passwordstoragescheme
passwordstoragescheme: clear

  - Add our user:

dn: uid=t001,ou=people,dc=example,dc=com
uid: t001
givenName: test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: 001
cn: test 001
mail: t001@example.com <mailto:t001@example.com>

Testing


   [1]  cd /etc/dirsrv
   [2]  kinit -k -t ./ldap.t001.keytab t001@EXAMPLE.COM
<mailto:t001@EXAMPLE.COM>
   [3]  klist

     Ticket cache: FILE:/tmp/krb5cc_0 <FILE://tmp/krb5cc_0>
     Default principal: t001@EXAMPLE.COM <mailto:t001@EXAMPLE.COM>

     Valid starting     Expires            Service principal
     02/08/10 14:29:33  02/09/10 14:29:33
krbtgt/EXAMPLE.COM@EXAMPLE.COM <mailto:krbtgt/EXAMPLE.COM@EXAMPLE.COM>
         renew until 02/08/10 14:29:33

   [4]  ldapsearch -h HOST.DOMAIN.COM -p 389  -b
"dc=example,dc=com" -v -LLL -Y GSSAPI "uid=*" dn

   [5]  klist

    Ticket cache: FILE:/tmp/krb5cc_0 <FILE://tmp/krb5cc_0>
    Default principal: t001@EXAMPLE.COM <mailto:t001@EXAMPLE.COM>

    Valid starting     Expires            Service principal
    02/08/10 16:52:14  02/09/10 16:52:14
krbtgt/EXAMPLE.COM@EXAMPLE.COM <mailto:krbtgt/EXAMPLE.COM@EXAMPLE.COM>
        renew until 02/08/10 16:52:14
    02/08/10 16:52:20  02/09/10 16:52:14
ldap/HOST.DOMAIN.COM@EXAMPLE.COM
<mailto:ldap/HOST.DOMAIN.COM@EXAMPLE.COM>
        renew until 02/08/10 16:52:14


Troubleshooting


   [1]  To verify the DS server does use the user kerberos ticket
for authentication, log on kdc server (internal.redhat.com), and
tail -f /var/log/krb5kdc.log You should see following msgs in log:

        - The first msg means the usr "t001" does get valid
kerberos ticket from kdc server
        - The second msg means the server which use
"ldap/internal.redhat.com@EXAMPLE.COM"
<mailto:ldap/internal.redhat.com@EXAMPLE.COM> is connect with kdc
for user authentication

   Feb 08 16:46:14 internal.redhat.com krb5kdc[2726](info): AS_REQ
(12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.16.96.80: ISSUE:
authtime 1265665574, etypes {rep=1 tkt=16 ses=16},
t001@EXAMPLE.COM <mailto:t001@EXAMPLE.COM> for
krbtgt/EXAMPLE.COM@EXAMPLE.COM <mailto:krbtgt/EXAMPLE.COM@EXAMPLE.COM>

   Feb 08 16:48:34 internal.redhat.com krb5kdc[2726](info):
TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.16.96.80: ISSUE:
authtime 1265665574, etypes {rep=16 tkt=16 ses=16},
t001@EXAMPLE.COM <mailto:t001@EXAMPLE.COM> for
ldap/HOST.DOMAIN.COM.com@EXAMPLE.COM
<mailto:ldap/HOST.DOMAIN.COM.com@EXAMPLE.COM>

   [2]  ldapsearch issues

      [a] make sure you use -h "<FQDN>"

      [b] error:

        ldap_sasl_interactive_bind_s: Invalid credentials (49)
            additional info: SASL(-1): generic failure: GSSAPI
Error: Unspecified GSS failure.  Minor code may provide more
information (Unknown error)

        cause:  /etc/sysconfig/dirsrv-INSTANCE, the KRB5_KTNAME
was incorrect

      [c] other errors, if you have verified the kerberos ticket
is being used(see [1]), then recheck your sasl mappings in dse.ldif

   [3]  DS error logging, turn on "trace function calls"
(nsslapd-errorlog-level: 1), this might provide more information.

================================================================


HTH,
Mark

On 4/12/20 12:41 PM, Kyle Brantley wrote:

    I'm trying to move over from OpenLDAP, as it seems that 389-ds
    is better supported in the RH family of products.

    I've followed the RH docs to configure kerberos[1] as well as
    checking to ensure that the auth mechanisms are enabled and
    I've poked around with the SASL identity mappings. From what I
    can tell, all of these are setup correctly.

    However, every single time, the realm isn't populated with the
    kerberos realm and instead, only the username is passed. This
    results in the SASL mapping that matches the realm (correctly)
    failing to match:

    DEBUG - do_bind - BIND dn="" method=163 version=3
    DEBUG - ids_sasl_listmech - sasl library mechs:
    GSS-SPNEGO,GSSAPI,DIGEST-MD5,CRAM-MD5,PLAIN,LOGIN,ANONYMOUS
    DEBUG - ids_sasl_log - (5): GSSAPI server step 3
    DEBUG - ids_sasl_canon_user - (user=kyletest, realm=)
    DEBUG - sasl_map_domap - Trying map [Kerberos uid mapping]
    DEBUG - sasl_map_check - regex: (.*)@(.*)\.(.*), id: kyletest,
    didn't match

    I've trimmed the above to just the more relevant log lines,
    but it's very clear that the value for "realm" is en empty
    string.

    What do I need to do in order to have the realm be made
    visible to the SASL mapping component? I've searched the docs,
    both the fedora and the pagure bug trackers, searched all of
    the nsslapd-* attributes to see if I'm missing something, and
    tried on both centos8 and F31 (same results). I don't see
    anything obvious missing here (but I might just not know where
    to be looking).

    F31 package: 389-ds-base-1.4.2.11-1.fc31.x86_64
    CentOS8 package:
    389-ds-base-1.4.2.9-1.module_el8+8314+9ac085f5.x86_64

    - Kerberos setup:
    [root@ldaptest ~]# cat /etc/sysconfig/dirsrv-app
    KRB5_KTNAME=/etc/dirsrv/krb5.keytab
    [root@ldaptest ~]# kinit -kt /etc/dirsrv/krb5.keytab
    ldap/$HOSTNAME
    [root@ldaptest ~]# klist
    Ticket cache: KCM:0:9594
    Default principal: ldap/ldaptest.averageurl.com@AVERAGEURL.COM
    <mailto:ldap/ldaptest.averageurl.com@AVERAGEURL.COM>

    - klist after attempting an ldapwhoami:
    [root@ldaptest ~]# klist
    Ticket cache: KCM:0:39355
    Default principal: kyletest@AVERAGEURL.COM
    <mailto:kyletest@AVERAGEURL.COM>

    Valid starting       Expires              Service principal
    04/12/2020 10:33:44  04/13/2020 10:33:40
    krbtgt/AVERAGEURL.COM@AVERAGEURL.COM
    <mailto:krbtgt/AVERAGEURL.COM@AVERAGEURL.COM>
    04/12/2020 10:33:51  04/13/2020 10:33:40
    ldap/ldaptest.averageurl.com@AVERAGEURL.COM
    <mailto:ldap/ldaptest.averageurl.com@AVERAGEURL.COM>

    - SASL mapping:
    nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
    nsSaslMapFilterTemplate: (cn=\1)
    nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

    - Alternative SASL mapping that I'd prefer to use:
    nsSaslMapRegexString: \(.*\)@AVERAGEURL\.COM
    nsSaslMapFilterTemplate: (cn=\1)
    nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com


    Thanks,
    --Kyle


    [1]
    https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/configuring_kerberos
    _______________________________________________
    389-users mailing list -- 389-users@lists.fedoraproject.org
    <mailto:389-users@lists.fedoraproject.org>
    To unsubscribe send an email to
    389-users-leave@lists.fedoraproject.org
    <mailto:389-users-leave@lists.fedoraproject.org>
    Fedora Code of Conduct:
    https://docs.fedoraproject.org/en-US/project/code-of-conduct/
    List Guidelines:
    https://fedoraproject.org/wiki/Mailing_list_guidelines
    List Archives:
    https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

-- 

389 Directory Server Development Team



_______________________________________________

389-users mailing list --389-users@lists.fedoraproject.org  <mailto:389-users@lists.fedoraproject.org>

To unsubscribe send an email to389-users-leave@lists.fedoraproject.org  <mailto:389-users-leave@lists.fedoraproject.org>

Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

-- 389 Directory Server Development Team

389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....

-- 389 Directory Server Development Team

Kyle Brantley

8:22 p.m.

New subject: Issues with GSSAPI kerberos authentication - realm undefined?

Log here, but it’s not really any more illuminating: https://paste.centos.org/view/raw/ec0588a0

And filtered down to just lines that contain ‘sasl’: https://paste.centos.org/view/raw/ea345620

From what I can tell, the first time the SASL identity is shown in any form, the realm is absent. Timestamp of my “ldapwhois” is 13:04:52. Timestamp of me changing the logging back to 0 is 13:05:42.

Yes – the mapping succeeded – but that’s because I’ve removed the SASL mappings that check for the realm in specific.

(And sorry for the top-posting… I’m away from the computer where I sent my initial mail, I’ll respond in the future in a better format.)

Thanks,

--Kyle

From: Mark Reynolds mreynolds@redhat.com Sent: Monday, April 13, 2020 12:59 PM To: General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org; Kyle Brantley kyle@averageurl.com Subject: [389-users] Re: Issues with GSSAPI kerberos authentication - realm undefined?

On 4/13/20 2:46 PM, Kyle Brantley wrote:

Thanks, Mark. I can tell that it’s an internal troubleshooting doc – and that’s great, thank you!

We have the pre-auth event:

kdc.averageurl.com krb5kdc[2432](info): AS_REQ (1 etypes {aes128-cts-hmac-sha1-96(17)}) 2001:470:xx:dae4: NEEDED_PREAUTH: kyletest@AVERAGEURL.COM mailto:kyletest@AVERAGEURL.COM for krbtgt/AVERAGEURL.COM@AVERAGEURL.COM mailto:krbtgt/AVERAGEURL.COM@AVERAGEURL.COM , Additional pre-authentication required

The issuance of the kgbtgt ticket:

And finally, the ticket for ldap/ being issued as well:

The issue appears to be specific to what 389-ds is seeing as the realm:

DEBUG - ids_sasl_canon_user - (user=kyletest, realm=)

For reasons unknown to me, the realm isn’t being populated internally within 389-ds when the SASL mapping is taking place, even though kerberos is working as it should be.

The realm gets set by the cyrus-sasl library, the DS code has no control over it.

Did you enable trace function call logging from the troubleshooting section of that doc?

ldapmodify -D "cn=directory manager" -W dn: cn=config changetype: modify replace: nsslapd-errorlog-level nsslapd-errorlog-level: 1

But beware, this is dramatically slow the server down. So enable it, run your test, and then set the nsslapd-errorlog-level to "0" when you are done. Please share the error log output from this test.

Thanks,

Mark

Thanks,

--Kyle

From: Mark Reynolds mailto:mreynolds@redhat.com mreynolds@redhat.com Sent: Monday, April 13, 2020 12:34 PM To: General discussion list for the 389 Directory server project. mailto:389-users@lists.fedoraproject.org 389-users@lists.fedoraproject.org; Kyle Brantley mailto:kyle@averageurl.com kyle@averageurl.com Subject: [389-users] Re: Issues with GSSAPI kerberos authentication - realm undefined?

On 4/13/20 2:30 PM, Mark Reynolds wrote:

Sorry not a kerberos expert but this is old doc I used to use to get it working. I would double check your /etc/krb5.conf first though.

Here is that doc

Mark

===================================================================

SASL and DS KDC Server

- HOST.DOMAIN.COM is usually "localhost.localdomain" for internal testing. Make sure the hostname is lowercase!

DS Server

- Get the keytabs

[1] cd /etc/dirsrv [2] wget ftp://internal.redhat.com/opt/ldap.HOST.DOMAIN.COM.keytab [3] wget ftp://internal.redhat.com/opt/sasltest.keytab [4] wget ftp://internal.redhat.com/opt/ldap.t001.keytab

- Edit /etc/krb5.conf, make sure these settings are included

[libdefaults]

default_realm: EXAMPLE.COM allow_weak_crypto = true (or 'yes')

[realms]

EXAMPLE.COM = { kdc = internal.redhat.com:88 admin_server = internal.redhat.com:749 default_domain = example.com }

[domain_realm] .redhat.com = EXAMPLE.COM redhat.com = EXAMPLE.COM .example.com = EXAMPLE.COM example.com = EXAMPLE.COM

- Edit /etc/sysconfig/dirsrv-INSTANCE

Add these two lines to

KRB5_CONFIG=/etc/krb5.conf KRB5_KTNAME=/etc/dirsrv/ldap.HOST.DOMAIN.COM.keytab

- Edit the dse.ldif/ldapmodify. This assumes there is a backend: dc=example,dc=com

dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapBaseDNTemplate nsSaslMapBaseDNTemplate: dc=example,dc=com

dn: cn=config changetype: modify add: passwordstoragescheme passwordstoragescheme: clear

- Add our user:

Testing

[1] cd /etc/dirsrv [2] kinit -k -t ./ldap.t001.keytab t001@EXAMPLE.COM mailto:t001@EXAMPLE.COM [3] klist

Ticket cache: FILE:/tmp/krb5cc_0 FILE://tmp/krb5cc_0 Default principal: t001@EXAMPLE.COM mailto:t001@EXAMPLE.COM

Valid starting Expires Service principal 02/08/10 14:29:33 02/09/10 14:29:33 krbtgt/EXAMPLE.COM@EXAMPLE.COM mailto:krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 02/08/10 14:29:33

[4] ldapsearch -h HOST.DOMAIN.COM -p 389 -b "dc=example,dc=com" -v -LLL -Y GSSAPI "uid=*" dn

[5] klist

Ticket cache: FILE:/tmp/krb5cc_0 FILE://tmp/krb5cc_0 Default principal: t001@EXAMPLE.COM mailto:t001@EXAMPLE.COM

Troubleshooting

[1] To verify the DS server does use the user kerberos ticket for authentication, log on kdc server (internal.redhat.com), and tail -f /var/log/krb5kdc.log You should see following msgs in log:

[2] ldapsearch issues

[a] make sure you use -h "<FQDN>"

[b] error:

ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unknown error)

cause: /etc/sysconfig/dirsrv-INSTANCE, the KRB5_KTNAME was incorrect

[c] other errors, if you have verified the kerberos ticket is being used(see [1]), then recheck your sasl mappings in dse.ldif

[3] DS error logging, turn on "trace function calls" (nsslapd-errorlog-level: 1), this might provide more information.

================================================================

HTH, Mark

On 4/12/20 12:41 PM, Kyle Brantley wrote:

I'm trying to move over from OpenLDAP, as it seems that 389-ds is better supported in the RH family of products.

I've trimmed the above to just the more relevant log lines, but it's very clear that the value for "realm" is en empty string.

F31 package: 389-ds-base-1.4.2.11-1.fc31.x86_64 CentOS8 package: 389-ds-base-1.4.2.9-1.module_el8+8314+9ac085f5.x86_64

- klist after attempting an ldapwhoami: [root@ldaptest ~]# klist Ticket cache: KCM:0:39355 Default principal: kyletest@AVERAGEURL.COM mailto:kyletest@AVERAGEURL.COM

- SASL mapping: nsSaslMapRegexString: (.*)@(.*).(.*) nsSaslMapFilterTemplate: (cn=\1) nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

- Alternative SASL mapping that I'd prefer to use: nsSaslMapRegexString: (.*)@AVERAGEURL.COM nsSaslMapFilterTemplate: (cn=\1) nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

Thanks, --Kyle

-- 389 Directory Server Development Team _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... -- 389 Directory Server Development Team _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... -- 389 Directory Server Development Team

William Brown

14 Apr 14 Apr

12:28 a.m.

New subject: Issues with GSSAPI kerberos authentication - realm undefined?

...

On 14 Apr 2020, at 05:22, Kyle Brantley kyle@averageurl.com wrote:

Log here, but it’s not really any more illuminating: https://paste.centos.org/view/raw/ec0588a0 And filtered down to just lines that contain ‘sasl’: https://paste.centos.org/view/raw/ea345620

From what I can tell, the first time the SASL identity is shown in any form, the realm is absent. Timestamp of my “ldapwhois” is 13:04:52. Timestamp of me changing the logging back to 0 is 13:05:42.

...
...
...

SASL mapping:

nsSaslMapRegexString: (.*)@(.*).(.*) nsSaslMapFilterTemplate: (cn=\1) nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

Alternative SASL mapping that I'd prefer to use:

nsSaslMapRegexString: (.*)@AVERAGEURL.COM nsSaslMapFilterTemplate: (cn=\1) nsSaslMapBaseDNTemplate: ou=accounts,dc=app,dc=averageurl,dc=com

Hi there,

The SASL mappings that are provided by default make a lot of assumptions, and honestly, I don't really like them :)

1: remove all sasl maps that exist under cn=mapping,cn=sasl,cn=config 2: Create your map as:

cn=krb,cn=mapping,cn=sasl,dc=config cn: krb nsSaslMapRegexString: (.*) nsSaslMapBaseDNTemplate: ou=account,dc=.... nsSaslMapFilterTemplate: (uid=\1)

3: restart your instance 4: check if that works :)

According to my notes, there is a bug in sasl where with gssapi/krb it doesn't pass the realm through correctly, so your map needs to omit it.

— Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server SUSE Labs

1538

Age (days ago)

1539

Last active (days ago)

389-users@lists.fedoraproject.org

6 comments

3 participants

tags (0)

participants (3)

Kyle Brantley
Mark Reynolds
William Brown