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 usera@PRISM.GATECH.EDU Password for usera@PRISM.GATECH.EDU: $ klist Ticket cache: FILE:/tmp/krb5cc_651342_Bepfv28166 Default principal: usera@PRISM.GATECH.EDU
Valid starting Expires Service principal 03/06/14 16:55:07 03/07/14 16:55:07 krbtgt/PRISM.GATECH.EDU@PRISM.GATECH.EDU $ ldapsearch -Y GSSAPI -H ldap://servera.iem.gatech.edu -LLL -b '' -s base 'objectclass=*' > /dev/null SASL/GSSAPI authentication started SASL username: usera@PRISM.GATECH.EDU SASL SSF: 56 SASL data security layer installed. $ ldapsearch -X userb@PRISM.GATECH.EDU -Y GSSAPI -H ldap://servera.iem.gatech.edu -LLL -b '' -s base 'objectclass=*' > /dev/null SASL/GSSAPI authentication started SASL username: userb@PRISM.GATECH.EDU 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?
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 usera@PRISM.GATECH.EDU <mailto:usera@PRISM.GATECH.EDU> Password for usera@PRISM.GATECH.EDU <mailto:usera@PRISM.GATECH.EDU>: $ klist Ticket cache: FILE:/tmp/krb5cc_651342_Bepfv28166 Default principal: usera@PRISM.GATECH.EDU <mailto:usera@PRISM.GATECH.EDU> Valid starting Expires Service principal 03/06/14 16:55:07 03/07/14 16:55:07 krbtgt/PRISM.GATECH.EDU@PRISM.GATECH.EDU <mailto:krbtgt/PRISM.GATECH.EDU@PRISM.GATECH.EDU> $ ldapsearch -Y GSSAPI -H ldap://servera.iem.gatech.edu -LLL -b '' -s base 'objectclass=*' > /dev/null SASL/GSSAPI authentication started SASL username: usera@PRISM.GATECH.EDU <mailto:usera@PRISM.GATECH.EDU> SASL SSF: 56 SASL data security layer installed. $ ldapsearch -X userb@PRISM.GATECH.EDU <mailto:userb@PRISM.GATECH.EDU> -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: userb@PRISM.GATECH.EDU <mailto:userb@PRISM.GATECH.EDU> 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 - U1The 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 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On 03/06/2014 04:17 PM, Paul Robert Marino wrote:
This is an issue with the LDAP search command which is part of the openldap project not 389 server. That said I think it ignores the -X if you only have one cached credential and are using it in combination with the -Y GSSAPI option further more if you want it to prompt you for a password you need to add a -W
I suspect it's not just openldap ldapsearch, but any LDAP client that can issue a SASL/GSSAPI bind and pass in a different authzid. 389 should have a way to disallow this, or explicitly allow this, like a proxy bind.
-- Sent from my HP Pre3
On Mar 6, 2014 17:28, Rich Megginson rmeggins@redhat.com wrote:
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 usera@PRISM.GATECH.EDU <mailto:usera@PRISM.GATECH.EDU> Password for usera@PRISM.GATECH.EDU <mailto:usera@PRISM.GATECH.EDU>: $ klist Ticket cache: FILE:/tmp/krb5cc_651342_Bepfv28166 Default principal: usera@PRISM.GATECH.EDU <mailto:usera@PRISM.GATECH.EDU> Valid starting Expires Service principal 03/06/14 16:55:07 03/07/14 16:55:07 krbtgt/PRISM.GATECH.EDU@PRISM.GATECH.EDU <mailto:krbtgt/PRISM.GATECH.EDU@PRISM.GATECH.EDU> $ ldapsearch -Y GSSAPI -H ldap://servera.iem.gatech.edu -LLL -b '' -s base 'objectclass=*' > /dev/null SASL/GSSAPI authentication started SASL username: usera@PRISM.GATECH.EDU <mailto:usera@PRISM.GATECH.EDU> SASL SSF: 56 SASL data security layer installed. $ ldapsearch -X userb@PRISM.GATECH.EDU <mailto:userb@PRISM.GATECH.EDU> -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: userb@PRISM.GATECH.EDU <mailto:userb@PRISM.GATECH.EDU> 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 - U1The 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 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
This isn't a client issue, this is a server issue. The server is allowing me to bind to one user using another user's credentials. It's the server's responsibility to verify proper credentials on bind requests.
On Mar 6, 2014, at 6:17 PM, Paul Robert Marino prmarino1@gmail.com wrote:
This is an issue with the LDAP search command which is part of the openldap project not 389 server. That said I think it ignores the -X if you only have one cached credential and are using it in combination with the -Y GSSAPI option further more if you want it to prompt you for a password you need to add a -W
Not sure, but if there is, it should be on (ignore authzid) by default. Please file a ticket.
Shucks, I was hoping for a quick answer, some setting I had overlooked.
We're running a version that's about a year old, "389-Directory/1.2.11.15 B2013.100.2247". I think I'll stand up a test server running whatever version is currently in Stable and see if the issue might have already been fixed. I feel more comfortable opening a ticket on that release rather than on what we're running.
389-users@lists.fedoraproject.org
-
Paul Robert Marino -
Rich Megginson -
Robert Viduya