7:52 p.m.
I'm looking for a little help concerning the below error I get when I do
an ldapsearch:
root@mytest:~# ldapsearch -Y GSSAPI
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 ()
That error is pretty generic to me and the searching I've done to find a
solution has not yielded anything successful. I have MIT Kerberos and
SASL setup and I'm able to successfully get a TGT from any machine that
can see my KDC. I also can successfully search my ldap directory using
simple authentication. I've run the sasl-sample-client and server
between several machines including: ldap server to krb server, test
server to krb server, test server to ldap server, etc. I can complete
the sasl test on every one. Running slapd in debug mode doesn't provide
me with any additional information:
root@baneling:~# slapd -h "ldap:/// ldapi:///" -d 256
5371865b @(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $
root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd
5371865c slapd starting
53718672 conn=1000 fd=13 ACCEPT from IP=10.1.10.10:53839 (IP=0.0.0.0:389)
53718672 conn=1000 op=0 BIND dn="" method=163
53718672 SASL [conn=1000] Failure: GSSAPI Error: Unspecified GSS
failure. Minor code may provide more information ()
53718672 conn=1000 op=0 RESULT tag=97 err=80 text=SASL(-1): generic
failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide
more information ()
53718672 conn=1000 op=1 UNBIND
53718672 conn=1000 fd=13 closed
53718672 connection_read(13): no connection!
I do have the keytab in a non-standard location on the ldap server
(/etc/ldap/ldap.keytab), so I modified /etc/default/slapd and restarted
slapd. I'm not really sure what I can provide from my cn=config that
would help diagnose this issue let me know and I can respond with the
details.
Here is my ldap.conf from the server I'm running the ldapsearch from (my
test server):
root@mytest:~# cat /etc/ldap/ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE dc=harmonywave,dc=com
URI ldap://baneling.harmonywave.com
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
# TLS certificates (needed for GnuTLS)
TLS_CACERT /etc/ssl/certs/ca.harmonywave.com.pem
TLS_REQCERT demand
TLS_CHECKPEER yes
TLS_CIPHER_SUITE SECURE256
# LDAP sudo settings
sudoers_base ou=SUDOers,dc=harmonywave,dc=com
# SASL Kerberos settings
SASL_MECH GSSAPI
SASL_REALM HARMONYWAVE.COM
Thanks,
Josh
11:26 p.m.
Am Mon, 12 May 2014 20:52:14 -0600
schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>:
I'm looking for a little help concerning the below error I get
when I
do an ldapsearch:
root@mytest:~# ldapsearch -Y GSSAPI
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 ()
That error is pretty generic to me and the searching I've done to
find a solution has not yielded anything successful. I have MIT
Kerberos and SASL setup and I'm able to successfully get a TGT from
any machine that can see my KDC. I also can successfully search my
ldap directory using simple authentication. I've run the
sasl-sample-client and server between several machines including:
ldap server to krb server, test server to krb server, test server to
ldap server, etc. I can complete the sasl test on every one.
Running slapd in debug mode doesn't provide me with any additional
information:
root@baneling:~# slapd -h "ldap:/// ldapi:///" -d 256
5371865b @(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $
root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd
5371865c slapd starting
53718672 conn=1000 fd=13 ACCEPT from IP=10.1.10.10:53839
(IP=0.0.0.0:389) 53718672 conn=1000 op=0 BIND dn="" method=163
53718672 SASL [conn=1000] Failure: GSSAPI Error: Unspecified GSS
failure. Minor code may provide more information ()
53718672 conn=1000 op=0 RESULT tag=97 err=80 text=SASL(-1): generic
failure: GSSAPI Error: Unspecified GSS failure. Minor code may
provide more information ()
53718672 conn=1000 op=1 UNBIND
53718672 conn=1000 fd=13 closed
53718672 connection_read(13): no connection!
I do have the keytab in a non-standard location on the ldap server
(/etc/ldap/ldap.keytab), so I modified /etc/default/slapd and
restarted slapd. I'm not really sure what I can provide from my
cn=config that would help diagnose this issue let me know and I can
respond with the details.
Here is my ldap.conf from the server I'm running the ldapsearch from
(my test server):
root@mytest:~# cat /etc/ldap/ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE dc=harmonywave,dc=com
URI ldap://baneling.harmonywave.com
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
# TLS certificates (needed for GnuTLS)
TLS_CACERT /etc/ssl/certs/ca.harmonywave.com.pem
TLS_REQCERT demand
TLS_CHECKPEER yes
TLS_CIPHER_SUITE SECURE256
# LDAP sudo settings
sudoers_base ou=SUDOers,dc=harmonywave,dc=com
# SASL Kerberos settings
SASL_MECH GSSAPI
SASL_REALM HARMONYWAVE.COM
Does klist show a ldap service principal?
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
4:32 a.m.
On Tue, 2014-05-13 at 08:26 +0200, Dieter Klünter wrote:
Am Mon, 12 May 2014 20:52:14 -0600
schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>:
> I'm looking for a little help concerning the below error I get when I
> do an ldapsearch:
>
> root@mytest:~# ldapsearch -Y GSSAPI
> 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 ()
>
> That error is pretty generic to me and the searching I've done to
> find a solution has not yielded anything successful. I have MIT
> Kerberos and SASL setup and I'm able to successfully get a TGT from
> any machine that can see my KDC. I also can successfully search my
> ldap directory using simple authentication. I've run the
> sasl-sample-client and server between several machines including:
> ldap server to krb server, test server to krb server, test server to
> ldap server, etc. I can complete the sasl test on every one.
> Running slapd in debug mode doesn't provide me with any additional
> information:
>
> root@baneling:~# slapd -h "ldap:/// ldapi:///" -d 256
> 5371865b @(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $
> root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd
> 5371865c slapd starting
> 53718672 conn=1000 fd=13 ACCEPT from IP=10.1.10.10:53839
> (IP=0.0.0.0:389) 53718672 conn=1000 op=0 BIND dn="" method=163
> 53718672 SASL [conn=1000] Failure: GSSAPI Error: Unspecified GSS
> failure. Minor code may provide more information ()
> 53718672 conn=1000 op=0 RESULT tag=97 err=80 text=SASL(-1): generic
> failure: GSSAPI Error: Unspecified GSS failure. Minor code may
> provide more information ()
> 53718672 conn=1000 op=1 UNBIND
> 53718672 conn=1000 fd=13 closed
> 53718672 connection_read(13): no connection!
>
> I do have the keytab in a non-standard location on the ldap server
> (/etc/ldap/ldap.keytab), so I modified /etc/default/slapd and
> restarted slapd. I'm not really sure what I can provide from my
> cn=config that would help diagnose this issue let me know and I can
> respond with the details.
>
> Here is my ldap.conf from the server I'm running the ldapsearch from
> (my test server):
>
> root@mytest:~# cat /etc/ldap/ldap.conf
> #
> # LDAP Defaults
> #
>
> # See ldap.conf(5) for details
> # This file should be world readable but not world writable.
>
> BASE dc=harmonywave,dc=com
> URI ldap://baneling.harmonywave.com
>
> #SIZELIMIT 12
> #TIMELIMIT 15
> #DEREF never
>
> # TLS certificates (needed for GnuTLS)
> TLS_CACERT /etc/ssl/certs/ca.harmonywave.com.pem
> TLS_REQCERT demand
> TLS_CHECKPEER yes
> TLS_CIPHER_SUITE SECURE256
>
> # LDAP sudo settings
> sudoers_base ou=SUDOers,dc=harmonywave,dc=com
>
> # SASL Kerberos settings
> SASL_MECH GSSAPI
> SASL_REALM HARMONYWAVE.COM
Does klist show a ldap service principal?
-Dieter
a couple of things that may need attention. you need to map the
kerberos-established identities to ldap user objects. adjust the below
to match your environment (these need to be in cn=config):
olcSaslRealm: BPK2.COM
olcAuthzRegexp: {0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid=
$1,ou=Users,dc=bpk2,dc=com
olcAuthzRegexp: {1}uid=([^,]*),cn=gssapi,cn=auth uid=
$1,ou=Users,dc=bpk2,dc=com
you might also need to tell sasl to use the kerberos auth mechanism, and
where to find the ldap servers. again, adjust to your environment
(saslauthd.conf):
ldap_servers: ldap://ldap1.bpk2.com/ ldap://ldap2.bpk2.com
ldap_use_sasl: yes
ldap_mech: kerberos5
ldap_auth_method: fastbind
keytab: /etc/ldap.keytab
from what it seems, there is no BIND DN being presented as authenticated
when you attempt your search. note the BIND dn ="" in your error
message.
6:12 a.m.
On 05/13/14 07:32 -0400, Brendan Kearney wrote:
On Tue, 2014-05-13 at 08:26 +0200, Dieter Klünter wrote:
> Am Mon, 12 May 2014 20:52:14 -0600
> schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>:
>
> > root@mytest:~# ldapsearch -Y GSSAPI
> > 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 ()
Check your syslog - auth facility, and check your kdc logs.
a couple of things that may need attention. you need to map the
kerberos-established identities to ldap user objects. adjust the below
to match your environment (these need to be in cn=config):
olcSaslRealm: BPK2.COM
This may be necessary.
olcAuthzRegexp: {0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid=
$1,ou=Users,dc=bpk2,dc=com
olcAuthzRegexp: {1}uid=([^,]*),cn=gssapi,cn=auth uid=
$1,ou=Users,dc=bpk2,dc=com
This is not necessary, for GSSAPI authentication. That is, the error
message above is a SASL error message. olcAuthzRegexp would be needed to
map the user after authentication has been completed.
you might also need to tell sasl to use the kerberos auth mechanism,
and
where to find the ldap servers. again, adjust to your environment
(saslauthd.conf):
ldap_servers: ldap://ldap1.bpk2.com/ ldap://ldap2.bpk2.com
ldap_use_sasl: yes
ldap_mech: kerberos5
ldap_auth_method: fastbind
keytab: /etc/ldap.keytab
This is also not necessary, as GSSAPI authentication does not depend on or
use saslauthd. It would be needed if performing pass-through or PLAIN/LOGIN
authentication.
--
Dan White
6:39 a.m.
On Tue, 2014-05-13 at 08:12 -0500, Dan White wrote:
On 05/13/14 07:32 -0400, Brendan Kearney wrote:
>On Tue, 2014-05-13 at 08:26 +0200, Dieter Klünter wrote:
>> Am Mon, 12 May 2014 20:52:14 -0600
>> schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>:
>>
>> > root@mytest:~# ldapsearch -Y GSSAPI
>> > 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 ()
Check your syslog - auth facility, and check your kdc logs.
>a couple of things that may need attention. you need to map the
>kerberos-established identities to ldap user objects. adjust the below
>to match your environment (these need to be in cn=config):
>
>olcSaslRealm: BPK2.COM
This may be necessary.
>olcAuthzRegexp: {0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid=
>$1,ou=Users,dc=bpk2,dc=com
>olcAuthzRegexp: {1}uid=([^,]*),cn=gssapi,cn=auth uid=
>$1,ou=Users,dc=bpk2,dc=com
This is not necessary, for GSSAPI authentication. That is, the error
message above is a SASL error message. olcAuthzRegexp would be needed to
map the user after authentication has been completed.
good point, why map an identity if it has not been authenticated yet.
>you might also need to tell sasl to use the kerberos auth
mechanism, and
>where to find the ldap servers. again, adjust to your environment
>(saslauthd.conf):
>
>ldap_servers: ldap://ldap1.bpk2.com/ ldap://ldap2.bpk2.com
>ldap_use_sasl: yes
>ldap_mech: kerberos5
>ldap_auth_method: fastbind
>keytab: /etc/ldap.keytab
This is also not necessary, as GSSAPI authentication does not depend on or
use saslauthd. It would be needed if performing pass-through or PLAIN/LOGIN
authentication.
interesting. when i found the articles that i worked off of for my
environment, those distinctions were not made. only recently did i
discover that the pass-through auth works. i have set olcSaslSecProps
to noanonymous,noplain so it seems to only works in limited cases.
6:52 a.m.
I do have olcSaslRealm and olcAuthzregexp setup in my cn=config. I do
not have saslauthd.conf setup. I ran kinit from my ldap server then
tried to do an ldapsearch and it looks like syslog is providing the same
information.
root@baneling:~# kdestroy
root@baneling:~# kinit -p jschaeffer
Password for jschaeffer(a)HARMONYWAVE.COM:
root@baneling:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: jschaeffer(a)HARMONYWAVE.COM
Valid starting Expires Service principal
13/05/2014 07:44 13/05/2014 17:44 krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM
renew until 14/05/2014 07:43
root@baneling:~# ldapsearch -Y GSSAPI
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 ()
root@baneling:~# cat /var/log/syslog | tail -n 2
May 13 07:44:37 baneling kernel: 7[275.456 palsdne(NU) Neh
U=MCf:ff:ff:f0:eb:c2:40:0SC0000DT25252525LN38TS01 RC00 T=2 D0POOUPST6
P=7LN38
May 13 07:44:48 baneling slapd[20118]: SASL [conn=1012] Failure: GSSAPI
Error: Unspecified GSS failure. Minor code may provide more information ()
In my kdc log I don't see anything related to the ldapsearch I'm trying
to perform. It did mention that it there was no host service ticket for
my test server so I added one, but the test I just ran was directly on
my ldap server. I do see this, I'm not sure if it is related to this
problem:
May 13 07:43:58 immortal.harmonywave.com krb5kdc[15804](info): AS_REQ (4
etypes {18 17 16 23}) 10.1.10.9: NEEDED_PREAUTH:
jschaeffer(a)HARMONYWAVE.COM for krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM,
Additional pre-authentication required.
Thanks,
Josh
On 05/13/2014 07:12 AM, Dan White wrote:
On 05/13/14 07:32 -0400, Brendan Kearney wrote:
> On Tue, 2014-05-13 at 08:26 +0200, Dieter Klünter wrote:
>> Am Mon, 12 May 2014 20:52:14 -0600
>> schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>:
>>
>> > root@mytest:~# ldapsearch -Y GSSAPI
>> > 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 ()
Check your syslog - auth facility, and check your kdc logs.
> a couple of things that may need attention. you need to map the
> kerberos-established identities to ldap user objects. adjust the below
> to match your environment (these need to be in cn=config):
>
> olcSaslRealm: BPK2.COM
This may be necessary.
> olcAuthzRegexp: {0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid=
> $1,ou=Users,dc=bpk2,dc=com
> olcAuthzRegexp: {1}uid=([^,]*),cn=gssapi,cn=auth uid=
> $1,ou=Users,dc=bpk2,dc=com
This is not necessary, for GSSAPI authentication. That is, the error
message above is a SASL error message. olcAuthzRegexp would be needed to
map the user after authentication has been completed.
> you might also need to tell sasl to use the kerberos auth mechanism, and
> where to find the ldap servers. again, adjust to your environment
> (saslauthd.conf):
>
> ldap_servers: ldap://ldap1.bpk2.com/ ldap://ldap2.bpk2.com
> ldap_use_sasl: yes
> ldap_mech: kerberos5
> ldap_auth_method: fastbind
> keytab: /etc/ldap.keytab
This is also not necessary, as GSSAPI authentication does not depend
on or
use saslauthd. It would be needed if performing pass-through or
PLAIN/LOGIN
authentication.
6:08 a.m.
Yes, it does on the server I'm testing from:
root@mytest:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: jschaeffer(a)HARMONYWAVE.COM
Valid starting Expires Service principal
12/05/2014 20:32 13/05/2014 06:32 krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM
renew until 13/05/2014 20:32
12/05/2014 20:32 13/05/2014 06:32
ldap/baneling.harmonywave.com(a)HARMONYWAVE.COM
renew until 13/05/2014 20:32
On 05/13/2014 12:26 AM, Dieter Klünter wrote:
Am Mon, 12 May 2014 20:52:14 -0600
schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>:
> I'm looking for a little help concerning the below error I get when I
> do an ldapsearch:
>
> root@mytest:~# ldapsearch -Y GSSAPI
> 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 ()
>
> That error is pretty generic to me and the searching I've done to
> find a solution has not yielded anything successful. I have MIT
> Kerberos and SASL setup and I'm able to successfully get a TGT from
> any machine that can see my KDC. I also can successfully search my
> ldap directory using simple authentication. I've run the
> sasl-sample-client and server between several machines including:
> ldap server to krb server, test server to krb server, test server to
> ldap server, etc. I can complete the sasl test on every one.
> Running slapd in debug mode doesn't provide me with any additional
> information:
>
> root@baneling:~# slapd -h "ldap:/// ldapi:///" -d 256
> 5371865b @(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $
> root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd
> 5371865c slapd starting
> 53718672 conn=1000 fd=13 ACCEPT from IP=10.1.10.10:53839
> (IP=0.0.0.0:389) 53718672 conn=1000 op=0 BIND dn="" method=163
> 53718672 SASL [conn=1000] Failure: GSSAPI Error: Unspecified GSS
> failure. Minor code may provide more information ()
> 53718672 conn=1000 op=0 RESULT tag=97 err=80 text=SASL(-1): generic
> failure: GSSAPI Error: Unspecified GSS failure. Minor code may
> provide more information ()
> 53718672 conn=1000 op=1 UNBIND
> 53718672 conn=1000 fd=13 closed
> 53718672 connection_read(13): no connection!
>
> I do have the keytab in a non-standard location on the ldap server
> (/etc/ldap/ldap.keytab), so I modified /etc/default/slapd and
> restarted slapd. I'm not really sure what I can provide from my
> cn=config that would help diagnose this issue let me know and I can
> respond with the details.
>
> Here is my ldap.conf from the server I'm running the ldapsearch from
> (my test server):
>
> root@mytest:~# cat /etc/ldap/ldap.conf
> #
> # LDAP Defaults
> #
>
> # See ldap.conf(5) for details
> # This file should be world readable but not world writable.
>
> BASE dc=harmonywave,dc=com
> URI ldap://baneling.harmonywave.com
>
> #SIZELIMIT 12
> #TIMELIMIT 15
> #DEREF never
>
> # TLS certificates (needed for GnuTLS)
> TLS_CACERT /etc/ssl/certs/ca.harmonywave.com.pem
> TLS_REQCERT demand
> TLS_CHECKPEER yes
> TLS_CIPHER_SUITE SECURE256
>
> # LDAP sudo settings
> sudoers_base ou=SUDOers,dc=harmonywave,dc=com
>
> # SASL Kerberos settings
> SASL_MECH GSSAPI
> SASL_REALM HARMONYWAVE.COM
Does klist show a ldap service principal?
-Dieter
3497
days inactive
3497
days old
openldap-technical@openldap.org
6 comments
4 participants
participants (4)
-
Brendan Kearney -
Dan White -
Dieter Klünter -
Joshua Schaeffer