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:
kylet...@averageurl.com for krbtgt/averageurl....@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)},
kylet...@averageurl.com for krbtgt/averageurl....@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)},
kylet...@averageurl.com for ldap/ldaptest.averageurl....@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
(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 <mreyno...@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 <k...@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
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 krbu...@internal.redhat.com
<mailto:krbu...@internal.redhat.com> (password redhat)
[2] sudo /usr/kerberos/sbin/kadmin.local -r EXAMPLE.COM
[3] addprinc -randkey ldap/host.domain....@example.com
<mailto:ldap/host.domain....@example.com>
[4] ktadd -k /opt/ldap.HOST.DOMAIN.COM.keytab
ldap/host.domain....@example.com
<mailto:ldap/host.domain....@example.com>
[5] addprinc sasltest -> use redhat as password
[6] ktadd -k /opt/sasltest.keytab saslt...@example.com
<mailto:saslt...@example.com>
[7] addprinc t001 --> use redhat as password
[8] ktadd -k /opt/ldap.t001.keytab t...@example.com
<mailto:t...@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: t...@example.com <mailto:t...@example.com>
Testing
[1] cd /etc/dirsrv
[2] kinit -k -t ./ldap.t001.keytab t...@example.com
<mailto:t...@example.com>
[3] klist
Ticket cache: FILE:/tmp/krb5cc_0 <FILE://tmp/krb5cc_0>
Default principal: t...@example.com <mailto:t...@example.com>
Valid starting Expires Service principal
02/08/10 14:29:33 02/09/10 14:29:33
krbtgt/example....@example.com <mailto:krbtgt/example....@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: t...@example.com <mailto:t...@example.com>
Valid starting Expires Service principal
02/08/10 16:52:14 02/09/10 16:52:14
krbtgt/example....@example.com <mailto:krbtgt/example....@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....@example.com
<mailto:ldap/host.domain....@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....@example.com"
<mailto:ldap/internal.redhat....@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},
t...@example.com <mailto:t...@example.com> for
krbtgt/example....@example.com <mailto:krbtgt/example....@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},
t...@example.com <mailto:t...@example.com> for
ldap/host.domain.com....@example.com
<mailto:ldap/host.domain.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....@averageurl.com
<mailto:ldap/ldaptest.averageurl....@averageurl.com>
- klist after attempting an ldapwhoami:
[root@ldaptest ~]# klist
Ticket cache: KCM:0:39355
Default principal: kylet...@averageurl.com
<mailto:kylet...@averageurl.com>
Valid starting Expires Service principal
04/12/2020 10:33:44 04/13/2020 10:33:40
krbtgt/averageurl....@averageurl.com
<mailto:krbtgt/averageurl....@averageurl.com>
04/12/2020 10:33:51 04/13/2020 10:33:40
ldap/ldaptest.averageurl....@averageurl.com
<mailto:ldap/ldaptest.averageurl....@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-le...@lists.fedoraproject.org
<mailto:389-users-le...@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-le...@lists.fedoraproject.org
<mailto:389-users-le...@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-le...@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-le...@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
