LDAP error on UCS system

Hi All,

I have 2 UCS servers in the system. There is no more Windows DC. After the successful AD takeover process, there are some errors to login the domain from the Windows clients. I had some checks and found that there was some errors with LDAP as below:

UCS-Master:

root@abc-ucs:~# net ads info LDAP server: 192.168.1.15 LDAP server name: abc-ucs.abc.com Realm: abc.COM Bind Path: dc=abc,dc=COM LDAP port: 389 Server time: Tue, 29 Sep 2015 18:14:21 ICT KDC server: 192.168.1.15 Server time offset: 0

UCS-Slave:

root@abc-ucs-2:~# net ads info ads_connect: No logon servers ads_connect: No logon servers Didn't find the ldap server!

The config of krb5.conf:
UCS-Master:

[code]# Warning: This file is auto-generated and might be overwritten by

univention-config-registry.

Please edit the following file instead:

Warnung: Diese Datei wurde automatisch generiert und kann durch

univention-config-registry überschrieben werden.

Bitte bearbeiten Sie an Stelle dessen die folgende Datei:

/etc/univention/templates/files/etc/krb5.conf

[libdefaults]
default_realm = abc.COM
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md4 des-cbc-md5 des3-cbc-sha1 arcfour-hmac-md5 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
default_tkt_enctypes = arcfour-hmac-md5 des-cbc-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md4 des3-cbc-sha1 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
permitted_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md4 des-cbc-md5 des3-cbc-sha1 arcfour-hmac-md5 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
krb4_get_tickets=no
allow_weak_crypto=true
dns_lookup_kdc = true
dns_lookup_realm = false
forwardable = true
proxiable = true
kdc_timesync = 1
debug = false

[realms]
abc.COM = {
acl_file = /var/lib/heimdal-kdc/kadmind.acl
kdc = 127.0.0.1
admin_server = abc-ucs.abc.com
kpasswd_server = 127.0.0.1
}

abc = {
kdc = 127.0.0.1
admin_server = abc-ucs.abc.com
default_domain = abc.com
}

[kdc]
hdb-ldap-create-base = cn=kerberos,dc=abc,dc=com
v4-realm = abc.COM

[kadmin]
v4-realm = abc.COM

database = {
label = {
acl_file = /var/lib/heimdal-kdc/kadmind.acl
dbname = ldap:dc=abc,dc=com
realm = abc.COM

	log_file = /var/log/heimdal-database.log
	mkey_file = /var/heimdal/m-key
}

}
[/code]

UCS-Slave:

[code]# Warning: This file is auto-generated and might be overwritten by

univention-config-registry.

Please edit the following file instead:

Warnung: Diese Datei wurde automatisch generiert und kann durch

univention-config-registry überschrieben werden.

Bitte bearbeiten Sie an Stelle dessen die folgende Datei:

/etc/univention/templates/files/etc/krb5.conf

[libdefaults]
default_realm = abc.COM
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md4 des-cbc-md5 des3-cbc-sha1 arcfour-hmac-md5 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
default_tkt_enctypes = arcfour-hmac-md5 des-cbc-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md4 des3-cbc-sha1 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
permitted_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md4 des-cbc-md5 des3-cbc-sha1 arcfour-hmac-md5 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
krb4_get_tickets=no
allow_weak_crypto=true
dns_lookup_kdc = true
dns_lookup_realm = false
forwardable = true
proxiable = true
kdc_timesync = 1
debug = false

[realms]
abc.COM = {
acl_file = /var/lib/heimdal-kdc/kadmind.acl
kdc = 127.0.0.1
admin_server = abc-ucs.abc.com
kpasswd_server = 127.0.0.1
}

abc = {
kdc = 127.0.0.1
admin_server = abc-ucs.abc.com
default_domain = abc.com
}

[kdc]
hdb-ldap-create-base = cn=kerberos,dc=abc,dc=com
v4-realm = abc.COM

[kadmin]
v4-realm = abc.COM

database = {
label = {
acl_file = /var/lib/heimdal-kdc/kadmind.acl
dbname = ldap:dc=abc,dc=com
realm = abc.COM

	log_file = /var/log/heimdal-database.log
	mkey_file = /var/heimdal/m-key
}

}
[/code]

The result of command “net ads status” on both UCS server is as below:

root@fmp-ucs:~# net ads status Enter root's password: kerberos_kinit_password ABC@ABC.COM failed: Client not found in Kerberos database kerberos_kinit_password ABC@ABC.COM failed: Client not found in Kerberos database kerberos_kinit_password ABC@ABC.COM failed: Client not found in Kerberos database

Can anyone help me to solve this? Thanks in advance.

Can anyone help me? :frowning:

Below is the result of “samba-tool drs showrepl” command:

[code]root@abc-ucs:~# samba-tool drs showrepl
WARNING: No path in service IPC$ - making it unavailable!
NOTE: Service IPC$ is flagged unavailable.
abc\abc-UCS
DSA Options: 0x00000001
DSA object GUID: 17606d4f-27e4-43de-90b5-424cb4b4399f
DSA invocationId: 6dca6597-f056-450e-b8a3-2238ffd0ef41

==== INBOUND NEIGHBORS ====

CN=Configuration,DC=abc,DC=com
abc\abc-UCS-2 via RPC
DSA object GUID: f566e9ac-0c27-4b08-9c63-86a85ddec414
Last attempt @ Wed Sep 30 16:31:16 2015 ICT failed, result 2 (WERR_BADFILE)
1032 consecutive failure(s).
Last success @ NTTIME(0)

DC=ForestDnsZones,DC=abc,DC=com
abc\abc-UCS-2 via RPC
DSA object GUID: f566e9ac-0c27-4b08-9c63-86a85ddec414
Last attempt @ Wed Sep 30 16:31:15 2015 ICT failed, result 2 (WERR_BADFILE)
1032 consecutive failure(s).
Last success @ NTTIME(0)

DC=abc,DC=com
abc\abc-UCS-2 via RPC
DSA object GUID: f566e9ac-0c27-4b08-9c63-86a85ddec414
Last attempt @ Wed Sep 30 16:31:16 2015 ICT failed, result 2 (WERR_BADFILE)
1032 consecutive failure(s).
Last success @ NTTIME(0)

CN=Schema,CN=Configuration,DC=abc,DC=com
abc\abc-UCS-2 via RPC
DSA object GUID: f566e9ac-0c27-4b08-9c63-86a85ddec414
Last attempt @ Wed Sep 30 16:31:16 2015 ICT failed, result 2 (WERR_BADFILE)
1031 consecutive failure(s).
Last success @ NTTIME(0)

DC=DomainDnsZones,DC=abc,DC=com
abc\abc-UCS-2 via RPC
DSA object GUID: f566e9ac-0c27-4b08-9c63-86a85ddec414
Last attempt @ Wed Sep 30 16:31:16 2015 ICT failed, result 2 (WERR_BADFILE)
1032 consecutive failure(s).
Last success @ NTTIME(0)

==== OUTBOUND NEIGHBORS ====

CN=Configuration,DC=abc,DC=com
abc\abc-UCS-2 via RPC
DSA object GUID: f566e9ac-0c27-4b08-9c63-86a85ddec414
Last attempt @ Wed Sep 30 16:31:35 2015 ICT failed, result 2 (WERR_BADFILE)
32659 consecutive failure(s).
Last success @ NTTIME(0)

DC=ForestDnsZones,DC=abc,DC=com
abc\abc-UCS-2 via RPC
DSA object GUID: f566e9ac-0c27-4b08-9c63-86a85ddec414
Last attempt @ Wed Sep 30 16:31:35 2015 ICT failed, result 2 (WERR_BADFILE)
34279 consecutive failure(s).
Last success @ NTTIME(0)

