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.
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[/quote]
Hi Michael,
Thank you so much. As my understanding, the UCS system must have more variables which related to AD more than current variables of our system. The join UCS to an AD domain progress will make UCS having some info like: domain DC, in this case is: abc-dc1.abc.com, etc… Below is information when I execute univention-ad-connector command:
This is univention-adsearch
Univention-adsearch uses the settings of "univention-ad-connector" to ldap-search an Active-Directory Server.
The Settings are not complete, please check the following univention-config-registry Values:
connector/ad/ldap/host, connector/ad/ldap/port,
connector/ad/ldap/binddn, connector/ad/ldap/bindpw,
connector/ad/ldap/base
I think UCS system after taking over from Windows AD must have above variables in UCR. Hope that you and your colleagues found the reason and a solution for this issue. Thanks again
Dear fmp,
We would really like to help you with your issue, unfortunatly it apppears that we are at a point where the forum is not the best and applicable means to this end.
To help you effectivly in this case we strongly suggest contacting our salesteam at sales@univention.de to procure a base subscription and a sales call - our salesteam will be glad to assist you in this matter. Then our supportteam will have the means to focus on your issue and bring to a satisfactory conclusion.
I am sure this will be more helpful then forum messages at this point.
[quote=“Thorp-Hansen”]Dear fmp,
We would really like to help you with your issue, unfortunatly it apppears that we are at a point where the forum is not the best and applicable means to this end.
To help you effectivly in this case we strongly suggest contacting our salesteam at sales@univention.de to procure a base subscription and a sales call - our salesteam will be glad to assist you in this matter. Then our supportteam will have the means to focus on your issue and bring to a satisfactory conclusion.
I am sure this will be more helpful then forum messages at this point.
Kind regards,
Jens Thorp-Hansen
Head of Support
Univention GmbH[/quote]
Dear Univention Team,
Honestly, we have plan to purchase a subscription but we need time to test UCS for stability. This is a future plan if we feel that this is a good product. But in fact, UCS still have a lot of bugs, at least for us. About this issue, it comes to us without any warnings from system or via UMC, so we must spent a lot of times to troubleshoot by ourselves. If noone in this forum can help us, we will find another choice to use Samba4 for our system and come back to try products of Univention in some future day. Thank you.
Dear fmp,
I still have eyes on your issue and as I said we want to help you. I want to give some inside in the progress and most likely causes of your present issue.
Since it is rather hard to solve your issues permanently without trying to find the underlying problem, I try to paint the way of the issue for clarification till now:
In july you had a failed AD-Takeover because of a service principal that was where it should not be at this point of the process. There was a workaround, so the AD-Takeover could commence.
Following this, there was a workaround, because the DNS Data was not where expected. Then a workaround for the S4 connector, so that it does not interfere with previous workarounds and additional help via forum and feedback all regarding the system in its present state.
We want to make the system work for you, but we need to first fix the underlying problems.
Can you confirm/check and send the following output from the console? We suspect that there is an issue that interfered with your AD-Takeover process and if that is the case we want to fix this issue and make you able to create a working system.
IF our suspicion turns out true the next step to really solve your issues and not create workaround after workaround would be to start over in a test environment first by doing the following steps:
We provide a bugfix
Start over with a UCS 4.0-3 Master with installed Bugfix
Install S4 Connector (Important: Installation HAS to commence AFTER the installation of the bugfix)
