Shulou(Shulou.com)06/02 Report--

In the previous article, krb5 + ldap + bind9 + bind9-dyndb-ldap was fully upgraded to debian 10, and the GSSAPI+krb5_keytab authentication mechanism of bind9-dyndb-ldap could not connect to the ldap database.

View the log:

SASL/GSSAPI authentication started

Error: Local error

Additional info: SASL (- 1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (Did not find a plugin for ccache_ops)

Internet search about GSSAPI+ccache_ops failed, had to do-it-yourself debugging.

Idea: starting from bind9-dyndb-ldap software package and its dependent packages, manually downgrading them one by one, or starting from normal debian 9, modify the software source to debian 10 and upgrade one by one. That is, downgrade / upgrade one, test once.

Description: debian system can not be automatically downgraded, you can modify the software source to a low version or manually download a low version of the deb package to reinstall the package

In fact, the whole debugging process is still blind. Krb5, ldap, sasl are all complex things, the problem may be in the server, may also be in the client, may also be missing in the configuration.

My ability is limited, but also hope to locate the problem from the source code, according to the log keyword 'plugin for ccache_ops' search above three source code, but also found only a few words, do not know why.

Thanks to his efforts, he downgraded each dependent package one by one, and fortunately decided to use the libsasl2-modules-gssapi-heimdal package, that is to say, all other related packages use the latest version of debian 10, and the configuration file does not need to be changed.

As long as the libsasl2-modules-gssapi-heimdal package is downgraded, bind9-dyndb-ldap connects to the ldap database normally.

Debian version 10 is 2.1.27+dfsg-1

Debian 9 version is 2.1.27~101-g0780600+dfsg-3

In fact, a file / usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25 can be replaced directly with debian 9 version unpacking.

Sasl/gssapi is also a common application, but the problem is that the 2.1.27+dfsg-1 version of libsasl2-modules-gssapi-heimdal has not been updated until debian 11, and other sasl/gssapi applications using 2.1.27+dfsg-1 are normal.

For example, the openldap client tool works well in 2.1.27+dfsg-1, as shown in the following command

Ldapwhoami-Y GSSAPI-h 192.168.1.11

Therefore, it is not clear whether the error in the 2.1.27+dfsg-1 version is BUG or whether this upgraded version requires further configuration of sasl/gssapi customers / services.

Or, for example, my demand for bind9-dyndb-ldap+SASL/GSSAPI is relatively rare, so I can hardly find related problems on the Internet, and I can't be sure if it is a bind9-dyndb-ldap problem.

The problem is calm, so it may be hidden. To debug bind9-dyndb-ldap is very troublesome, change the way of thinking, write the simplest ldap/sasl/gssapi/krb5 client program test, sure enough, found that the use of memory tickets will appear this problem.

The krb5 client can specify the location of the ticket, as follows

"MEMORY:krb5cc_1000" is stored in process memory

"FILE:/tmp/krb5cc_1000" is stored in a temporary directory

Krb5 tickets are usually placed in a temporary directory, such as the ticket file of / tmp/krb5cc_1000, and the openldap client tool is to read the tickets in the temporary directory.

After testing, the libsasl2-modules-gssapi-heimdal 2.1.27+dfsg-1 version of the memory bill has BUG, the document bill is normal.

In the previous article, the SSSD client installation mentioned that libsasl2-modules-gssapi-mit and libsasl2-modules-gssapi-heimdal are interchangeable.

So installing libsasl2-modules-gssapi-mit for debian 10 is perfectly normal for memory bills. The MIT version is more mainstream, perhaps because there is a mit version instead of the heimdal version, so the heimdal version is calm.

Summary:

For sasl/gssapi applications, install libsasl2-modules-gssapi-mit

Postscript:

1. For krb5 clients, try to use the mit version. Kerberos is invented by mit and is more active.

two。 Why should I use heimdal version of my Kerberos server?

Because my goal Kerberos+LDAP is one, two sets of passwords are synchronized.

Mit heimdal-krb5 service The ldap connection via EXTERNAL does not support synchronization of passwords through slapd-smbk5pwd.

New changes in bind9-dyndb-ldap configuration format for 3.debian 10

Please refer to the previous section for customer / service configuration, and then click the following:

But please press Kerberos to use your own local database to understand the following configuration, because using ldap as the Kerberos back-end database later understood that the krb5 principal and ldap entries are very confusing

1) bind9-dyndb-ldap configuration

/ etc/bind/named.conf.ldap

/ / other strategies

...

/ / different system paths, such as / usr/lib/i386-linux-gnu/bind/ldap.so

Dyndb "my_db_name"/ usr/lib/bind/ldap.so" {

Server_id ""

Directory "/ var/cache/bind"

Uri "ldap://127.0.0.1"

Base "ou=dns,dc=ctp,dc=net"

/ / Authentication mechanism

Auth_method "sasl"

Sasl_mech "GSSAPI"

/ /-- vMurt-add krb5 body

Krb5_principal "dnsadmin@CTP.NET"

Krb5_keytab "FILE:/etc/bind/krb5.keytab"

/ /-- ^

Timeout 50

Reconnect_interval 100

}

2) ldap configuration

/ etc/ldap/slapd.d/cn=config/olcDatabase= {1} mdb.ldif

# other strategies

...

OlcAccess: {3} to dn.subtree= "ou=dns,dc=ctp,dc=net" by dn= "uid=dnsadmin,cn=gssapi,cn=auth" write by * read

...

Description:

Configure krb5 principal dnsadmin write ldap database permissions. If you only need read permissions, you should not need to configure

"cn=gssapi,cn=auth" is in a fixed format and is used to indicate that it is a krb5 entry (here the krb5 entry does not refer to the entry that is stored in the ldap database using ldap as the Kerberos backend. You can understand it by using Kerberos to use your own database). The ldap database does not need to create and store "uid=dnsadmin,cn=gssapi,cn=auth" krb5 entries.

Other names "dnsadmin", "dns", "ctp" and "net" are filled in according to your actual name.

3) run the following command

Kadmin-l add-r-- use-defaults dnsadmin

Kadmin-l ext-k / etc/bind/krb5.keytab dnsadmin

Using ldap as the Kerberos backend, the add command automatically adds the entry "krb5PrincipalName=dnsadmin@CTP.NET,ou=hdkrb5,dc=ctp,dc=net" of the krb5 principal dnsadmin to the ldap database

Chown bind:bind / etc/bind/krb5.keytab

Chmod Omurr / etc/bind/krb5.keytab

Chmod Gmurr / etc/bind/krb5.keytab

4. Other considerations

My krb5 + ldap + bind9 + bind9-dyndb-ldap kdc server (192.168.1.11)

1)

When / etc/resolv.conf is empty

Or set nameserver 127.0.0.1

Or set nameserver 192.168.1.11

Or set the address where nameserver 192.168.1.xx does not exist with the kdc server network segment.

Bind9 failed to start, prompting timeout

If you use the above resolv.conf configuration, change the sasl/gssapi authentication mechanism of / etc/bind/named.conf.ldap to anonymous

Auth_method "none"

Bind9 startup can be successful, although anonymous can not write ldap, but dig read successfully; this may be due to the sasl/gssapi mechanism.

2)

Must add an address to / etc/resolv.conf that does not exist in a different network segment from the kdc server

Such as nameserver 127.0.0.2

Or nameserver 192.168.2.22

Sasl/gssapi authentication mechanism, bind9 startup is successful, the reason is unknown.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.