DC=abc,DC=com
abc\abc-UCS-2 via RPC
DSA object GUID: f566e9ac-0c27-4b08-9c63-86a85ddec414
Last attempt @ Wed Sep 30 16:31:35 2015 ICT failed, result 2 (WERR_BADFILE)
32124 consecutive failure(s).
Last success @ NTTIME(0)

CN=Schema,CN=Configuration,DC=abc,DC=com
abc\abc-UCS-2 via RPC
DSA object GUID: f566e9ac-0c27-4b08-9c63-86a85ddec414
Last attempt @ Wed Sep 30 16:31:36 2015 ICT failed, result 2 (WERR_BADFILE)
31547 consecutive failure(s).
Last success @ NTTIME(0)

DC=DomainDnsZones,DC=abc,DC=com
abc\abc-UCS-2 via RPC
DSA object GUID: f566e9ac-0c27-4b08-9c63-86a85ddec414
Last attempt @ Wed Sep 30 16:31:35 2015 ICT failed, result 2 (WERR_BADFILE)
33479 consecutive failure(s).
Last success @ NTTIME(0)

==== KCC CONNECTION OBJECTS ====

Connection –
Connection name: 242a348e-8219-4bd7-8331-70a6f19effce
Enabled : TRUE
Server DNS name : abc-ucs-2.abc.com
Server DN name : CN=NTDS Settings,CN=abc-UCS-2,CN=Servers,CN=abc,CN=Sites,CN=Configuration,DC=abc,DC=com
TransportType: RPC
options: 0x00000001
Warning: No NC replicated for Connection!
root@abc-ucs:~#
[/code]

Well here are a few things from my UCS/AD/Samba4 experience…

root@abc-ucs-2:~# net ads info
ads_connect: No logon servers
ads_connect: No logon servers
Didn’t find the ldap server!

This means that the Samba4 is not installed on your Slave. <-- This is the first problem. It needs to be on ALL DCs as far as I know. We had this type of problem until we put it on all UCS DC (Master DC, Any backup DC and All slave DCs.)

root@fmp-ucs:~# net ads status
Enter root’s password:
kerberos_kinit_password ABC@ABC.COM failed: Client not found in Kerberos database
kerberos_kinit_password ABC@ABC.COM failed: Client not found in Kerberos database
kerberos_kinit_password ABC@ABC.COM failed: Client not found in Kerberos database

Again your missing an install of Samba4 somewhere. We had these type of errors until we installed UCS AD or AD connector if using Windows ADs and UCS ADs on the same domains on EVERY one of our UCS Servers that have a Domain Controller role. Either Master/Backup or Slave.

[quote=“BrianBonnell”]Well here are a few things from my UCS/AD/Samba4 experience…

root@abc-ucs-2:~# net ads info
ads_connect: No logon servers
ads_connect: No logon servers
Didn’t find the ldap server!

This means that the Samba4 is not installed on your Slave. <-- This is the first problem. It needs to be on ALL DCs as far as I know. We had this type of problem until we put it on all UCS DC (Master DC, Any backup DC and All slave DCs.)

root@fmp-ucs:~# net ads status
Enter root’s password:
kerberos_kinit_password ABC@ABC.COM failed: Client not found in Kerberos database
kerberos_kinit_password ABC@ABC.COM failed: Client not found in Kerberos database
kerberos_kinit_password ABC@ABC.COM failed: Client not found in Kerberos database

Again your missing an install of Samba4 somewhere. We had these type of errors until we installed UCS AD or AD connector if using Windows ADs and UCS ADs on the same domains on EVERY one of our UCS Servers that have a Domain Controller role. Either Master/Backup or Slave.[/quote]
Thank you for your reply but Samba4 was installed and running. I’ve check via command, the version is 4.2.3 on both UCS server. Today when I check again on both UCS servers, all of them got errors together. So I add more parameter for details as below:

root@abc-ucs:~# net ads info -d 3 lp_load_ex: refreshing parameters Initialising global parameters rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) Processing section "[global]" added interface eth0:1 ip=192.168.1.14 bcast=192.168.1.255 netmask=255.255.255.0 added interface eth0 ip=192.168.1.15 bcast=192.168.1.255 netmask=255.255.255.0 Registered MSG_REQ_POOL_USAGE Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED get_dc_list: preferred server list: ", *" dns_send_req: Failed to resolve _ldap._tcp.abc._sites.dc._msdcs.abc.COM (Success) ads_dns_lookup_srv: Failed to send DNS query (NT_STATUS_UNSUCCESSFUL) dns_send_req: Failed to resolve _ldap._tcp.dc._msdcs.abc.COM (Success) ads_dns_lookup_srv: Failed to send DNS query (NT_STATUS_UNSUCCESSFUL) get_sorted_dc_list: no server for name abc.COM available in site abc, fallback to all servers get_dc_list: preferred server list: ", *" dns_send_req: Failed to resolve _ldap._tcp.dc._msdcs.abc.COM (Success) ads_dns_lookup_srv: Failed to send DNS query (NT_STATUS_UNSUCCESSFUL) get_dc_list: preferred server list: ", *" resolve_lmhosts: Attempting lmhosts lookup for name abc.COM<0x1c> resolve_lmhosts: Attempting lmhosts lookup for name abc.COM<0x1c> resolve_wins: using WINS server 127.0.0.1 and tag '*' name_resolve_bcast: Attempting broadcast lookup for name abc.COM<0x1c> get_sorted_dc_list: no server for name abc.COM available in site abc, fallback to all servers get_dc_list: preferred server list: ", *" resolve_lmhosts: Attempting lmhosts lookup for name abc.COM<0x1c> resolve_lmhosts: Attempting lmhosts lookup for name abc.COM<0x1c> name_resolve_bcast: Attempting broadcast lookup for name abc.COM<0x1c> ads_connect: No logon servers get_dc_list: preferred server list: ", *" dns_send_req: Failed to resolve _ldap._tcp.abc._sites.dc._msdcs.abc.COM (Success) ads_dns_lookup_srv: Failed to send DNS query (NT_STATUS_UNSUCCESSFUL) dns_send_req: Failed to resolve _ldap._tcp.dc._msdcs.abc.COM (Success) ads_dns_lookup_srv: Failed to send DNS query (NT_STATUS_UNSUCCESSFUL) get_sorted_dc_list: no server for name abc.COM available in site abc, fallback to all servers get_dc_list: preferred server list: ", *" dns_send_req: Failed to resolve _ldap._tcp.dc._msdcs.abc.COM (Success) ads_dns_lookup_srv: Failed to send DNS query (NT_STATUS_UNSUCCESSFUL) get_dc_list: preferred server list: ", *" resolve_lmhosts: Attempting lmhosts lookup for name abc.COM<0x1c> resolve_lmhosts: Attempting lmhosts lookup for name abc.COM<0x1c> name_resolve_bcast: Attempting broadcast lookup for name abc.COM<0x1c> get_sorted_dc_list: no server for name abc.COM available in site abc, fallback to all servers get_dc_list: preferred server list: ", *" resolve_lmhosts: Attempting lmhosts lookup for name abc.COM<0x1c> resolve_lmhosts: Attempting lmhosts lookup for name abc.COM<0x1c> name_resolve_bcast: Attempting broadcast lookup for name abc.COM<0x1c> ads_connect: No logon servers Didn't find the ldap server! return code = -1 root@abc-ucs:~#

ads_dns_lookup_srv: Failed to send DNS query (NT_STATUS_UNSUCCESSFUL)
dns_send_req: Failed to resolve _ldap._tcp.dc._msdcs.abc.COM (Success)

Check that your UCS DNS entries are in your DNS Domain. It look like your missing your * _ldap._tcp entries for all our UCS DCs.

Per the UCS support database: sdb.univention.de/content/20/279 … n-ucs.html

These entries need to be either on your UCS DNS (which should create them at install of UCS AD Modules) or your external DNS needs to have them added manually:

