On 03/06/2014 03:13 PM, Robert Viduya wrote:
We're trying to get GSSAPI authentication working with 389 and
following the doc page on the website, I think I've gotten it working
a little too well.
We're using the stock ldapsearch command that comes with RHN, I
believe it's from openldap. Here's a command log
$ kinit [email protected] <mailto:[email protected]>
Password for [email protected] <mailto:[email protected]>:
$ klist
Ticket cache: FILE:/tmp/krb5cc_651342_Bepfv28166
Default principal: [email protected]
<mailto:[email protected]>
Valid starting Expires Service principal
03/06/14 16:55:07 03/07/14 16:55:07
krbtgt/[email protected]
<mailto:krbtgt/[email protected]>
$ ldapsearch -Y GSSAPI -H ldap://servera.iem.gatech.edu -LLL -b ''
-s base 'objectclass=*' > /dev/null
SASL/GSSAPI authentication started
SASL username: [email protected] <mailto:[email protected]>
SASL SSF: 56
SASL data security layer installed.
$ ldapsearch -X [email protected]
<mailto:[email protected]> -Y GSSAPI -H
ldap://servera.iem.gatech.edu <http://servera.iem.gatech.edu> -LLL
-b '' -s base 'objectclass=*' > /dev/null
SASL/GSSAPI authentication started
SASL username: [email protected] <mailto:[email protected]>
SASL SSF: 56
SASL data security layer installed.
and here's the relevant access log entries:
[06/Mar/2014:16:55:18 -0500] conn=1387 fd=64 slot=64 connection
from 192.168.232.4 to 192.168.232.4
[06/Mar/2014:16:55:18 -0500] conn=1387 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[06/Mar/2014:16:55:18 -0500] conn=1387 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[06/Mar/2014:16:55:18 -0500] conn=1387 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[06/Mar/2014:16:55:18 -0500] conn=1387 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[06/Mar/2014:16:55:18 -0500] conn=1387 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[06/Mar/2014:16:55:18 -0500] conn=1387 op=2 RESULT err=0 tag=97
nentries=0
etime=0
dn="uid=usera,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu"
[06/Mar/2014:16:55:18 -0500] conn=1387 op=3 SRCH base="" scope=0
filter="(objectClass=*)" attrs=ALL
[06/Mar/2014:16:55:18 -0500] conn=1387 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[06/Mar/2014:16:55:18 -0500] conn=1387 op=4 UNBIND
[06/Mar/2014:16:55:18 -0500] conn=1387 op=4 fd=64 closed - U1
[06/Mar/2014:16:55:25 -0500] conn=1388 fd=64 slot=64 connection
from 192.168.232.4 to 192.168.232.4
[06/Mar/2014:16:55:25 -0500] conn=1388 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[06/Mar/2014:16:55:25 -0500] conn=1388 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[06/Mar/2014:16:55:25 -0500] conn=1388 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[06/Mar/2014:16:55:25 -0500] conn=1388 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[06/Mar/2014:16:55:25 -0500] conn=1388 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[06/Mar/2014:16:55:25 -0500] conn=1388 op=2 RESULT err=0 tag=97
nentries=0
etime=0
dn="uid=userb,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu"
[06/Mar/2014:16:55:25 -0500] conn=1388 op=3 SRCH base="" scope=0
filter="(objectClass=*)" attrs=ALL
[06/Mar/2014:16:55:25 -0500] conn=1388 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[06/Mar/2014:16:55:25 -0500] conn=1388 op=4 UNBIND
[06/Mar/2014:16:55:25 -0500] conn=1388 op=4 fd=64 closed - U1
The issue is that if we do the ldapsearch without specifying an
authzid (the "-X" option to ldapsearch), the bind correctly binds to
DN that maps to the Kerberos principal name. However, if we specify
an authzid that's different than what we kinitted to, the directory
server binds to the DN that maps to that authzid even though we don't
have the credentials for that user. It uses usera's credentials to
bind to userb's DN.
My question is, is there a configuration setting somewhere that would
make the directory server ignore any passed in authzid when using
GSSAPI and just use what's in the credential cache?
Not sure, but if there is, it should be on (ignore authzid) by default.
Please file a ticket.
--
389 users mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/389-users
