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?
I went digging through the LDAP objects trying to figure out if there were any Domain controllers listed and there are not any there. Though when I try to add one with the IP of the UCS installation it says that the IP is already in use.
Hi,
I just skimmed through your last two posts - do you have the App “Active Directory Domain Controller” installed? That is what you need to provide Active Directory Services with UCS. The “univention-ad-connector” is something different (https://docs.software-univention.de/manual-4.2.html#ad-connector:general). In the “System Services” module you need to look for “samba” related daemons, since Samba provides the Active Directory Domain Services.
Please run univention-app info on the commandline and paste the output here.
univention-app: error: too few arguments
Administrator@ucs:~$ univention-app info
UCS: 4.2-1 errata52
App Center compatibility: 4
Installed: adconnector=11.0 adtakeover=4.0.0 cups=1.7.5 dhcp-server=11.0.0 fetch mail=6.3.26 kde=4 kvm=1.2.8 mailserver=11 nagios=3.5 pkgdb=10 printquota=9.0 rad ius=4.0 samba4=4.6 self-service=2.0 squid=3.4 uvmm=6
Upgradable:
Here is my installed apps page as well:
The only Samba related thing I see is Samba4 and it is running. I am also able to connect to the Samba shares, or what I assume is them using the network and sharing center.
Hi,
for me it looks strange that you’ve installed AD-take over and AD-connection - when you are installing UCS you only need AD compatible DC module. the others are only needed if you connect to an existing Windows AD (AD-connection) or you migrate an existing Windows AD to UCS (AD Takeover)
Maybe you now have a problem with AD.connection module installed
rg
Christian
Hey Christian:
Are you saying that it only works with one or the other but not both? I assumed the AD takeover was just a tool to allow the migration of existing infrastructure, is that not the case?
Thanks,
I have done some more digging and decided to look at the windows logs I have found this:
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 “ucs.columbiarivertech.intranet”:
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.ucs.columbiarivertech.intranet
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.187
- One or more of the following zones do not include delegation to its child zone:
ucs.columbiarivertech.intranet
columbiarivertech.intranet
intranet
. (the root zone)
I have also checked in NSlookup and it actually looks like I am unable to resolve this adress.
Though I can resolve _ldap._tcp.dc._msdcs.columbiarivertech.intranet
No, as long as you only install the apps without configuring them it should not be a problem, but you don’t need them if you’re not migrating from or connectiong to an already existing Microsoft AD
for Samba AD function you only need the Windows compatible DC App which builds the AD from your LDAP.
I would remove all three apps (AD Connection, AD takeover and AD compatible DC) and then only reinstall Active Directory compatible DC
rg
Christian
I think I have got the issue resolved. I was able to connect to the domain controller. I had to remove the subdomain portion of my FQDN to get it to connect though. Which seems strange to me. Why is it that it would not work with the sub domain?
same here, present in webgui, not in nslookup