The following DNS service records are used in an UCS domain:

  • _domaincontroller_master._tcp - hostname of UCS domaincontroller master
  • _kerberos._tcp - each kerberos server of the UCS domain that is reachable via TCP
  • _kerberos._udp - each kerberos server of the UCS domain that is reachable via UDP
  • _kerberos-adm._tcp - the administrative kerberos server
  • _ldap._tcp - each UCS domaincontroller
  • _pkgdb._tcp - UCS system on which the package database is used

[quote=“BrianBonnell”]ads_dns_lookup_srv: Failed to send DNS query (NT_STATUS_UNSUCCESSFUL)
dns_send_req: Failed to resolve _ldap._tcp.dc._msdcs.abc.COM (Success)

Check that your UCS DNS entries are in your DNS Domain. It look like your missing your * _ldap._tcp entries for all our UCS DCs.

Per the UCS support database: sdb.univention.de/content/20/279 … n-ucs.html

These entries need to be either on your UCS DNS (which should create them at install of UCS AD Modules) or your external DNS needs to have them added manually:

The following DNS service records are used in an UCS domain:

  • _domaincontroller_master._tcp - hostname of UCS domaincontroller master
  • _kerberos._tcp - each kerberos server of the UCS domain that is reachable via TCP
  • _kerberos._udp - each kerberos server of the UCS domain that is reachable via UDP
  • _kerberos-adm._tcp - the administrative kerberos server
  • _ldap._tcp - each UCS domaincontroller
  • _pkgdb._tcp - UCS system on which the package database is used[/quote]
    I checked this carefully. It seems to be OK. Below is the result of command host -al $(dnsdomainname)

[code]root@abc-ucs:~# host -al $(dnsdomainname)
Trying “abc.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41950
;; flags: qr aa ra; QUERY: 1, ANSWER: 145, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;abc.com. IN AXFR

;; ANSWER SECTION:
abc.com. 10800 IN SOA abc-ucs.abc.com. root.abc.com. 92 28800 7200 604800 3600
abc.com. 900 IN NS abc-ucs.abc.com.
abc.com. 900 IN NS abc-ucs-2.abc.com.
abc.com. 900 IN A 192.168.1.15
abc.com. 900 IN A 192.168.1.24
abc.com. 900 IN A 192.168.1.14

_msdcs.abc.com. 0 IN NS abc-dc1.abc.com.
_msdcs.abc.com. 0 IN NS abc-ad.abc.com.

abc-DC1.abc.com. 3600 IN CNAME abc-ucs.abc.com.
_gc._tcp.abc.com. 900 IN SRV 0 100 3268 abc-ucs-2.abc.com.
_gc._tcp.abc.com. 900 IN SRV 0 100 3268 abc-ucs.abc.com.

_ldap._tcp.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
_ldap._tcp.abc.com. 900 IN SRV 0 100 389 abc-ucs-2.abc.com.

_pkgdb._tcp.abc.com. 900 IN SRV 0 0 5432 abc-ucs.abc.com.
_VLMCS._TCP.abc.com. 3600 IN SRV 0 0 1688 test12345.abc.com.

_kpasswd._udp.abc.com. 900 IN SRV 0 100 464 abc-ucs.abc.com.
_kpasswd._udp.abc.com. 900 IN SRV 0 100 464 abc-ucs-2.abc.com.
_kpasswd._tcp.abc.com. 900 IN SRV 0 100 464 abc-ucs.abc.com.
_kpasswd._tcp.abc.com. 900 IN SRV 0 100 464 abc-ucs-2.abc.com.

_kerberos._udp.abc.com. 900 IN SRV 0 100 88 abc-ucs.abc.com.
_kerberos._udp.abc.com. 900 IN SRV 0 100 88 abc-ucs-2.abc.com.
_kerberos._tcp.abc.com. 900 IN SRV 0 100 88 abc-ucs.abc.com.
_kerberos._tcp.abc.com. 900 IN SRV 0 100 88 abc-ucs-2.abc.com.
ForestDnsZones.abc.com. 900 IN A 192.168.1.14
ForestDnsZones.abc.com. 900 IN A 192.168.1.24
ForestDnsZones.abc.com. 900 IN A 192.168.1.15

DomainDnsZones.abc.com. 900 IN A 192.168.1.15
DomainDnsZones.abc.com. 900 IN A 192.168.1.24
DomainDnsZones.abc.com. 900 IN A 192.168.1.14

_kerberos-adm._tcp.abc.com. 900 IN SRV 0 100 88 abc-ucs.abc.com.
_ldap._tcp.gc._msdcs.abc.com. 900 IN SRV 0 100 3268 abc-ucs-2.abc.com.
_ldap._tcp.gc._msdcs.abc.com. 900 IN SRV 0 100 3268 abc-ucs.abc.com.
_ldap._tcp.dc._msdcs.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
_ldap._tcp.dc._msdcs.abc.com. 900 IN SRV 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.pdc._msdcs.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
_gc._tcp.abc._sites.abc.com. 900 IN SRV 0 100 3268 abc-ucs-2.abc.com.
_gc._tcp.abc._sites.abc.com. 900 IN SRV 0 100 3268 abc-ucs.abc.com.
_ldap._tcp.abc._sites.abc.com. 900 IN SRV 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.abc._sites.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
_kerberos._tcp.dc._msdcs.abc.com. 900 IN SRV 0 100 88 abc-ucs.abc.com.
_kerberos._tcp.dc._msdcs.abc.com. 900 IN SRV 0 100 88 abc-ucs-2.abc.com.
_ldap._tcp.ForestDnsZones.abc.com. 900 IN SRV 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.ForestDnsZones.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
_ldap._tcp.DomainDnsZones.abc.com. 900 IN SRV 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.DomainDnsZones.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
_kerberos._tcp.abc._sites.abc.com. 900 IN SRV 0 100 88 abc-ucs-2.abc.com.
_kerberos._tcp.abc._sites.abc.com. 900 IN SRV 0 100 88 abc-ucs.abc.com.
_domaincontroller_master._tcp.abc.com. 900 IN SRV 0 0 0 abc-ucs.abc.com.
_ldap._tcp.abc._sites.gc._msdcs.abc.com. 900 IN SRV 0 100 3268 abc-ucs-2.abc.com.
_ldap._tcp.abc._sites.gc._msdcs.abc.com. 900 IN SRV 0 100 3268 abc-ucs.abc.com.
_ldap._tcp.abc._sites.dc._msdcs.abc.com. 900 IN SRV 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.abc._sites.dc._msdcs.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
_kerberos._tcp.abc._sites.dc._msdcs.abc.com. 900 IN SRV 0 100 88 abc-ucs-2.abc.com.
_kerberos._tcp.abc._sites.dc._msdcs.abc.com. 900 IN SRV 0 100 88 abc-ucs.abc.com.
_ldap._tcp.abc._sites.ForestDnsZones.abc.com. 900 IN SRV 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.abc._sites.ForestDnsZones.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
_ldap._tcp.abc._sites.DomainDnsZones.abc.com. 900 IN SRV 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.abc._sites.DomainDnsZones.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
_gc._tcp.Default-First-Site-Name._sites.abc.com. 900 IN SRV 0 100 3268 abc-ucs.abc.com.
_ldap._tcp.Default-First-Site-Name._sites.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
_ldap._tcp.Default-First-Site-Name._sites.abc.com. 900 IN SRV 0 100 389 abc-ucs-2.abc.com.
f566e9ac-0c27-4b08-9c63-86a85ddec414._msdcs.abc.com. 900 IN CNAME abc-ucs-2.abc.com.
5dea7521-b1fe-46c4-b6ef-8889ab3c2b09._msdcs.abc.com. 3600 IN CNAME abc-ucs.abc.com.
17606d4f-27e4-43de-90b5-424cb4b4399f._msdcs.abc.com. 900 IN CNAME abc-ucs.abc.com.
_kerberos._tcp.Default-First-Site-Name._sites.abc.com. 900 IN SRV 0 100 88 abc-ucs.abc.com.
_kerberos._tcp.Default-First-Site-Name._sites.abc.com. 900 IN SRV 0 100 88 abc-ucs-2.abc.com.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.abc.com. 900 IN SRV 0 100 3268 abc-ucs.abc.com.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.abc.com. 900 IN SRV 0 100 389 abc-ucs-2.abc.com.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.abc.com. 900 IN SRV 0 100 88 abc-ucs.abc.com.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.abc.com. 900 IN SRV 0 100 88 abc-ucs-2.abc.com.
_ldap._tcp.c151ba93-a5ed-45a3-b232-eed06113b226.domains._msdcs.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
_ldap._tcp.c151ba93-a5ed-45a3-b232-eed06113b226.domains._msdcs.abc.com. 900 IN SRV 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.3ddd65e0-4746-4214-ad0d-f20b3fe4ce80.domains._msdcs.abc.com. 900 IN SRV 0 100 389 abc-ucs.abc.com.
abc.com. 10800 IN SOA abc-ucs.abc.com. root.abc.com. 92 28800 7200 604800 3600

