Unable to connect windows clients to AD DC

shardless · May 30, 2017, 8:33pm

Sorry if there is a topic on this already I tried to find one and couldn’t, but since I don’t speak or read German it’s possible I may have missed it.

I have installed UCS in two environments, one in a VM lab with a virtualized network, and the other in a real world lab. In both cases I am unable to connect any client to the Active Directory. I have used windows 7 and 10 to attempt this.

I have checked as best I know how and I believe samba is installed and correctly configured, my DNS records all seem to be resolving properly, and the DNS in UCS seems to have all the proper entries IE: master controller. but when I connect I get the message stating that no AD DC can be contacted.

I have installed a new UCS in the VM environment and I was able to link that install as a slave and connect to the AD just fine, but I am unable to do so from any windows device.

I ran a port Query in the VM environment and got these results which look okay to me but I am unsure.

=============================================

 Starting portqry.exe -n 192.168.1.101 -e 135 -p TCP ...


Querying target system called:

 192.168.1.101

Attempting to resolve IP address to a name...


IP address resolved to test-company.columbiarivertech.com

querying...

TCP port 135 (epmap service): LISTENING

Using ephemeral source port
Querying Endpoint Mapper Database...
Server's response:

UUID: 50abc2a4-574d-40b3-9d66-ee4fd5fba076 dnsserver
ncacn_np:192.168.1.101[\\pipe\\dnsserver]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_np:192.168.1.101[\\pipe\\dnsserver]

UUID: 3dde7c30-165d-11d1-ab8f-00805f14db40 backupkey
ncacn_np:192.168.1.101[\\pipe\\ntsvcs]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_np:192.168.1.101[\\pipe\\ntsvcs]

UUID: 6bffd098-a112-3610-9833-012892020162 browser
ncacn_np:192.168.1.101[\\pipe\\browser]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_np:192.168.1.101[\\pipe\\browser]

UUID: 9c54e310-a955-4885-bd31-78787147dfa6 unixinfo
ncacn_np:192.168.1.101[\\pipe\\unixinfo]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_np:192.168.1.101[\\pipe\\unixinfo]

UUID: 3dde7c30-165d-11d1-ab8f-00805f14db40 backupkey
ncacn_np:192.168.1.101[\\pipe\\protected_storage]

UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 drsuapi
ncacn_np:192.168.1.101[\\pipe\\protected_storage]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_np:192.168.1.101[\\pipe\\protected_storage]

UUID: 3919286a-b10c-11d0-9ba8-00c04fd92ef5 dssetup
ncacn_np:192.168.1.101[\\pipe\\lsass]

UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 drsuapi
ncacn_np:192.168.1.101[\\pipe\\lsass]

UUID: 12345778-1234-abcd-ef00-0123456789ab lsarpc
ncacn_np:192.168.1.101[\\pipe\\lsass]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_np:192.168.1.101[\\pipe\\lsass]

UUID: 3919286a-b10c-11d0-9ba8-00c04fd92ef5 dssetup
ncacn_np:192.168.1.101[\\pipe\\lsarpc]

UUID: 12345778-1234-abcd-ef00-0123456789ab lsarpc
ncacn_np:192.168.1.101[\\pipe\\lsarpc]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_np:192.168.1.101[\\pipe\\lsarpc]

UUID: 50abc2a4-574d-40b3-9d66-ee4fd5fba076 dnsserver
ncacn_ip_tcp:192.168.1.101[1024]

UUID: 3dde7c30-165d-11d1-ab8f-00805f14db40 backupkey
ncacn_ip_tcp:192.168.1.101[1024]

UUID: f6beaff7-1e19-4fbb-9f8f-b89e2018337c eventlog6
ncacn_ip_tcp:192.168.1.101[1024]

UUID: 6bffd098-a112-3610-9833-012892020162 browser
ncacn_ip_tcp:192.168.1.101[1024]

UUID: 9c54e310-a955-4885-bd31-78787147dfa6 unixinfo
ncacn_ip_tcp:192.168.1.101[1024]

