Unable to connect windows clients to AD DC

Did you tried this as user “root” or as user “Administrator”?

Is your DNS in general working?

nslookup test-company.columbiarivertech.com

I was attempting it as Administrator, should I do it as root?

The nslookup seems to return normal results. It is sending back a local IP though.

C:\Users\Test>nslookup test-company.columbiarivertech.com
Server:  test-company.columbiarivertech.com
Address:  192.168.1.101

Name:    test-company.columbiarivertech.com
Address:  192.168.1.101

Yes you should.

That is good. Your DNS is not broken. The question is now why the service records above are missing. But first please provide the output of mentioned commands.

Sorry, I was not precise enough :disappointed_relieved:
Either use root or use Administrator and prepend sudo before the commands.

I got it to work. This is from the VM lab, as have been all the other results I have provided. I want to point out again that I have the same perceived issues in the test bench with physical machines as well. In the test bench envirionment there is no pfSense firewall, just a simple asus router.

root@test-company:~# univention-app info
UCS: 4.2-0 errata1
App Center compatibility: 4
Installed: adconnector=11.0 adtakeover=4.0.0 cups=1.7.5 dhcp-server=11.0.0 fetchmail=6.3.26 kde=4 kvm=1.2.8 mailserver=11 nagios=3.5 pkgdb=10 printquota=9.0 radius=4.0 samba4=4.6 self-service=2.0 squid=3.4 uvmm=6
Upgradable:
root@test-company:~# univention-check-join-status
Joined successfully

Okay, great :slight_smile: That looks as expected.

Now, how should we proceed 
 I think it’s necessary to determine if this is a problem of UCS itself or maybe caused by a networking/firewall issue.

  1. I recommend to update the UCS system to the latest Errata-Level (26). That won’t solve your problem, but Errata 18 contains a critical security fix for Samba.
  2. Is the pfSense “between” the Windows client and the UCS? If so, please double check your firewall config. I’ve seen UDP packets denied but TCP packets allowed for DNS (port 53), leading to similiar strange responses.
  3. Please check if you have any S4-Connector-Rejects:
    univention-s4connector-list-rejected
  4. Please try to update the relevant DNS entries via this samba command on the UCS:
    samba_dnsupdate
    Does this change anything?
  5. Try to check the DNS records directly on the UCS. I’ll attach a patched version of a script that will do this (the version delivered with UCS 4.2 has a little flaw causing it to fail, unfortunately. Fix is on the way).
    → copy the attached check_essential_samba4_dns_records.txt to your UCS (using scp or something like WinSCP or downloading it via the direct link with a commandline tool like wget or curl)
    → rename it: mv check_essential_samba4_dns_records.txt check_essential_samba4_dns_records.sh
    → make it executable: chmod +x check_essential_samba4_dns_records.sh
    → execute it: ./check_essential_samba4_dns_records.sh
    → copy&paste the output

Will do

The pfSense is not between the two as far as I follow, It is acting as the router, DHCP, and a DNS but it is not ‘between’ them they are both within the same subnet provided by the pfSense device.

root@test-company:~# 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: 3869

I get no return when executing this command it just returns to the prompt.

I don’t see any attachments, am I missing something?

Nah, sorry, that got lost somewhere. Trying again:
check_essential_samba4_dns_records.txt (3.7 KB)

Thanks, I will get on that. I am juggling many projects so bear with me please.

root@test-company:~# ./check_essential_samba4_dns_records.sh
gc._msdcs.columbiarivertech.com has address 192.168.1.101
_gc._tcp.columbiarivertech.com has SRV record 0 100 3268 test-company.columbiarivertech.com.
_ldap._tcp.gc._msdcs.columbiarivertech.com has SRV record 0 100 3268 test-company.columbiarivertech.com.
_ldap._tcp.columbiarivertech.com has SRV record 0 100 389 test-company.columbiarivertech.com.
_ldap._tcp.dc._msdcs.columbiarivertech.com has SRV record 0 100 389 test-company.columbiarivertech.com.
_ldap._tcp.pdc._msdcs.columbiarivertech.com has SRV record 0 100 389 test-company.columbiarivertech.com.
_ldap._tcp.359fc8c5-f8d6-4fde-981a-f995a183c7bb.domains._msdcs.columbiarivertech.com has SRV record 0 100 389 test-company.columbiarivertech.com.
_kerberos._tcp.dc._msdcs.columbiarivertech.com has SRV record 0 100 88 test-company.columbiarivertech.com.
_kerberos._tcp.columbiarivertech.com has SRV record 0 100 88 test-company.columbiarivertech.com.
_kerberos._udp.columbiarivertech.com has SRV record 0 100 88 test-company.columbiarivertech.com.
_kpasswd._tcp.columbiarivertech.com has SRV record 0 100 464 test-company.columbiarivertech.com.
_kpasswd._udp.columbiarivertech.com has SRV record 0 100 464 test-company.columbiarivertech.com.
Located DC 'test-company' in site 'Default-First-Site-Name'
74bd0c78-67a5-4ec9-ae5e-4bfec0cf03ae._msdcs.columbiarivertech.com is an alias for test-company.columbiarivertech.com.
## Records for site Default-First-Site-Name:
_ldap._tcp.Default-First-Site-Name._sites.columbiarivertech.com has SRV record 0 100 389 test-company.columbiarivertech.com.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.columbiarivertech.com has SRV record 0 100 389 test-company.columbiarivertech.com.
_kerberos._tcp.Default-First-Site-Name._sites.columbiarivertech.com has SRV record 0 100 88 test-company.columbiarivertech.com.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.columbiarivertech.com has SRV record 0 100 88 test-company.columbiarivertech.com.
## Optional GC Records for site Default-First-Site-Name:
_gc._tcp.Default-First-Site-Name._sites.columbiarivertech.com has SRV record 0 100 3268 test-company.columbiarivertech.com.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.columbiarivertech.com has SRV record 0 100 3268 test-company.columbiarivertech.com.
_kerberos.columbiarivertech.com descriptive text "COLUMBIARIVERTECH.COM"