Received 5117 bytes from 192.168.1.15#53 in 21 ms
[/code]
… is the A records of clients which I removed
Notes: abc-dc1 is the computer name of Primary Windows AD Domain Controller before the AD Takeover with IP 192.168.1.14
Now both UCS servers cannot find ldap server. Please help me to solve this problem. Thanks

Hi,

the error on “net ads status” might be a “red herring” as it will probably succeed once you do a “kinit Administrator” before running the tool.

Your first post already included the output of “samba-tool drs showrepl” which shows replication errors. This could be the origin of the problem.
Have you already checked the Samba 4 Troubleshooting Guide? There are some things mentioned which should be checked in this case.

Note: it is helpful to illustrate the intended setup, especially if you are going to anonymize your domain for some obvious reasons. Checking the output of the commands you posted would be a bit easier.

Best Regards,
Dirk Ahrnke

[quote=“ahrnke”]Hi,

the error on “net ads status” might be a “red herring” as it will probably succeed once you do a “kinit Administrator” before running the tool.

Your first post already included the output of “samba-tool drs showrepl” which shows replication errors. This could be the origin of the problem.
Have you already checked the Samba 4 Troubleshooting Guide? There are some things mentioned which should be checked in this case.

Note: it is helpful to illustrate the intended setup, especially if you are going to anonymize your domain for some obvious reasons. Checking the output of the commands you posted would be a bit easier.

Best Regards,
Dirk Ahrnke[/quote]
I follow almost SDB topic of UCS Univention but there’s no lucky to find out the reason. From Windows AD, we had a policy to change the user “Administrator” to another user. We did not remove this policy and after the AD takeover process, we met this situation. I tried to create a username “Administrator” which belong to a lot of admin/domain admin groups but it seems to be not successful. I will try to check all the log of system for the main reason of this. Hope that anyone can help me to troubleshoot this issue soon. Thanks

Hello fmp,

I’ll do my best. As a first step, could we go back to your initial problem first? You wrote that “there are some errors to login the domain from the Windows clients” - what does ‘some errors’ mean?

Just to clarify things for me a bit, could please tell me:
[ul][li] Are you able to log in to the webbased Univention Management Console (UMC)?
Please try the UMC of the DC Master and the UMC on one of your DC Slaves. For each one, try with your “Administrator” and a regular Domain User.
If you renamed the Administrator account, please try with the renamed one. I guess this is also the account used to do the AD Takeover?[/li]
[li] Are all users unable to log in on Windows Clients or only some of them?
If only some of them, can you spot differences to users where it is working? Does it depend on the users, the clients or does it seem random? What about your “Administrator”?[/li][/ul]

Nevertheless, it’s quite obvious that your DC Slave(s) DO have a problem, but I would like to clarify the things mentioned above before digging deeper.

Only one more question, just to be sure:
[ul]
[li] Were the DC Slaves installed and joined before the AD Takeover or afterwards?[/li][/ul]

Best regards,
Michael Grandjean

[quote=“Grandjean”]Hello fmp,

I’ll do my best. As a first step, could we go back to your initial problem first? You wrote that “there are some errors to login the domain from the Windows clients” - what does ‘some errors’ mean? Some of our clients got this error when logon: The trust relationship between this workstation and the primary domain failed. So we unjoin the clients from domain and rejoin them. But when we join the clients, if we type the domain name ABC.COM it causes an error: An Active Directory Domain Controller (AD DC) for the domain “ABC.COM” could not be contacted. I checked the SVR record as detail instruction but every DNS SVR record is ok. Then, I tried to type “ABC” in the domain field, and it’s ok. The domain join progress is successfully. Until now, I still have to type ABC instead of ABC.COM to join new clients (Windows 7 & Windows Server 2008 R2) to UCS domain system. There’s one thing I do not understand, if I unjoin a client, delete that computer (and related objects) via UMC and join that computer again, DNS records for this client will be created successfully but there’s no computer object for this one.

Just to clarify things for me a bit, could please tell me:
[ul][li] Are you able to log in to the webbased Univention Management Console (UMC)? Yes, the login to UMC of both UCS server are ok.
Please try the UMC of the DC Master and the UMC on one of your DC Slaves. For each one, try with your “Administrator” and a regular Domain User.
If you renamed the Administrator account, please try with the renamed one. I guess this is also the account used to do the AD Takeover? Yes, this is the account used to do the AD Takeover. Yesterday, I created an account named “Administrator” (with all domain admin groups) and there’s no problem with this.[/li]
[li] Are all users unable to log in on Windows Clients or only some of them? Only some
If only some of them, can you spot differences to users where it is working? Does it depend on the users, the clients or does it seem random? What about your “Administrator”?[/li][/ul]There’s no differences, it seems to be random… The “Administrator” is ok to logon

Nevertheless, it’s quite obvious that your DC Slave(s) DO have a problem, but I would like to clarify the things mentioned above before digging deeper.

Only one more question, just to be sure:
[ul]
[li] Were the DC Slaves installed and joined before the AD Takeover or afterwards?[/li][/ul] The UCS slave was installed after the successful AD Takeover progress.

Best regards,
Michael Grandjean[/quote]
Hi Michael, thank you for your help. Pls have a look at my answer in blue color. If you need any logs or result of which command, pls let me know. Thank you.

Hello fmp,

Okay, this seems to be a DNS issue nevertheless. If I recall correctly: if one uses the FQDN of the domain (ABC.COM), the lookup of the Domain Controller is done via DNS. If one uses the short legacy domain name (ABC), the lookup is done via Netbios. So obviously, DNS does not work for some reason. We can try a couple of things here:

[ol][li]Use this commandline tool on your UCS DC Master to check if all necessary DNS records are present and please post the result:

/usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh

[li]Check with this command (just copy and paste) if the UCS DC Master is able to lookup the needed DNS service records and post the results (I’ve ssen your “host -al $(dnsdomainname)” above, but let’s try different angles):

host -t SRV _kerberos._tcp.$(ucr get domainname) $(hostname -f) host -t SRV _ldap._tcp.$(ucr get domainname) $(hostname -f)[/li]
[li]Check the same thing on your DC Slave - first, asking the DC Master and second, asking the DC Slave itself:

host -t SRV _kerberos._tcp.$(ucr get domainname) $(ucr get ldap/master) host -t SRV _ldap._tcp.$(ucr get domainname) $(ucr get ldap/master) host -t SRV _kerberos._tcp.$(ucr get domainname) $(hostname -f) host -t SRV _ldap._tcp.$(ucr get domainname) $(hostname -f)[/li]
[li]Last but not least: Check this also on your Windows Clients. There we need to use the nslookup command (replace abc.com accordingly):