UUID: 3919286a-b10c-11d0-9ba8-00c04fd92ef5 dssetup
ncacn_ip_tcp:192.168.1.101[1024]

UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 drsuapi
ncacn_ip_tcp:192.168.1.101[1024]

UUID: 12345778-1234-abcd-ef00-0123456789ab lsarpc
ncacn_ip_tcp:192.168.1.101[1024]

UUID: 12345678-1234-abcd-ef00-01234567cffb netlogon
ncacn_ip_tcp:192.168.1.101[1024]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_ip_tcp:192.168.1.101[1024]

UUID: 12345678-1234-abcd-ef00-01234567cffb netlogon
ncacn_np:192.168.1.101[\\pipe\\netlogon]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_np:192.168.1.101[\\pipe\\netlogon]

UUID: 12345778-1234-abcd-ef00-0123456789ac samr
ncacn_np:192.168.1.101[\\pipe\\samr]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_np:192.168.1.101[\\pipe\\samr]

UUID: 60a15ec5-4de8-11d7-a637-005056a20182 rpcecho
ncacn_np:192.168.1.101[\\pipe\\rpcecho]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_np:192.168.1.101[\\pipe\\rpcecho]

UUID: 12345778-1234-abcd-ef00-0123456789ac samr
ncacn_ip_tcp:192.168.1.101[1025]

UUID: 60a15ec5-4de8-11d7-a637-005056a20182 rpcecho
ncacn_ip_tcp:192.168.1.101[1025]

UUID: 6bffd098-a112-3610-9833-46c3f87e345a wkssvc
ncacn_ip_tcp:192.168.1.101[1025]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_ip_tcp:192.168.1.101[1025]

UUID: 6bffd098-a112-3610-9833-46c3f87e345a wkssvc
ncacn_np:192.168.1.101[\\pipe\\wkssvc]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_np:192.168.1.101[\\pipe\\wkssvc]

UUID: e1af8308-5d1f-11c9-91a4-08002b14a0fa epmapper
ncacn_http:192.168.1.101[593]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_http:192.168.1.101[593]

UUID: e1af8308-5d1f-11c9-91a4-08002b14a0fa epmapper
ncacn_ip_tcp:192.168.1.101[135]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_ip_tcp:192.168.1.101[135]

UUID: e1af8308-5d1f-11c9-91a4-08002b14a0fa epmapper
ncacn_np:192.168.1.101[\\pipe\\epmapper]

UUID: afa8bd80-7d8a-11c9-bef4-08002b102989 mgmt
ncacn_np:192.168.1.101[\\pipe\\epmapper]

Total endpoints found: 46



==== End of RPC Endpoint Mapper query response ====
portqry.exe -n 192.168.1.101 -e 135 -p TCP exits with return code 0x00000000.
=============================================

 Starting portqry.exe -n 192.168.1.101 -e 389 -p BOTH ...


Querying target system called:

 192.168.1.101

Attempting to resolve IP address to a name...


IP address resolved to test-company.columbiarivertech.com

querying...

TCP port 389 (ldap service): LISTENING

Using ephemeral source port
Sending LDAP query to TCP port 389...

LDAP query response:

