Hi!
I kerberized ldap: dn: cn=config objectClass: olcGlobal cn: config olcAuthzRegexp: uid=(.*),cn=example.com,cn=gssapi,cn=auth uid=$1,ou=Users,dc=example,dc=com olcSaslHost: srv.example.com olcSaslRealm: EXAMPLE.COM
In /etc/ldap/ldap.conf: BASE dc=example,dc=com URI ldap://srv.example.com SASL_MECH GSSAPI
In /etc/ldap.conf base dc=example,dc=com uri ldap://srv.example.com ldap_version 3 rootbinddn cn=adm,dc=example,dc=com pam_password md5
I now try to connect to my ldap server:
client:~$ kinit user Password for user@EXAMPLE.COM: client:~$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: user@EXAMPLE.COM
Valid starting Expires Service principal 01/21/11 11:32:03 01/21/11 21:32:03 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 01/22/11 11:31:58
client:~$ ldapsearch -H ldap://srv.example.com SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database
client:~$ ldapsearch -D uid=user,dc=example,dc=com -H ldap://srv.example.com ldap_bind: Server is unwilling to perform (53) additional info: unauthenticated bind (DN with no password) disallowed
The user in question exists: dn: cn=user user,ou=Users,dc=example,dc=com givenName: user sn: user cn: user user uid: user objectClass: inetOrgPerson objectClass: posixAccount objectClass: top uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/user loginShell: /bin/zsh
Any idea what is wrong? As far as I see: I do have a tgt and thus I shall be authenticated. But I am not granted access! Any idea why?
Hello Thomas,
2011/1/21 Thomas Schweikle tps@vr-web.de
Hi!
I kerberized ldap:
Maybe you missed "olcAuthzPolicy"
client:~$ ldapsearch -H ldap://srv.example.com
SASL/DIGEST-MD5 authentication started
Is not using GSSAPI.
Does your slapd have a kerberos principal (ldap/srv.example.com@EXAMPLE.COM) ?
Did you tell slapd where its kerberos keytab file is (export KRB5_KTNAME=/path/to/keytab)?
Regards, Norberto
Am Fri, 21 Jan 2011 11:45:53 +0100 schrieb Thomas Schweikle tps@vr-web.de:
Hi!
I kerberized ldap: dn: cn=config objectClass: olcGlobal cn: config olcAuthzRegexp: uid=(.*),cn=example.com,cn=gssapi,cn=auth uid=$1,ou=Users,dc=example,dc=com olcSaslHost: srv.example.com olcSaslRealm: EXAMPLE.COM
In /etc/ldap/ldap.conf: BASE dc=example,dc=com URI ldap://srv.example.com SASL_MECH GSSAPI
In /etc/ldap.conf base dc=example,dc=com uri ldap://srv.example.com ldap_version 3 rootbinddn cn=adm,dc=example,dc=com pam_password md5
This is not an OPenLDAP configuration file.
I now try to connect to my ldap server:
client:~$ ldapsearch -H ldap://srv.example.com SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database
It seems that slapd doesn't have knowledge of sasl mechanism GSSAPI, check with ldapsearch -x -LLL -H ldap://srv.example.com -b "" -s base \ suportedSASLmechanisms
client:~$ ldapsearch -D uid=user,dc=example,dc=com -H ldap://srv.example.com ldap_bind: Server is unwilling to perform (53) additional info: unauthenticated bind (DN with no password) disallowed
You want to do a sasl bind with GSSAPI mechanism
ldapsearch -Y GSSAPI -H ldap://srv.example.com
-Dieter
On Fri, Jan 21, 2011 at 11:45:53AM +0100, Thomas Schweikle wrote:
client:~$ ldapsearch -H ldap://srv.example.com SASL/DIGEST-MD5 authentication started
Try adding -Y GSSAPI to ldapsearch command line.
I found the same (that DIGEST-MD5 was being preferred over GSSAPI). You can fix it by disabling DIGEST-MD5.
Under Ubuntu, I did this by
# vi /etc/ldap/sasl2/slapd.conf mech_list: gssapi external
The location of this config file may differ under other distros.
Am 21.01.2011 13:15, schrieb Brian Candler:
On Fri, Jan 21, 2011 at 11:45:53AM +0100, Thomas Schweikle wrote:
client:~$ ldapsearch -H ldap://srv.example.com SASL/DIGEST-MD5 authentication started
Try adding -Y GSSAPI to ldapsearch command line.
I found the same (that DIGEST-MD5 was being preferred over GSSAPI). You can fix it by disabling DIGEST-MD5.
Under Ubuntu, I did this by
# vi /etc/ldap/sasl2/slapd.conf mech_list: gssapi externalThe location of this config file may differ under other distros.
I do have the directory, but not the file ... do I have to create it myself or is it part of a package I did not install?
On Fri, Jan 21, 2011 at 04:52:09PM +0100, Thomas Schweikle wrote:
I found the same (that DIGEST-MD5 was being preferred over GSSAPI). You can fix it by disabling DIGEST-MD5.
Under Ubuntu, I did this by
# vi /etc/ldap/sasl2/slapd.conf mech_list: gssapi externalThe location of this config file may differ under other distros.
I do have the directory, but not the file ... do I have to create it myself or is it part of a package I did not install?
You have to create it.
Am 22.01.2011 17:04, schrieb Brian Candler:
On Fri, Jan 21, 2011 at 04:52:09PM +0100, Thomas Schweikle wrote:
I found the same (that DIGEST-MD5 was being preferred over GSSAPI). You can fix it by disabling DIGEST-MD5.
Under Ubuntu, I did this by
# vi /etc/ldap/sasl2/slapd.conf mech_list: gssapi externalThe location of this config file may differ under other distros.
I do have the directory, but not the file ... do I have to create it myself or is it part of a package I did not install?
You have to create it.
OK. Created the file. It holds: mech_list: gssapi external keytab: /etc/ldap/krb5.ldap sasldb_path: /etc/ldap/sasl2/passwd.db
Had a look at the rights for /etc/ldap/krb5.ldap: -rw------- 1 openldap openldap 278 2011-01-21 10:54 /etc/ldap/krb5.ldap
slapd is running as: openldap 4744 0.0 0.9 115800 5008 ? Ssl 00:02 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap
Seems OK. Next I tried: $ ldapsearch -Y GSSAPI -LLL -H ldap://srv.example.com -s "base" -b "" supportedSASLMechanisms SASL/GSSAPI authentication started SASL username: tschweikle@XOMPU.DE SASL SSF: 56 SASL data security layer installed. dn: supportedSASLMechanisms: GSSAPI
Works!
Next try: $ldapsearch -Y GSSAPI -H ldap://srv.example.com -LLL -b "dc=example,dc=com" "(objectclass=*)"
... returns the whole database! Fine! Looks like I've solved the issues with your help! Thanks a lot!
On 21/01/11 11:45 +0100, Thomas Schweikle wrote:
Hi!
I kerberized ldap: dn: cn=config objectClass: olcGlobal cn: config olcAuthzRegexp: uid=(.*),cn=example.com,cn=gssapi,cn=auth uid=$1,ou=Users,dc=example,dc=com olcSaslHost: srv.example.com olcSaslRealm: EXAMPLE.COM
In /etc/ldap/ldap.conf: BASE dc=example,dc=com URI ldap://srv.example.com SASL_MECH GSSAPI
In /etc/ldap.conf base dc=example,dc=com uri ldap://srv.example.com ldap_version 3 rootbinddn cn=adm,dc=example,dc=com pam_password md5
I now try to connect to my ldap server:
client:~$ kinit user Password for user@EXAMPLE.COM: client:~$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: user@EXAMPLE.COM
Valid starting Expires Service principal 01/21/11 11:32:03 01/21/11 21:32:03 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 01/22/11 11:31:58
client:~$ ldapsearch -H ldap://srv.example.com SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database
See the FAQ entry on OpenLDAP+SASL+GSSAPI at:
http://www.cyrusimap.org/mediawiki/index.php/FAQ
Am 21.01.2011 16:02, schrieb Dan White:
On 21/01/11 11:45 +0100, Thomas Schweikle wrote:
Hi!
I kerberized ldap: dn: cn=config objectClass: olcGlobal cn: config olcAuthzRegexp: uid=(.*),cn=example.com,cn=gssapi,cn=auth uid=$1,ou=Users,dc=example,dc=com olcSaslHost: srv.example.com olcSaslRealm: EXAMPLE.COM
In /etc/ldap/ldap.conf: BASE dc=example,dc=com URI ldap://srv.example.com SASL_MECH GSSAPI
In /etc/ldap.conf base dc=example,dc=com uri ldap://srv.example.com ldap_version 3 rootbinddn cn=adm,dc=example,dc=com pam_password md5
I now try to connect to my ldap server:
client:~$ kinit user Password for user@EXAMPLE.COM: client:~$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: user@EXAMPLE.COM
Valid starting Expires Service principal 01/21/11 11:32:03 01/21/11 21:32:03 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 01/22/11 11:31:58
client:~$ ldapsearch -H ldap://srv.example.com SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database
See the FAQ entry on OpenLDAP+SASL+GSSAPI at:
This refers to "pluginviewer": This program doesn't exist on the system. What package is it in on debian/ubuntu?
On 21/01/11 17:06 +0100, Thomas Schweikle wrote:
Am 21.01.2011 16:02, schrieb Dan White:
See the FAQ entry on OpenLDAP+SASL+GSSAPI at:
This refers to "pluginviewer": This program doesn't exist on the system. What package is it in on debian/ubuntu?
On Debian based systems, it's renamed as saslpluginviewer. It's located in the sasl2-bin package. The GSSAPI mechanism is installed in one of:
libsasl2-modules-gssapi-heimdal libsasl2-modules-gssapi-mit
Am 21.01.2011 17:17, schrieb Dan White:
On 21/01/11 17:06 +0100, Thomas Schweikle wrote:
Am 21.01.2011 16:02, schrieb Dan White:
See the FAQ entry on OpenLDAP+SASL+GSSAPI at:
This refers to "pluginviewer": This program doesn't exist on the system. What package is it in on debian/ubuntu?
On Debian based systems, it's renamed as saslpluginviewer. It's located in the sasl2-bin package. The GSSAPI mechanism is installed in one of:
libsasl2-modules-gssapi-heimdal libsasl2-modules-gssapi-mit
Package sasl2-bin wasn't installed, libsasl2-modules-gssapi-mit was. Now I have:
Plugin "gssapiv2" [loaded], API version: 4 SASL mechanism: GSSAPI, best SSF: 56 security flags: NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|PASS_CREDENTIALS|MUTUAL_AUTH features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION|NEED_SERVER_FQDN
#ldapsearch -LLL -x -H ldap://srv.example.com -s "base" -b "" supportedSASLMechanisms dn: supportedSASLMechanisms: GSSAPI
#ldapsearch -Y GSSAPI -LLL -H ldap://srv.example.com -s "base" -b "" supportedSASLMechanisms SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Permission denied)
Within the credentials cache: #klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: user@XOMPU.DE
Valid starting Expires Service principal 01/21/11 11:32:03 01/21/11 21:32:03 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 01/22/11 11:31:58 01/21/11 16:20:04 01/21/11 21:32:03 host/srv.example.com@EXAMPLE.COM renew until 01/22/11 11:31:58 01/21/11 16:46:15 01/21/11 21:32:03 ldap/srv.example.com@EXAMPLE.COM renew until 01/22/11 11:31:58
I keep getting Permission Denied errors.
On 21/01/11 17:51 +0100, Thomas Schweikle wrote:
Am 21.01.2011 17:17, schrieb Dan White:
On Debian based systems, it's renamed as saslpluginviewer. It's located in the sasl2-bin package. The GSSAPI mechanism is installed in one of:
libsasl2-modules-gssapi-heimdal libsasl2-modules-gssapi-mit
Package sasl2-bin wasn't installed, libsasl2-modules-gssapi-mit was. Now I have:
Plugin "gssapiv2" [loaded], API version: 4 SASL mechanism: GSSAPI, best SSF: 56 security flags: NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|PASS_CREDENTIALS|MUTUAL_AUTH features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION|NEED_SERVER_FQDN
#ldapsearch -LLL -x -H ldap://srv.example.com -s "base" -b "" supportedSASLMechanisms dn: supportedSASLMechanisms: GSSAPI
#ldapsearch -Y GSSAPI -LLL -H ldap://srv.example.com -s "base" -b "" supportedSASLMechanisms SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Permission denied)
Within the credentials cache: #klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: user@XOMPU.DE
Valid starting Expires Service principal 01/21/11 11:32:03 01/21/11 21:32:03 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 01/22/11 11:31:58 01/21/11 16:20:04 01/21/11 21:32:03 host/srv.example.com@EXAMPLE.COM renew until 01/22/11 11:31:58 01/21/11 16:46:15 01/21/11 21:32:03 ldap/srv.example.com@EXAMPLE.COM renew until 01/22/11 11:31:58
I keep getting Permission Denied errors.
That error (Permission denied) may be generated by the server. Verify that the keytab file you're using is readable by the openldap user or group.
Am Fri, 21 Jan 2011 17:51:03 +0100 schrieb Thomas Schweikle tps@vr-web.de:
Am 21.01.2011 17:17, schrieb Dan White:
On 21/01/11 17:06 +0100, Thomas Schweikle wrote:
Am 21.01.2011 16:02, schrieb Dan White:
[...]
#ldapsearch -LLL -x -H ldap://srv.example.com -s "base" -b "" supportedSASLMechanisms dn: supportedSASLMechanisms: GSSAPI
#ldapsearch -Y GSSAPI -LLL -H ldap://srv.example.com -s "base" -b "" supportedSASLMechanisms SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Permission denied)
The user that runs slapd has no access to a keytab file.
-Dieter
openldap-technical@openldap.org
-
Brian Candler -
Dan White -
Dieter Kluenter -
Thomas Schweikle -
zoolook