nslookup -type=SRV _ldap._tcp.abc.com abc-ucs.abc.com nslookup -type=SRV _kerberos._tcp.abc.com abc-ucs.abc.com nslookup -type=SRV _ldap._tcp.abc.com abc-ucs-2.abc.com nslookup -type=SRV _kerberos._tcp.abc.com abc-ucs-2.abc.com[/li][/ol]

Hm, this is strange behaviour. I would give this a lower priority for now and eventually come back to it later.

[quote=“fmp”]Only some
[…]
There’s no differences, it seems to be random… The “Administrator” is ok to logon[/quote]

I should have also asked: Does an affected user have this problem always? Or does it work the one day and doesn’t work the other day? Or maybe it’s the other way round after a reboot?

Thanks. “Successful” means that the log in problems were not there right away but occured later (e.g. after installing and joining the DC Slave)?

Oh, and just to be more complete, could you please post the result of these commands on your DC Master and DC Slave?

ucr search --brief ^version univention-check-join-status univention-s4connector-list-rejected

[quote=“Grandjean”]Hello fmp,

Okay, this seems to be a DNS issue nevertheless. If I recall correctly: if one uses the FQDN of the domain (ABC.COM), the lookup of the Domain Controller is done via DNS. If one uses the short legacy domain name (ABC), the lookup is done via Netbios. So obviously, DNS does not work for some reason. We can try a couple of things here:

[ol][li]Use this commandline tool on your UCS DC Master to check if all necessary DNS records are present and please post the result:

/usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh

[li]Check with this command (just copy and paste) if the UCS DC Master is able to lookup the needed DNS service records and post the results (I’ve ssen your “host -al $(dnsdomainname)” above, but let’s try different angles):

host -t SRV _kerberos._tcp.$(ucr get domainname) $(hostname -f) host -t SRV _ldap._tcp.$(ucr get domainname) $(hostname -f)[/li]
[li]Check the same thing on your DC Slave - first, asking the DC Master and second, asking the DC Slave itself:

host -t SRV _kerberos._tcp.$(ucr get domainname) $(ucr get ldap/master) host -t SRV _ldap._tcp.$(ucr get domainname) $(ucr get ldap/master) host -t SRV _kerberos._tcp.$(ucr get domainname) $(hostname -f) host -t SRV _ldap._tcp.$(ucr get domainname) $(hostname -f)[/li]
[li]Last but not least: Check this also on your Windows Clients. There we need to use the nslookup command (replace abc.com accordingly):

nslookup -type=SRV _ldap._tcp.abc.com abc-ucs.abc.com nslookup -type=SRV _kerberos._tcp.abc.com abc-ucs.abc.com nslookup -type=SRV _ldap._tcp.abc.com abc-ucs-2.abc.com nslookup -type=SRV _kerberos._tcp.abc.com abc-ucs-2.abc.com[/li][/ol]

Hm, this is strange behaviour. I would give this a lower priority for now and eventually come back to it later.

[quote=“fmp”]Only some
[…]
There’s no differences, it seems to be random… The “Administrator” is ok to logon[/quote]

I should have also asked: Does an affected user have this problem always? Or does it work the one day and doesn’t work the other day? Or maybe it’s the other way round after a reboot?

Thanks. “Successful” means that the log in problems were not there right away but occured later (e.g. after installing and joining the DC Slave)?

Oh, and just to be more complete, could you please post the result of these commands on your DC Master and DC Slave?

ucr search --brief ^version univention-check-join-status univention-s4connector-list-rejected[/quote]
Appreciate for your help. Pls have a look at my answer as below:

Result of command: /usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh

[code]root@abc-ucs:~# /usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh
Host gc._msdcs not found: 3(NXDOMAIN)
_gc._tcp.abc.com has SRV record 0 100 3268 abc-ucs.abc.com.
_gc._tcp.abc.com has SRV record 0 100 3268 abc-ucs-2.abc.com.
Host _ldap._tcp.gc._msdcs not found: 3(NXDOMAIN)
_ldap._tcp.abc.com has SRV record 0 100 389 abc-ucs.abc.com.
_ldap._tcp.abc.com has SRV record 0 100 389 abc-ucs-2.abc.com.
Host _ldap._tcp.dc._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.pdc._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.c151ba93-a5ed-45a3-b232-eed06113b226.domains._msdcs not found: 3(NXDOMAIN)
Host _kerberos._tcp.dc._msdcs not found: 3(NXDOMAIN)
_kerberos._tcp.abc.com has SRV record 0 100 88 abc-ucs-2.abc.com.
_kerberos._tcp.abc.com has SRV record 0 100 88 abc-ucs.abc.com.
_kerberos._udp.abc.com has SRV record 0 100 88 abc-ucs-2.abc.com.
_kerberos._udp.abc.com has SRV record 0 100 88 abc-ucs.abc.com.
_kpasswd._tcp.abc.com has SRV record 0 100 464 abc-ucs.abc.com.
_kpasswd._tcp.abc.com has SRV record 0 100 464 abc-ucs-2.abc.com.
_kpasswd._udp.abc.com has SRV record 0 100 464 abc-ucs-2.abc.com.
_kpasswd._udp.abc.com has SRV record 0 100 464 abc-ucs.abc.com.
Located DC ‘abc-ucs’ in site ‘abc’
Located DC ‘abc-ucs-2’ in site ‘abc’
Host 17606d4f-27e4-43de-90b5-424cb4b4399f._msdcs not found: 3(NXDOMAIN)
Host f566e9ac-0c27-4b08-9c63-86a85ddec414._msdcs not found: 3(NXDOMAIN)

Records for site abc:

_ldap._tcp.abc._sites.abc.com has SRV record 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.abc._sites.abc.com has SRV record 0 100 389 abc-ucs.abc.com.
Host _ldap._tcp.abc._sites.dc._msdcs not found: 3(NXDOMAIN)
_kerberos._tcp.abc._sites.abc.com has SRV record 0 100 88 abc-ucs-2.abc.com.
_kerberos._tcp.abc._sites.abc.com has SRV record 0 100 88 abc-ucs.abc.com.
Host _kerberos._tcp.abc._sites.dc._msdcs not found: 3(NXDOMAIN)

Optional GC Records for site abc:

_gc._tcp.abc._sites.abc.com has SRV record 0 100 3268 abc-ucs-2.abc.com.
_gc._tcp.abc._sites.abc.com has SRV record 0 100 3268 abc-ucs.abc.com.
Host _ldap._tcp.abc._sites.gc._msdcs not found: 3(NXDOMAIN)
No _kerberos TXT record (ok)
root@abc-ucs:~#
[/code]

Result of command: host -t SRV _kerberos._tcp.$(ucr get domainname) $(hostname -f)

[code]root@abc-ucs:~# host -t SRV _kerberos._tcp.$(ucr get domainname) $(hostname -f)
Using domain server:
Name: abc-ucs.abc.com
Address: 192.168.1.15#53
Aliases:

_kerberos._tcp.abc.com has SRV record 0 100 88 abc-ucs-2.abc.com.
_kerberos._tcp.abc.com has SRV record 0 100 88 abc-ucs.abc.com.
root@abc-ucs:~#
[/code]

Result of command: host -t SRV _ldap._tcp.$(ucr get domainname) $(hostname -f)

[code]root@abc-ucs:~# host -t SRV _ldap._tcp.$(ucr get domainname) $(hostname -f)
Using domain server:
Name: abc-ucs.abc.com
Address: 192.168.1.15#53
Aliases:

_ldap._tcp.abc.com has SRV record 0 100 389 abc-ucs.abc.com.
_ldap._tcp.abc.com has SRV record 0 100 389 abc-ucs-2.abc.com.
root@abc-ucs:~#
[/code]