configurationNamingContext: CN=Configuration,DC=columbiarivertech,DC=com
defaultNamingContext: DC=columbiarivertech,DC=com
rootDomainNamingContext: DC=columbiarivertech,DC=com
schemaNamingContext: CN=Schema,CN=Configuration,DC=columbiarivertech,DC=com
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=columbiarivertech,DC=com
supportedCapabilities: 1.2.840.113556.1.4.800
supportedLDAPVersion: 2
vendorName: Samba Team (https://www.samba.org)
isSynchronized: TRUE
dsServiceName: CN=NTDS Settings,CN=TEST-COMPANY,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=columbiarivertech,DC=com
serverName: CN=TEST-COMPANY,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=columbiarivertech,DC=com
dnsHostName: test-company.columbiarivertech.com
ldapServiceName: columbiarivertech.com:test-company$@COLUMBIARIVERTECH.COM

currentdate: 04/22/2017 17:07:38 (unadjusted GMT)
supportedControl: 1.2.840.113556.1.4.528
namingContexts: DC=columbiarivertech,DC=com
supportedSASLMechanisms: GSS-SPNEGO
highestCommittedUSN: 3869
domainFunctionality: 4
forestFunctionality: 4
domainControllerFunctionality: 4
isGlobalCatalogReady: TRUE


======== End of LDAP query response ========

UDP port 389 (unknown service): LISTENING or FILTERED

Using ephemeral source port
Sending LDAP query to UDP port 389...

LDAP query response:

configurationNamingContext: CN=Configuration,DC=columbiarivertech,DC=com
defaultNamingContext: DC=columbiarivertech,DC=com
rootDomainNamingContext: DC=columbiarivertech,DC=com
schemaNamingContext: CN=Schema,CN=Configuration,DC=columbiarivertech,DC=com
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=columbiarivertech,DC=com
supportedCapabilities: 1.2.840.113556.1.4.800
supportedLDAPVersion: 2
vendorName: Samba Team (https://www.samba.org)
isSynchronized: TRUE
dsServiceName: CN=NTDS Settings,CN=TEST-COMPANY,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=columbiarivertech,DC=com
serverName: CN=TEST-COMPANY,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=columbiarivertech,DC=com
dnsHostName: test-company.columbiarivertech.com
ldapServiceName: columbiarivertech.com:test-company$@COLUMBIARIVERTECH.COM

currentdate: 04/22/2017 17:07:41 (unadjusted GMT)
supportedControl: 1.2.840.113556.1.4.528
namingContexts: DC=columbiarivertech,DC=com
highestCommittedUSN: 3869
domainFunctionality: 4
forestFunctionality: 4
domainControllerFunctionality: 4
isGlobalCatalogReady: TRUE


======== End of LDAP query response ========

UDP port 389 is LISTENING

portqry.exe -n 192.168.1.101 -e 389 -p BOTH exits with return code 0x00000000.
=============================================

 Starting portqry.exe -n 192.168.1.101 -e 636 -p TCP ...


Querying target system called:

 192.168.1.101

Attempting to resolve IP address to a name...


IP address resolved to test-company.columbiarivertech.com

I also ran a port query in the real world lab and got different results, and as far as I know the installs are identical save for the FQDN.

=============================================

 Starting portqry.exe -n 192.168.1.127 -e 135 -p TCP ...


Querying target system called:

 192.168.1.127

Attempting to resolve IP address to a name...


IP address resolved to JEDI

querying...

TCP port 135 (epmap service): FILTERED
portqry.exe -n 192.168.1.127 -e 135 -p TCP exits with return code 0x00000002.
=============================================

 Starting portqry.exe -n 192.168.1.127 -e 389 -p BOTH ...


Querying target system called:

 192.168.1.127

Attempting to resolve IP address to a name...


IP address resolved to JEDI

querying...

TCP port 389 (ldap service): LISTENING

Using ephemeral source port
Sending LDAP query to TCP port 389...

LDAP query response:

objectClass: top


======== End of LDAP query response ========

UDP port 389 (unknown service): LISTENING or FILTERED

Using ephemeral source port
Sending LDAP query to UDP port 389...

LDAP query to port 389 failed
Server did not respond to LDAP query

portqry.exe -n 192.168.1.127 -e 389 -p BOTH exits with return code 0x00000001.
=============================================

 Starting portqry.exe -n 192.168.1.127 -e 636 -p TCP ...


Querying target system called:

 192.168.1.127

Attempting to resolve IP address to a name...


IP address resolved to JEDI

querying...

TCP port 636 (ldaps service): LISTENING
portqry.exe -n 192.168.1.127 -e 636 -p TCP exits with return code 0x00000000.
=============================================

 Starting portqry.exe -n 192.168.1.127 -e 3268 -p TCP ...


Querying target system called:

 192.168.1.127

Attempting to resolve IP address to a name...


IP address resolved to JEDI

querying...

TCP port 3268 (msft-gc service): FILTERED
portqry.exe -n 192.168.1.127 -e 3268 -p TCP exits with return code 0x00000002.
=============================================

 Starting portqry.exe -n 192.168.1.127 -e 3269 -p TCP ...


Querying target system called:

 192.168.1.127

Attempting to resolve IP address to a name...


IP address resolved to JEDI

querying...

TCP port 3269 (msft-gc-ssl service): FILTERED
portqry.exe -n 192.168.1.127 -e 3269 -p TCP exits with return code 0x00000002.
=============================================

 Starting portqry.exe -n 192.168.1.127 -e 53 -p BOTH ...


Querying target system called:

 192.168.1.127

Attempting to resolve IP address to a name...


IP address resolved to JEDI

querying...

TCP port 53 (domain service): LISTENING

UDP port 53 (domain service): LISTENING
portqry.exe -n 192.168.1.127 -e 53 -p BOTH exits with return code 0x00000000.
=============================================

 Starting portqry.exe -n 192.168.1.127 -e 88 -p BOTH ...


Querying target system called:

 192.168.1.127

Attempting to resolve IP address to a name...


IP address resolved to JEDI

querying...

TCP port 88 (kerberos service): NOT LISTENING

UDP port 88 (kerberos service): LISTENING or FILTERED
portqry.exe -n 192.168.1.127 -e 88 -p BOTH exits with return code 0x00000002.
=============================================

 Starting portqry.exe -n 192.168.1.127 -e 445 -p TCP ...


Querying target system called:

 192.168.1.127

Attempting to resolve IP address to a name...


IP address resolved to JEDI

querying...

TCP port 445 (microsoft-ds service): LISTENING
portqry.exe -n 192.168.1.127 -e 445 -p TCP exits with return code 0x00000000.
=============================================

 Starting portqry.exe -n 192.168.1.127 -e 137 -p UDP ...

I have also tried to connect using Sysinternals AD explorer to troubleshoot the domains and it seems to find the AD but tells me that the Username and password are incorrect though I know for certain they are not. I even tried to create a test user to connect with in this way and received the same message.

I apologize for my lack of knowledge I have not worked with AD since Server 2003 was a released, so I am more than a bit rusty and I have zero experience with UCS outside of this setup so far.

Please help!

Grandjean · May 30, 2017, 9:47pm

Hello @shardless

welcome to Univention Help

I hope you don’t mind if we check this again Let’s get some basic info about your UCS installation:

Please log in to the UCS system on the command-line shell, either via ssh or the terminal, then execute:
- univention-app info to get some info about the UCS version and the installed apps
- univention-check-join-status to see if there are pending joinscripts

Please paste the results here.

Your port query seems to prove that Samba/AD is running on UCS (it finds AD LDAP-base, Functioning Levels, Global Catalog, the Default Site, etc.)

Can you show us the output of ipconfig /all on the Windows clients?
Any firewalling that could get in the way?
Can the Windows clients resolve these DNS records?

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

Best regards,
Michael Grandjean

shardless · May 31, 2017, 5:01pm

When trying to execute both of these commands in SSH it returns an error stating that they are not commands. Should I precede them with something?

Yes there is a firewall in the VM lab I am using I have pfsense set as the router and firewall on a virtual host network using virtualbox.

The Ipconfig results as well as about half the DNs resolution results are below: after so many failures I gave up on the rest, if you need them all I can complete the list.

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Users\Test>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : DESKTOP-0LIHSC1
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : test-company.columbiarivertech.com

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : test-company.columbiarivertech.com
   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Desktop Adapter
   Physical Address. . . . . . . . . : 08-00-27-49-AE-FA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::60c0:50e:cf5a:d1e8%3(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.1.102(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, May 29, 2017 7:22:00 PM
   Lease Expires . . . . . . . . . . : Tuesday, May 30, 2017 5:20:31 PM
   Default Gateway . . . . . . . . . : fe80::1:1%3
                                       192.168.1.1
   DHCP Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6 IAID . . . . . . . . . . . : 50855975
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-20-89-78-43-08-00-27-49-AE-FA
   DNS Servers . . . . . . . . . . . : 192.168.1.101
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:0:4137:9e76:3c79:89d0:b474:45af(Preferred)
   Link-local IPv6 Address . . . . . : fe80::3c79:89d0:b474:45af%2(Preferred)
   Default Gateway . . . . . . . . . : ::
   DHCPv6 IAID . . . . . . . . . . . : 134217728
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-20-89-78-43-08-00-27-49-AE-FA
   NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter isatap.test-company.columbiarivertech.com:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : test-company.columbiarivertech.com
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

C:\Users\Test>ping gc._msdcs.columbiarivertech.com

Pinging gc._msdcs.columbiarivertech.com [192.168.1.101] with 32 bytes of data:
Reply from 192.168.1.101: bytes=32 time<1ms TTL=64
Reply from 192.168.1.101: bytes=32 time<1ms TTL=64
Reply from 192.168.1.101: bytes=32 time<1ms TTL=64
Reply from 192.168.1.101: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.1.101:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\Test>ping _gc._tcp.columbiarivertech.com
Ping request could not find host _gc._tcp.columbiarivertech.com. Please check the name and try again.

C:\Users\Test>ping _ldap._tcp.gc._msdcs.columbiarivertech.com
Ping request could not find host _ldap._tcp.gc._msdcs.columbiarivertech.com. Please check the name and try again.

C:\Users\Test>ping _ldap._tcp.columbiarivertech.com
Ping request could not find host _ldap._tcp.columbiarivertech.com. Please check the name and try again.

C:\Users\Test>ping _ldap._tcp.dc._hsdcs.columbiarivertech.com
Ping request could not find host _ldap._tcp.dc._hsdcs.columbiarivertech.com. Please check the name and try again.

C:\Users\Test>ping _ldap._tcp.pdc._hsdcs.columbiarivertech.com
Ping request could not find host _ldap._tcp.pdc._hsdcs.columbiarivertech.com. Please check the name and try again.

C:\Users\Test>ping _kerberos._tcp.dc._msdcs.columbiarivertech.com
Ping request could not find host _kerberos._tcp.dc._msdcs.columbiarivertech.com. Please check the name and try again.

C:\Users\Test>ping _kerberos._tcp.columbiarivertech.com
Ping request could not find host _kerberos._tcp.columbiarivertech.com. Please check the name and try again.

C:\Users\Test>ping _kerberos._udp.columbiarivertech.com
Ping request could not find host _kerberos._udp.columbiarivertech.com. Please check the name and try again.

C:\Users\Test>ping _kpasswd._tcp.columbiarivertech.com
Ping request could not find host _kpasswd._tcp.columbiarivertech.com. Please check the name and try again.

C:\Users\Test>ping _kpasswd._udp.columbiarivertech.com
Ping request could not find host _kpasswd._udp.columbiarivertech.com. Please check the name and try again.

SirTux · May 31, 2017, 5:36pm

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

Is your DNS in general working?

nslookup test-company.columbiarivertech.com

shardless · May 31, 2017, 6:00pm

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

SirTux · May 31, 2017, 6:04pm

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.

Grandjean · May 31, 2017, 6:06pm

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

shardless · May 31, 2017, 6:08pm

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

Grandjean · May 31, 2017, 7:26pm

Okay, great 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.

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.
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.
Please check if you have any S4-Connector-Rejects:
univention-s4connector-list-rejected
Please try to update the relevant DNS entries via this samba command on the UCS:
samba_dnsupdate
Does this change anything?
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

shardless · May 31, 2017, 8:35pm

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?

Grandjean · May 31, 2017, 8:43pm

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

shardless · May 31, 2017, 8:44pm

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

shardless · May 31, 2017, 9:35pm

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"

Grandjean · May 31, 2017, 9:45pm

Thanks!

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

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)

shardless · May 31, 2017, 10:18pm

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.

thorp-hansen · June 1, 2017, 7:59am

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

Grandjean · June 1, 2017, 8:02am

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.

shardless · June 1, 2017, 5:14pm

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.

shardless · June 1, 2017, 5:35pm

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

shardless · June 1, 2017, 5:37pm

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?