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:
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.
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:~#
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.
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)
;; 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
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.
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
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]
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.
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:
[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):
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?
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:
[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):
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]
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.
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:
Fix all the mentioned DNS issues manually (use the UMC module “DNS” in the “Domain” category) and then check if this improves the situation
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?
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:
Fix all the mentioned DNS issues manually (use the UMC module “DNS” in the “Domain” category) and then check if this improves the situation
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
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…
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
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.