Result of command: host -t SRV _kerberos._tcp.$(ucr get domainname) $(ucr get ldap/master)
UCS Master:

[code]root@abc-ucs:~# host -t SRV _kerberos._tcp.$(ucr get domainname) $(ucr get ldap/master)
Using domain server:
Name: abc-ucs.abc.com
Address: 192.168.1.15#53
Aliases:

_kerberos._tcp.abc.com has SRV record 0 100 88 abc-ucs.abc.com.
_kerberos._tcp.abc.com has SRV record 0 100 88 abc-ucs-2.abc.com.
root@abc-ucs:~#
[/code]
UCS Slave:

[code]root@abc-ucs-2:~# host -t SRV _kerberos._tcp.$(ucr get domainname) $(ucr get ldap/master)
Using domain server:
Name: abc-ucs.abc.com
Address: 192.168.1.15#53
Aliases:

_kerberos._tcp.abc.com has SRV record 0 100 88 abc-ucs-2.abc.com.
_kerberos._tcp.abc.com has SRV record 0 100 88 abc-ucs.abc.com.
root@abc-ucs-2:~# [/code]

Result of command: host -t SRV _ldap._tcp.$(ucr get domainname) $(ucr get ldap/master)
UCS Master:

[code]root@abc-ucs:~# host -t SRV _ldap._tcp.$(ucr get domainname) $(ucr get ldap/master)
Using domain server:
Name: abc-ucs.abc.com
Address: 192.168.1.15#53
Aliases:

_ldap._tcp.abc.com has SRV record 0 100 389 abc-ucs.abc.com.
_ldap._tcp.abc.com has SRV record 0 100 389 abc-ucs-2.abc.com.
root@abc-ucs:~#
[/code]
UCS Slave:

[code]root@abc-ucs-2:~# host -t SRV _ldap._tcp.$(ucr get domainname) $(ucr get ldap/master)
Using domain server:
Name: abc-ucs.abc.com
Address: 192.168.1.15#53
Aliases:

_ldap._tcp.abc.com has SRV record 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.abc.com has SRV record 0 100 389 abc-ucs.abc.com.
root@abc-ucs-2:~#
[/code]

Result of command: host -t SRV _kerberos._tcp.$(ucr get domainname) $(hostname -f)
UCS Master:

[code]root@abc-ucs:~# host -t SRV _kerberos._tcp.$(ucr get domainname) $(hostname -f)
Using domain server:
Name: abc-ucs.abc.com
Address: 192.168.1.15#53
Aliases:

_kerberos._tcp.abc.com has SRV record 0 100 88 abc-ucs-2.abc.com.
_kerberos._tcp.abc.com has SRV record 0 100 88 abc-ucs.abc.com.
root@abc-ucs:~#
[/code]
UCS Slave:

[code]root@abc-ucs-2:~# host -t SRV _kerberos._tcp.$(ucr get domainname) $(hostname -f)
Using domain server:
Name: abc-ucs-2.abc.com
Address: 192.168.1.24#53
Aliases:

_kerberos._tcp.abc.com has SRV record 0 100 88 abc-ucs.abc.com.
_kerberos._tcp.abc.com has SRV record 0 100 88 abc-ucs-2.abc.com.
_kerberos._tcp.abc.com has SRV record 0 100 88 abc-dc1.abc.com.
root@abc-ucs-2:~#
[/code]

Result of command: host -t SRV _ldap._tcp.$(ucr get domainname) $(hostname -f)
UCS Master:

[code]root@abc-ucs:~# host -t SRV _ldap._tcp.$(ucr get domainname) $(hostname -f)
Using domain server:
Name: abc-ucs.abc.com
Address: 192.168.1.15#53
Aliases:

_ldap._tcp.abc.com has SRV record 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.abc.com has SRV record 0 100 389 abc-ucs.abc.com.
root@abc-ucs:~#
[/code]
UCS Slave:

[code]root@abc-ucs-2:~# host -t SRV _ldap._tcp.$(ucr get domainname) $(hostname -f)
Using domain server:
Name: abc-ucs-2.abc.com
Address: 192.168.1.24#53
Aliases:

_ldap._tcp.abc.com has SRV record 0 100 389 abc-dc1.abc.com.
_ldap._tcp.abc.com has SRV record 0 100 389 abc-ucs.abc.com.
_ldap._tcp.abc.com has SRV record 0 100 389 abc-ucs-2.abc.com.
root@abc-ucs-2:~#
[/code]

Result from below command on client computer:

nslookup -type=SRV _ldap._tcp.abc.com abc-ucs.abc.com nslookup -type=SRV _kerberos._tcp.abc.com abc-ucs.abc.com nslookup -type=SRV _ldap._tcp.abc.com abc-ucs-2.abc.com nslookup -type=SRV _kerberos._tcp.abc.com abc-ucs-2.abc.com

C:\Users\mkt.korea>nslookup -type=SRV _ldap._tcp.abc.com abc-ucs.abc.com
Server:  abc-ucs.abc.com
Address:  192.168.1.15

_ldap._tcp.abc.com    SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = abc-ucs.abc.com
_ldap._tcp.abc.com    SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = abc-ucs-2.abc.com
abc.com       nameserver = abc-ucs.abc.com
abc.com       nameserver = abc-ucs-2.abc.com
abc-ucs.abc.com       internet address = 192.168.1.15
abc-ucs.abc.com       internet address = 192.168.1.14
abc-ucs-2.abc.com     internet address = 192.168.1.24

C:\Users\mkt.korea>nslookup -type=SRV _kerberos._tcp.abc.com  abc-ucs.abc.com
Server:  abc-ucs.abc.com
Address:  192.168.1.15

_kerberos._tcp.abc.com        SRV service location:
          priority       = 0
          weight         = 100
          port           = 88
          svr hostname   = abc-ucs-2.abc.com
_kerberos._tcp.abc.com        SRV service location:
          priority       = 0
          weight         = 100
          port           = 88
          svr hostname   = abc-ucs.abc.com
abc.com       nameserver = abc-ucs.abc.com
abc.com       nameserver = abc-ucs-2.abc.com
abc-ucs.abc.com       internet address = 192.168.1.14
abc-ucs.abc.com       internet address = 192.168.1.15
abc-ucs-2.abc.com     internet address = 192.168.1.24


C:\Users\mkt.korea>nslookup -type=SRV _ldap._tcp.abc.com abc-ucs-2.abc.com
Server:  abc-ucs-2.abc.com
Address:  192.168.1.24

_ldap._tcp.abc.com    SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = abc-dc1.abc.com
_ldap._tcp.abc.com    SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = abc-ucs.abc.com
_ldap._tcp.abc.com    SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = abc-ucs-2.abc.com
abc.com       nameserver = abc-ucs-2.abc.com
abc.com       nameserver = abc-ucs.abc.com
abc-ucs.abc.com       internet address = 192.168.1.15
abc-ucs-2.abc.com     internet address = 192.168.1.24


C:\Users\mkt.korea>nslookup -type=SRV _kerberos._tcp.abc.com  abc-ucs-2.abc.com
Server:  abc-ucs-2.abc.com
Address:  192.168.1.24

_kerberos._tcp.abc.com        SRV service location:
          priority       = 0
          weight         = 100
          port           = 88
          svr hostname   = abc-dc1.abc.com
_kerberos._tcp.abc.com        SRV service location:
          priority       = 0
          weight         = 100
          port           = 88
          svr hostname   = abc-ucs.abc.com
_kerberos._tcp.abc.com        SRV service location:
          priority       = 0
          weight         = 100
          port           = 88
          svr hostname   = abc-ucs-2.abc.com
abc.com       nameserver = abc-ucs-2.abc.com
abc.com       nameserver = abc-ucs.abc.com
abc-ucs.abc.com       internet address = 192.168.1.15
abc-ucs-2.abc.com     internet address = 192.168.1.24[/code]