Thanks!

So, this looks fine, too. The UCS system itself is able to resolve all the relevant DNS records. :heavy_check_mark:
But the Windows client is not. :x:
:thinking:

Just to get this straight:

  • 192.168.1.101 is the IP address of your UCS system called test-company.columbiarivertech.com
  • the Windows client has 192.168.1.102 obtained via DHCP from 192.168.1.1
  • 192.168.1.1 is the pfSense (I guess) that is used as default gateway and DHCP server for the Windows client
  • 192.168.1.101 (which is the UCS system) is used as DNS server for the Windows clients

Is this correct?
(The Windows clients need to use the UCS system as DNS server to be able to resolve all the relevant records)

That is all correct I have also set the pfsense to use the DNS from UCS as well. Though pfSense has it’s own DNS forwarder and zone editor for the local network routing I have just assigned it the address for the UCS.

As I mentioned in the OP as well I am able to connect another UCS install to the master controller just fine, and slave it. I have yet to try with a different OS beyond WIndows 7 and 10.

I can’t honestly understand what could be wrong as you can see everything seems to resolve correctly. as long as it’s not in windows.

Is that working when the DNS Backend is set to LDAP?

ucr set dns/backend='ldap'

Can you restart the Bind and send the syslog entries from the Bindrestart (I want to see if all zones are present and nothing is “ignored”)?

service bind9 restart

Yes, I’m puzzled, too. I just installed a fresh UCS 4.2, added the Apps “Active Directory compatible Domaincontroller” and “DHCP server” and named it just like your system (test-company.columbiarivertech.com) - just wanted to rule out the possibility that the name might be too long or that the client gets confused with the internet domain columbiarivertech.com

I usually recommend to use something different than the external internet domain name for the internal domain name. I’d go with a subdomain, because I can then control that this subdomain will only be resolvable internally and never externally (e.g. something like “intern.columbiarivertech.com” for the domain name and “ucs01.intern.columbiarivertech.com” as FQDN for the server).

But I was able to join a Windows 10 client without any problems. The Legacy/Netbios-Domain name gets shortened automatically to “COLUMBIARIVERTE” (we have a 15 character limit here), but it works nevertheless.

This also means, that it definately should work - we just have to find the reason why it’s not working for you.

I can definitely do this as you suggest, but doesn’t a FQDN have to be ARIN registered to work properly, or is that a misconception I have? I have never used one that wasn’t just as a matter of coincidence.

I will do this as soon as I have time, and post results.

root@test-company:~# ucr set dns/backend='ldap'
Setting dns/backend
root@test-company:~# service bind9 restart
root@test-company:~#

When I installed it the only thing I left out was the KDE environment, could there be some ‘app’ or other module that could be causing the problem?

Hm, never say never, but I think that’s very unlikely.

Personally, I would proceed with analyzing the network traffic with tcpdump and Wireshark at this point.

I will do that, I am going to clean up the environment a bit and do as you did and just install the apps I need leaving out everything else and see if that helps as well.

So I have had a chance to get back to this issue and I have reinstalled UCS on a fresh VM this time in a xenserver cluster environment, and I am having a similar issue. It looks as if the domain itself is resolving and the port query shows that UCS is listening in all the correct ports, but it is still unable to connect using a windows machine. I am able to get all the following to resolve using nslookup on the windows machine:

gc._msdcs.columbiarivertech.com
_gc._tcp.columbiarivertech.com
_ldap._tcp.gc._msdcs.columbiarivertech.com
_ldap._tcp.columbiarivertech.com
_ldap._tcp.dc._msdcs.columbiarivertech.com
_ldap._tcp.pdc._msdcs.columbiarivertech.com
_kerberos._tcp.dc._msdcs.columbiarivertech.com
_kerberos._tcp.columbiarivertech.com
_kerberos._udp.columbiarivertech.com
_kpasswd._tcp.columbiarivertech.com
_kpasswd._udp.columbiarivertech.com
_ldap._tcp.Default-First-Site-Name._sites.columbiarivertech.com
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.columbiarivertech.com
_kerberos._tcp.Default-First-Site-Name._sites.columbiarivertech.com
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.columbiarivertech.com
_gc._tcp.Default-First-Site-Name._sites.columbiarivertech.com
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.columbiarivertech.com
_kerberos.columbiarivertech.com

I have also been able to connect to UCS through the network and sharing center, but not though the domain setting in advanced system settings.

Is there an additioonal application I need to install on the windows environment in order to connect to the domain? It seems as if the Smb shares are all working since I can connect to them. It just seems to be the AD/DC that I am unable to connect to.

I have also tried to connect to the machine using Freenas and was unable to join the domain using that OS either.

I have tried to connect using ADExplorer as well and was unable to connect, this lead me to check the services in the web admin panel for UCS and I realized that the AD/DC is not running. When I try to start it it says it has started successfully, but it remains with a status of stopped. Though I am suspicious that this is not the DOmain COntroller but just the connector for integrating into existing AD evironments, is that correct?

Mastodon