LDAP ( ERROR ) : ldap_simple_bind: Invalid credentials

Roman 2017-08-09 15:22:26 UTC #1

Hi. I have member server with constant error logs. Specifically, bind9 complains about invalid credentials. Please help me to resolve.

LDAP ( ERROR ) : ldap_simple_bind: Invalid credentials

09.08.17 16:17:57.603  DEBUG_INIT
0: dc02.company.com
1: dc.company.com
UNIVENTION_DEBUG_BEGIN  : uldap.__open host=dc.com port=7389 base=dc=company,dc=com
UNIVENTION_DEBUG_END    : uldap.__open host=dc.com port=7389 base=dc=company,dc=com
09.08.17 16:17:58.273  LISTENER    ( PROCESS ) : updating 'zoneName=company.com,cn=dns,dc=company,dc=com' command m
09.08.17 16:17:58.293  LDAP        ( ERROR   ) : ldap_simple_bind: Invalid credentials
09.08.17 16:17:58.294  LISTENER    ( ERROR   ) : check_parent_dn: bind to local LDAP failed
09.08.17 16:17:58.303  LISTENER    ( ERROR   ) : 'failed.ldif' exists. Check for /var/lib/univention-directory-replication/failed.ldif

Moritz_Bunkus 2017-08-14 07:54:11 UTC #2

The log file you're showing us is not from bind9 but from the Univention Directory Listener process. This makes more sense, too, as it's unusual to run bind9 on a member server, but a Directory Listener is always running on each and every server.

The Directory Listener process uses the server's LDAP machine account for authentication. Fortunately it's easy to check whether or that account still works. Just run the command univention-ldapsearch on your member server. It should output a lot of data.

If that works, try restarting the Directory Listener process with systemctl restart univention-directory-listener.service and see if that makes a difference.

Roman 2017-08-14 08:12:29 UTC #3

Thanks, I have restarted and it did not make a difference.

I do not know why DNS was enabled for this member server, I removed that service from univention management centre however it is still present on that server. Is there any command I can use to forcefully disable DNS on member server?

Moritz_Bunkus 2017-08-14 08:22:58 UTC #4

I don't believe you actually do have DNS on your member server. Your interpretation of the log file seems wrong. Check if dpkg -l univention-bind bind9 shows both packages as not being installed (the lines should start with un).

Try rejoining the server to the domain with univention-join. You won't lose data that way, but the server will copy important data such as the machine account's credentials, and this often solves issues such as this.

Roman 2017-08-14 11:04:29 UTC #5

What would the below mean?

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)

ii  bind9          1:9.8.4.dfsg amd64        Internet Domain Name Server
ii  univention-bin 10.0.2-5.218 all          UCS - DNS server

Roman 2017-08-14 11:07:58 UTC #6

Join failed!
* Contact your system administrator
* Message:  binddn for user root not found.

And join failed because of binddn

Search DC Master:                                          done
Check DC Master:                                           done
Stop LDAP Server:                                          done
Search ldap/base                                           done
Start LDAP Server:                                         done
Search LDAP binddn Insufficient access (50)

Moritz_Bunkus 2017-08-14 11:19:03 UTC #7

Bind is indeed installed on your machine. Interesting. It's quite possible that having bind running on a member server isn't supported, and that the member server's machine account simply doesn't have write access to the LDAP's DNS objects.

Is this really a member server? Please post the output of ucr get server/role before we remove potentially important packages.

Joining is done with a user account from the LDAP who has domain admin privileges. The user root is not an LDAP user, though — you usually have to use administrator for joining.

Roman 2017-08-14 11:36:49 UTC #8

Hey, so this is the reply I got from your server role command

domaincontroller_slave

this server runs few applications which are optional, so should not be a domain controller server.

Attempt to join domain not with root but now with Administrator

Enter DC Master Account : administrator
Enter DC Master Password: 

Search DC Master:                                          done
Check DC Master:                                           done
Stop LDAP Server:                                          done
Search ldap/base                                           done
Start LDAP Server:                                         done
Search LDAP binddn                                         done
Sync time:                                                 done
Join Computer Account: 

**************************************************************************
* Join failed!                                                           *
* Contact your system administrator                                      *
**************************************************************************
* Message:  No LDAP Host DN returned
**************************************************************************

Moritz_Bunkus 2017-08-14 11:59:37 UTC #9

So it isn't a member server after all. The term "member server" has a very distinct meaning in the UCS context — it's one of the four possible roles a server can have (domaincontroller_master, domaincontroller_backup, domaincontroller_slave or memberserver). The big difference between a DC Slave and a Member server is that a DC Slave runs its own LDAP server with a partial or full copy of the DC Master's LDAP server while a Member server doesn't run its own LDAP server. A DC Slave is usually used for remote locations/branch offices where you want to have access to your authentication services without having to go over the wire.

A DC Slave also runs its own bind name server. Therefore removing it is not a good idea.

About the failing join: please post the content of the following log file: /var/log/univention/join.log. Thanks.

Roman 2017-08-14 13:08:02 UTC #10

Please see the log

Mon Aug 14 12:05:59 BST 2017: starting /usr/sbin/univention-join 
running version check
OK: UCS version on sub.domain.com is higher or equal (4.14) to the local version (4.14).
Stopping ldap server(s): slapd ...retry #1....done.
Starting ldap server(s): slapd ...done.
Found failed.ldif. Importing ...failed.
Please check /var/log/univention/listener.log.
Mon Aug 14 12:07:25 BST 2017: finish /usr/sbin/univention-join
Mon Aug 14 12:31:00 BST 2017: starting /usr/sbin/univention-join 
running version check
OK: UCS version on sub.domain.com is higher or equal (4.14) to the local version (4.14).
Stopping ldap server(s): slapd ...done.
Starting ldap server(s): slapd ...done.
Found failed.ldif. Importing ...failed.
Please check /var/log/univention/listener.log.
Mon Aug 14 12:31:13 BST 2017
univention-server-join: joins a server to an univention domain
copyright (c) 2001-2017 Univention GmbH, Germany

E: failed to create DC Slave (1) [E: Object exists: (mac)  52:54:00:87:01:3f]
Mon Aug 14 12:31:15 BST 2017: finish /usr/sbin/univention-join

By the way, DC slave was created probably for reason to use LDAP authentication for web apps we run on this server.

Moritz_Bunkus 2017-08-14 13:40:43 UTC #11

Alright. You should now remove the computer object for that DC Slave in the Univention Management Console. Afterwards make sure that the MAC address isn't used anywhere else in the LDAP directory by running this on your DC Master:

univention-ldapsearch '(macaddress=52:54:00:87:01:3f)' dn

It should report # numEntries: 0. If it does, try the join again.