Final is result from below commands: all result is the same except the last one
[code]ucr search --brief ^version
univention-check-join-status
univention-s4connector-list-rejected[/code]

[code]root@abc-ucs:~# ucr search --brief ^version
version/erratalevel: 336
version/patchlevel: 3
version/releasename: Walle
version/version: 4.0
root@abc-ucs:~# 

root@abc-ucs:~# univention-check-join-status Joined successfully root@abc-ucs:~#

[code]root@abc-ucs:~# univention-s4connector-list-rejected

UCS rejected

1:   UCS DN: cn=abc-XRAY-TECH,ou=BlockUSB,ou=abc,dc=abc,dc=com
      S4 DN: cn=abc-xray-tech,ou=blockusb,ou=abc,DC=abc,DC=com
     Filename: /var/lib/univention-connector/s4/1444007999.598053

2:   UCS DN: cn=HN-W1,cn=computers,dc=abc,dc=com
      S4 DN: cn=hn-w1,cn=computers,DC=abc,DC=com
     Filename: /var/lib/univention-connector/s4/1444235471.789736

S4 rejected

1:    S4 DN: DC=_VLMCS._TCP,DC=abc.com,CN=MicrosoftDNS,CN=System,DC=abc,DC=com
     UCS DN: <not found>

last synced USN: 16766

root@abc-ucs:~# [/code]

[code]root@abc-ucs-2:~# univention-s4connector-list-rejected

UCS rejected

S4 rejected

There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.

last synced USN: 0

root@abc-ucs-2:~#
[/code]

I tried to remove objects in the rejected list several times but now it appears another object again…

Yes, some clients worked for one day, some for a few days or after a reboot and got error “the relationship”. But some clients got no error even they are in the same group as well as OU.

There are 2 kinds of relationship error message:

The trust relationship between this workstation and the primary domain failed
and
The security database on the server does not have a computer account for this workstation trust relationship

And the solution for our last several days is unjoin and rejoin the clients. Hope that you can show me where I was wrong. Thank you.

Hello fmp,

thanks for providing all these information. So basically DNS is working, even from different hosts/clients.

But your installation is missing the _msdcs parts, see all the “not found: 3(NXDOMAIN)” errors in “check_essential_samba4_dns_records.sh”. This is a special DNS subdomain that contains Microsoft/AD specific SRV records. Maybe this was already missing before the takeover?
Just as with all the other SRV records (e.g. _kerberos._tcp.abc.com), there should be entries for all the missing _msdcs parts referring to the DC Master and mostly also to the DC Slave.

Your situation:

Host gc._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.gc._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.dc._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.pdc._msdcs not found: 3(NXDOMAIN)
Host _kerberos._tcp.dc._msdcs not found: 3(NXDOMAIN)
Host 17606d4f-27e4-43de-90b5-424cb4b4399f._msdcs not found: 3(NXDOMAIN)
Host f566e9ac-0c27-4b08-9c63-86a85ddec414._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.abc._sites.dc._msdcs not found: 3(NXDOMAIN)
Host _kerberos._tcp.abc._sites.dc._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.abc._sites.gc._msdcs not found: 3(NXDOMAIN)

But it should be:

gc._msdcs.abc.com has address 192.168.1.14
gc._msdcs.abc.com has address 192.168.1.24

_ldap._tcp.gc._msdcs.abc.com has SRV record 0 100 3268 abc-ucs.abc.com.
_ldap._tcp.gc._msdcs.abc.com has SRV record 0 100 3268 abc-ucs-2.abc.com.

_ldap._tcp.dc._msdcs.abc.com has SRV record 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.dc._msdcs.abc.com has SRV record 0 100 389 abc-ucs.abc.com.

_ldap._tcp.pdc._msdcs.abc.com has SRV record 0 100 389 abc-ucs.abc.com.

_kerberos._tcp.dc._msdcs.abc.com has SRV record 0 100 88 abc-ucs.abc.com.
_kerberos._tcp.dc._msdcs.abc.com has SRV record 0 100 88 abc-ucs-2.abc.com.

17606d4f-27e4-43de-90b5-424cb4b4399f._msdcs.abc.com is an alias for abc-ucs.abc.com.
f566e9ac-0c27-4b08-9c63-86a85ddec414._msdcs.abc.com is an alias for abc-ucs-2.abc.com.

_ldap._tcp.abc._sites.dc._msdcs.abc.com has SRV record 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.abc._sites.dc._msdcs.abc.com has SRV record 0 100 389 abc-ucs.abc.com.

_kerberos._tcp.abc._sites.dc._msdcs.abc.com has SRV record 0 100 88 abc-ucs-2.abc.com.
_kerberos._tcp.abc._sites.dc._msdcs.abc.com has SRV record 0 100 88 abc-ucs.abc.com.

_ldap._tcp.abc._sites.gc._msdcs.abc.com has SRV record 0 100 3268 abc-ucs.abc.com.
_ldap._tcp.abc._sites.gc._msdcs.abc.com has SRV record 0 100 3268 abc-ucs-2.abc.com.

Please note that I’m not sure if this is correct:

17606d4f-27e4-43de-90b5-424cb4b4399f._msdcs.abc.com is an alias for abc-ucs.abc.com.
f566e9ac-0c27-4b08-9c63-86a85ddec414._msdcs.abc.com is an alias for abc-ucs-2.abc.com.

It could be the other way round.

Additionally, there’s a difference in SRV records regarding abc-dc1. This is the old Windows DC that was shutdown after the Takeover, right?
On your DC Slave, these records are still present in the local DNS while they are NOT present in the DNS of the DC Master:

LDAP and Kerberos SRV records known on the DC Master (abc-ucs):

abc-ucs.abc.com
abc-ucs-2.abc.com

LDAP and Kerberos SRV records known on the DC Slave (abc-ucs-2):

abc-dc1.abc.com
abc-ucs.abc.com
abc-ucs-2.abc.com

If I compare this to a test environment (also with Takeover) then the DC Slave is wrong here.

The same goes for the IP adresse of the old Windows DC that is usually also taken over by the DC Master as an additional (virtual) IP during Takeover. But here it’s the other way round:

When asking the DC Master DNS:

abc-ucs.abc.com       internet address = 192.168.1.14
abc-ucs.abc.com       internet address = 192.168.1.15

But when asking the DC Slave DNS:

abc-ucs.abc.com       internet address = 192.168.1.15

Again, the DC Slave doesn’t have the correct information.

Regarding the S4-Connector-Rejects: They don’t seem that important to me, regarding the current problem. For example the one with _VLMCS seems to be a SRV record for the Microsoft KMS licence server.

I think we have two options now:

  1. Fix all the mentioned DNS issues manually (use the UMC module “DNS” in the “Domain” category) and then check if this improves the situation
  2. Consider reprovisioning the whole Samba AD directory according to this SDB article: sdb.univention.de/1282

The first option might resolve the problem or at least improve the situation, but I can’t guarantee that.
The second option might be a quick win but you need to have a working backup/restore and should try this first in a cloned test environment. It also takes some time, so you might need to plan a maintenance window.

Thanks, this kind of supports my theory: If the client asks e.g. the DC Master, it’s working. If the same client asks the DC Slave, it’s not working. Windows clients pick their logon servers randomly (based on DNS or Netbios) during boot. Do you have the possibility to turn off the DC Slave for a while and see if it gets any better?

PS: Don’t miss my previous post :slight_smile:

[quote=“Grandjean”]Hello fmp,

thanks for providing all these information. So basically DNS is working, even from different hosts/clients.

But your installation is missing the _msdcs parts, see all the “not found: 3(NXDOMAIN)” errors in “check_essential_samba4_dns_records.sh”. This is a special DNS subdomain that contains Microsoft/AD specific SRV records. Maybe this was already missing before the takeover?
Just as with all the other SRV records (e.g. _kerberos._tcp.abc.com), there should be entries for all the missing _msdcs parts referring to the DC Master and mostly also to the DC Slave.

Your situation:

Host gc._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.gc._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.dc._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.pdc._msdcs not found: 3(NXDOMAIN)
Host _kerberos._tcp.dc._msdcs not found: 3(NXDOMAIN)
Host 17606d4f-27e4-43de-90b5-424cb4b4399f._msdcs not found: 3(NXDOMAIN)
Host f566e9ac-0c27-4b08-9c63-86a85ddec414._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.abc._sites.dc._msdcs not found: 3(NXDOMAIN)
Host _kerberos._tcp.abc._sites.dc._msdcs not found: 3(NXDOMAIN)
Host _ldap._tcp.abc._sites.gc._msdcs not found: 3(NXDOMAIN)

But it should be:

gc._msdcs.abc.com has address 192.168.1.14
gc._msdcs.abc.com has address 192.168.1.24

_ldap._tcp.gc._msdcs.abc.com has SRV record 0 100 3268 abc-ucs.abc.com.
_ldap._tcp.gc._msdcs.abc.com has SRV record 0 100 3268 abc-ucs-2.abc.com.

_ldap._tcp.dc._msdcs.abc.com has SRV record 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.dc._msdcs.abc.com has SRV record 0 100 389 abc-ucs.abc.com.

_ldap._tcp.pdc._msdcs.abc.com has SRV record 0 100 389 abc-ucs.abc.com.

_kerberos._tcp.dc._msdcs.abc.com has SRV record 0 100 88 abc-ucs.abc.com.
_kerberos._tcp.dc._msdcs.abc.com has SRV record 0 100 88 abc-ucs-2.abc.com.

17606d4f-27e4-43de-90b5-424cb4b4399f._msdcs.abc.com is an alias for abc-ucs.abc.com.
f566e9ac-0c27-4b08-9c63-86a85ddec414._msdcs.abc.com is an alias for abc-ucs-2.abc.com.

_ldap._tcp.abc._sites.dc._msdcs.abc.com has SRV record 0 100 389 abc-ucs-2.abc.com.
_ldap._tcp.abc._sites.dc._msdcs.abc.com has SRV record 0 100 389 abc-ucs.abc.com.

_kerberos._tcp.abc._sites.dc._msdcs.abc.com has SRV record 0 100 88 abc-ucs-2.abc.com.
_kerberos._tcp.abc._sites.dc._msdcs.abc.com has SRV record 0 100 88 abc-ucs.abc.com.

_ldap._tcp.abc._sites.gc._msdcs.abc.com has SRV record 0 100 3268 abc-ucs.abc.com.
_ldap._tcp.abc._sites.gc._msdcs.abc.com has SRV record 0 100 3268 abc-ucs-2.abc.com.

Please note that I’m not sure if this is correct:

17606d4f-27e4-43de-90b5-424cb4b4399f._msdcs.abc.com is an alias for abc-ucs.abc.com.
f566e9ac-0c27-4b08-9c63-86a85ddec414._msdcs.abc.com is an alias for abc-ucs-2.abc.com.

It could be the other way round.

Additionally, there’s a difference in SRV records regarding abc-dc1. This is the old Windows DC that was shutdown after the Takeover, right?
On your DC Slave, these records are still present in the local DNS while they are NOT present in the DNS of the DC Master:

LDAP and Kerberos SRV records known on the DC Master (abc-ucs):

abc-ucs.abc.com
abc-ucs-2.abc.com

LDAP and Kerberos SRV records known on the DC Slave (abc-ucs-2):

abc-dc1.abc.com
abc-ucs.abc.com
abc-ucs-2.abc.com

If I compare this to a test environment (also with Takeover) then the DC Slave is wrong here.

The same goes for the IP adresse of the old Windows DC that is usually also taken over by the DC Master as an additional (virtual) IP during Takeover. But here it’s the other way round:

When asking the DC Master DNS:

abc-ucs.abc.com       internet address = 192.168.1.14
abc-ucs.abc.com       internet address = 192.168.1.15

But when asking the DC Slave DNS:

abc-ucs.abc.com       internet address = 192.168.1.15

Again, the DC Slave doesn’t have the correct information.

Regarding the S4-Connector-Rejects: They don’t seem that important to me, regarding the current problem. For example the one with _VLMCS seems to be a SRV record for the Microsoft KMS licence server.

I think we have two options now:

  1. Fix all the mentioned DNS issues manually (use the UMC module “DNS” in the “Domain” category) and then check if this improves the situation
  2. Consider reprovisioning the whole Samba AD directory according to this SDB article: sdb.univention.de/1282

The first option might resolve the problem or at least improve the situation, but I can’t guarantee that.
The second option might be a quick win but you need to have a working backup/restore and should try this first in a cloned test environment. It also takes some time, so you might need to plan a maintenance window.[/quote]
Thank you Michael. But as I rememberred, there’s no error after executing the check DNS script as now. There’s no missing record. However, I tried to add the “missing” record as your suggestion but not successful. UMC always tell me that the object already exist. I checked again and it does exist. I do not know why and really confused about this.

I reinstalled a fresh UCS server to takeover AD again but the same error happened. The clients cannot resolve domain name even the time setting and DNS server was correct.

Note: This information is intended for a network administrator.  If you are not your network's administrator, notify the administrator that you received this information, which has been recorded in the file C:\Windows\debug\dcdiag.txt.

The following error occurred when DNS was queried for the service location (SRV) resource record used to locate an Active Directory Domain Controller (AD DC) for domain "abc.com":

The error was: "DNS name does not exist."
(error code 0x0000232B RCODE_NAME_ERROR)

The query was for the SRV record for _ldap._tcp.dc._msdcs.abc.com

Common causes of this error include the following:

- The DNS SRV records required to locate a AD DC for the domain are not registered in DNS. These records are registered with a DNS server automatically when a AD DC is added to a domain. They are updated by the AD DC at set intervals. This computer is configured to use DNS servers with the following IP addresses:

192.168.1.14

- One or more of the following zones do not include delegation to its child zone:

abc.com
com
. (the root zone)

But in the UMC --> DNS: the records does exist.
@Michael: I’ve sent an email to you with logs, samba and univention configuration. Pls help me to find out the reason. Thank you so much.

I found the reason why UCS server told that some records not found although those records do exist in the DNS and LDAP Directory in UMC. The reason is BIND cannot accesses the Samba internal DNS data via the DLZ interface. I did not find out the solution right now but this is a hope to solve this issue :slight_smile:

There’s something so interesting.

  1. Follow the problem of BIND DLZ, I check in the UCR and search with keyword “connector/ad/ldap” and the result is as below:

    It seems that our UCS system is missing some UCR variables…

  2. I made a search in the console of UCS for “bindpw” and it returned no result, so there is no bindpw file exist in UCS system to satisfy the configuration from: /etc/bind/univention.conf.d/abc.com

zone "abc.com" {
        type master;
        notify yes;
        database "ldap ldap://127.0.0.1:7389/zoneName=abc.com,cn=dns,dc=abc,dc=com????!bindname=cn=ucs%2ccn=dc%2ccn=computers%2cdc=abc%2cdc=com,!x-bindpw=xKfmYrnzK3xnUwGBo,x-tls 172800";
};

It seems that the UCS takeover progress got something wrong
Hope that someone can show me how to solve this issue soon. Thank you

Hello fmp,

sorry, I haven’t been around the last days. I’ve seen your e-mails to feedback@ and your entry in our bugtracker. My colleagues will check your case and get back to you. For now, we should wait for this.
All I can say now is, that imho it’s very unlikely that the “connector/ad/*” variables have anything to do with the problem.

Best regards,
Michael Grandjean

Mastodon