is that a new UCS setup? I am asking, because you have “domain bebconsultingservices.com” in the resolv.conf which results to “BEBCONSULTINGSE(rvices.com)” in windows/domain.
Did you use the instructions in the documentation regarding the AD-Membermode? http://docs.software-univention.de/manual-4.1.html#ad-connector:ad-member-einrichtung:
I would also have a look at the nameserver-variables and set only the AD master as nameserver1 (dropping the rest):
[code]# ucr set nameserver1=
Yes this is a NEW UCS Install in an EXISTING Windows 2012/2008 Domain called FQDN “bebconsultingservices.com” or in NetBIOS “BEBCONSULTING”
I followed the instructions for AD Connector docs.software-univention.de/manu … inrichtung: and it fails with the error in this thread. No matter which option I use.
The FQDN for the UCS is bebucsmtasvrp5.bebconsultingservices.com. the FQDN for the Windows domain server is bebw12mtasvrp1.bebconsultingservices.com and the backup Windows domain is bebw12mtasvrp2.bebconsultingservices.com.
I’m trying to get the UCS installed as a member of the Windows 2012/2008 domain so that users of the UCS can access the resources/application on the Windows Domain and users of the Windows Domain can access resources/applications on the UCS Domain. Ideally both having the FQDN Windows domain of “bebconsultingservices.com” and using NETBIOS as BEBCONSULTING.
I just installed a Windows Server 2012 with a name like yours and the domain “bebconsultingservice.com” - as netbiosname (Pre-Windows 2000) I configured “bebconsulting”.
I then installed a new 4.1-4. At the IP Konfiguration I chose an IP and set the DNS Server to the AD Server.
I then chose to “install in existing AD Domain” - the setup then did a lookup for the AD server and presented me with: “bebw12mtasvrp1.bebconsultingservices.com” as server to join to.
I set AD Administrator and Password and at the name configuration I just set “bebucsmtasvrp5” as local name.
The setup then asked which apps to install and I chose “Active Directory Connection”.
Afterwards, the installation started and finished without errors.
I get this at the UCS Server:
root@bebucsmtasvrp5:~# ucr search windows/domain
windows/domain: BEBCONSULTING
The NetBIOS domain name (used in Samba 3, Samba 4 predominantly uses the DNS/Kerberos domainname).
This seems to work fine - can you check if you did something different or tell if you encountered errors along the way?
The only thing I have done different was set the UCS DNS #1 to itself (64.111.20.203) and the Windows AD (104.153.46.198) as the External DNS #1.
I also set the UCS local name to the FQDN (bebucsmtasvrp5.bebconsultingservices.com) as when I use just “bebucsmtasvrp5” the UCS server can’t resolve itself. nslookup fails with just “bebucsmtasvrp5: but works fine with"bebucsmtasvrp5.bebconsultingservices.com” when resolving the hostname .
When I select to install app and select “Active Directory Connection” it starts but then fails stating that it can not join because of the error “Could not connect to AD Server BEBW12MTASVRP1.bebconsultingservices.com. Please verify that username and password are correct”
Then it give me the option of “Back” or “Reboot”
I just tried again with a new host name, following the process you listed. It still fails with Connection Refused.
The Domain is set as a Windows 2003 Domain Level for the Domain and Forest.
The password and user are correct being used.
Hi,
is it possible to try the process exactly as I mentioned and tell the results?
Afterwards, check the following:
root@bebucsmtasvrp5:~# ucr search windows/domain
windows/domain: BEBCONSULTING
The NetBIOS domain name (used in Samba 3, Samba 4 predominantly uses the DNS/Kerberos domainname).
Tell me where your experience in the process differs from my lab-test.
Kind Regards,
Jens Thorp-Hansen
Will try this morning…stay tuned…
Just attempted it again…It fails with " Connection Refused" followed these steps exactly.
Install a new 4.1-4
I have a AVI video of the process, not able upload here however.But screen shot is attached of the Error.
I have tried to reset the password to something more simple. Still fails with connection refused.
I also checked and 104.153.46.198 does resolve to “bebw12mtasvrp1.bebconsultingservices.com”. I am wondering if it might be a Windows AD firewall issue. Not sure what ports UCS needs open to join a AD Domain.
In order to maintain our production schedule we are moving forward with the UCS Master rebuild as we can’t delay any longer with reinstalling over and over. We will need to attempt to install AD Connector with a system that is build as a Dedicated UCS Master in parallel to a Window Domain. As rebuilding this over and over wipes out our applications and data that we have to restore.
Also checked the firewall on the AD Domain Controller open ports are:
LDAP TCP-in - 389
LDAP UDP in - 389
LDAP for Global Catalog TCP in - 3268
NetBIOS name Resolution UDP in - 138
SAM/LSA TCP in - 445
SAM/LSA UDP in - 445
Secure LDAP TCP in - 636
Secure LDAP for Global Catalog TCP in - 3269
W32Time NTP UDP in - 123
RPC - RPC Dynamic
RPC Endpoint Mapper
DNS - TCP and UDP 53
Kerberos V5 UDP in - 88
Netbios Datagram UDP in - 137
Just attempted again, this time setting up a new UCS Domain.
Then install AD Connector (installed and no errors) and selected “Configure UCS as part of an Active Directory domain (recommended).” as the option.
when attempting to join the windows domain I get the error:
Could not fulfill the request.
Server error message:
The command has failed: Could not connect to AD Server BEBW12MTASVRP1.bebconsultingservices.com. Please verify that username and password are correct.
Same as before…going to try to select “Synchronisation of account data between an Active Directory and this UCS domain.” Option and see what the result is…
Well that option also fails with
Could not fulfill the request.
Server error message:
The command has failed: Could not connect to AD Server BEBW12MTASVRP1.bebconsultingservices.com. Please verify that username and password are correct.
On the newly rebuilt UCS Master, it appears that even though I have the AD Server as the DNS it still is not able to resolve…
root@bebucsmtasvrp5:/var/log/univention# nslookup bebw12mtasvrp1.bebconsultingservices.com
Server: 64.111.20.203
Address: 64.111.20.203#53
** server can’t find bebw12mtasvrp1.bebconsultingservices.com: NXDOMAIN
even though the first DNS is itself (put there during the install automatically) and it has the second DNS as 104.153.46.198 which is the IP Address for bebw12mtasvrp1.bebconsultingservices.com. It does not resolve…
I’ve managed to get DNS name resolution to work. However the connection is still refused.
I am also seeing that the NETBIOS and FQDN are now correct in AD Connector:
28.11.16 13:35:02.905 MODULE ( PROCESS ) : AD Info: {‘Domain’: ‘bebconsultingservices.com’, ‘LDAP Base’: DC=bebconsultingservices,DC=com’, ‘Forest’: ‘bebconsultingservices.com’, ‘Client Site’: ‘Default-First-Site-Name’, ‘DC Netbios Name’: ‘BEBW12MTASVRP1’, ‘DC DNS Name’: ‘BEBW12MTASVRP1.bebconsultingservices.com’, ‘Netbios Domain’: 'BEBCONSULTING’, ‘DC IP’: ‘104.153.46.198’, ‘Server Site’: ‘Default-First-Site-Name’}
28.11.16 13:35:03.013 MODULE ( WARN ) : Failure:
28.11.16 13:35:03.013 MODULE ( PROCESS ) : The command has failed: Could not connect to AD Server BEBW12MTASVRP1.bebconsultingservices.com. Please verify that username and password are correct.
But the connection is still being refused…now I am at a loss…
Do I need to also have Active Directory-compatible Domain Controller installed as well? As currently it is NOT installed only Active Directory Connection is installed.
No, you do not need the Active Directory Domain Controller. The step-by-step instructions I sent are verified in a lab-environment so there must be something in your environment, that is causing the fails. Maybe the network environment? Configuration of the Windows Server, that activly hinders the connection?
Further:
Maybe a routing issue?
I am really sorry, but can it not be that you use an Administrator that is either not allowed to do the join/connect? Or that the password has a typo or the likes? I mean: If the system at the point “Give User/Password” tells you the typed in user/passwort is wrong.
Ok it does look like a possible routing issue…
Going from the UCS to the Windows AD Server:
From MTA 5 to MTA 1
root@bebucsmtasvrp5:~# traceroute bebw12mtasvrp1.bebconsultingservices.com
traceroute to bebw12mtasvrp1.bebconsultingservices.com (104.153.46.198), 30 hops max, 60 byte packets
1 64.111.20.201 (64.111.20.201) 0.643 ms 0.635 ms 0.845 ms
2 vs201.cor1.cos1.vis.data102.com (64.111.16.192) 0.592 ms 0.606 ms 0.608 m s
3 g0-1.edge3.cos1.vis.data102.com (64.111.16.219) 1.279 ms 1.280 ms 1.280 m s
4 gi0-0-0-0.rcr11.cos01.atlas.cogentco.com (38.101.50.117) 1.273 ms 1.526 ms 1.527 ms
5 te0-7-0-8.ccr22.den01.atlas.cogentco.com (154.54.40.18) 3.221 ms 3.233 ms 3.229 ms
6 be3036.ccr22.mci01.atlas.cogentco.com (154.54.31.90) 14.634 ms 14.676 ms 14.681 ms
7 be2832.ccr42.ord01.atlas.cogentco.com (154.54.44.170) 26.438 ms 26.450 ms 26.447 ms
8 be2718.ccr22.cle04.atlas.cogentco.com (154.54.7.130) 33.332 ms 33.226 ms 33.505 ms
9 be2890.ccr42.jfk02.atlas.cogentco.com (154.54.82.246) 45.027 ms 45.441 ms 45.441 ms
10 be2855.ccr22.jfk04.atlas.cogentco.com (154.54.7.6) 45.415 ms 45.428 ms 45.926 ms
11 38.88.134.18 (38.88.134.18) 46.228 ms 46.777 ms 46.788 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
root@bebucsmtasvrp5:~#
Going from the Windows AD Server to UCS…
From MTA 1 to MTA 5
Tracing route to bebucsmtasvrp5.bebconsultingservices.com [64.111.20.203]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 199.231.92.1
2 1 ms 1 ms 1 ms 38.88.134.17
3 1 ms 1 ms 2 ms be2855.ccr42.jfk02.atlas.cogentco.com [154.54.7.5]
4 13 ms 13 ms 13 ms be2890.ccr22.cle04.atlas.cogentco.com [154.54.82.245]
5 21 ms 21 ms 21 ms be2718.ccr42.ord01.atlas.cogentco.com [154.54.7.129]
6 33 ms 33 ms 33 ms be2832.ccr22.mci01.atlas.cogentco.com [154.54.44.169]
7 44 ms 44 ms 44 ms be3036.ccr22.den01.atlas.cogentco.com [154.54.31.89]
8 46 ms 46 ms 46 ms te0-0-2-2.rcr11.cos01.atlas.cogentco.com [154.54.40.17]
9 46 ms 46 ms 58 ms Optimum_Network_Services.demarc.cogentco.com [38.101.50.118]
10 46 ms 46 ms 46 ms g7-10.core1.cos1.vis.data102.com [64.111.16.218]
11 46 ms 46 ms 46 ms vs201.dist3.cos1.vis.data102.com [64.111.16.193]
12 46 ms 48 ms 46 ms 64.111.20.203
Trace complete.
So I think I will open a case with the ISP/Co-Location for UCS.
Thanks…I will update again if we have more issues…or something else.
The password has been reset twice to a very simple password. It is so simple there is no way it could be type wrong. We even disabled password complexity.
We changed the password to “Icantgetin” (it is no longer that password…LOL) and it still FAILS.
I think it might be something with routing as the trace routes don’t look right from UCS to Windows, but Windows to UCS is OK.
Well we have had ISPs at both ends check the routing, that is GOOD.
We also opened ALL AD required firewall ports in Windows Firewall
DNS resolves correctly.
There is no firewall at the ISP ends blocking traffic.
The password for Administrator has been reset multiple times. Plus has been simplified.
We have other servers join the AD Domain without issues. This is the ONLY server that seems to have this problem.
Could it be the way the password/user is encrypted on the UCS side and sent to the AD side, in a way the AD side does not understand? As the password is TYPED correctly, we even cut and pasted it to prevent typos.
I am not sure if the Free Core Edition has formal support with Univention or not but this is starting to look like some sort of bug somewhere. There is nothing on the AD side that should be blocking this, other than the password being hashed in a way that is incompatible with Windows 2012 AD.
[quote=“BrianBonnell”]
I am not sure if the Free Core Edition has formal support with Univention or not but this is starting to look like some sort of bug somewhere. There is nothing on the AD side that should be blocking this, other than the password being hashed in a way that is incompatible with Windows 2012 AD.[/quote]
If the password send from the UCS to the windows server is hashed in a way, that the Windows Server does not understand, shouldn’t I encounter the problem in my testing environment too and other customers also? Can you set up a lab, where you setup a UCS and a Windows Server with the same names, etc. in the same address range (and additionally a different range including routing) and try it for yourself in a controlled environment?
We have created a lab.
Same as our production setup, we used the NEW (fresh download) install media (ISO) for both the Windows 2012 and Univention Corporate Server 4.1.4. The only change is in the LAB there is NO routing as it is all on the same subnet (192.168.100.0/24)
We get the exact same errors when we attempt to make a connection to the AD server from UCS using AD Connector.
We are going to try one thing in the lab that was not done in production:
Our Windows System engineer, suggests we try RAISING the FOREST/DOMAIN Level to Windows 2008. It is currently running in the LAB and PROD as Windows 2003 Forest/Domain level.
He recalls that Microsoft has stopped all support for Windows 2003 this might also include supporting the Forest/Domain level of Windows 2003, he is wondering if it is possibly that UCS is using a method that is actually compatible more with Windows 2008 for the AD Connection than it is compatible with Windows 2003 (As Univention developers might have anticipated the removal of support for Windows 2003) OR that a Microsoft has released a patch that has been applied to our Windows 2008/2012 Servers has altered the SSL encryption tokens/hash scheme and has removed the SSL encryption support for Windows 2003 there by causing the user password to FAIL because the Univention system is using Windows 2008 SSL tokens/hashing and the AD servers is set to use Windows 2003 SSL tokens/hashing to make AD Connections. Which would explain why the Windows to Windows server ADDs to the DOMAIN work just fine, but the UCS to Windows server ADDs to the DOMAIN all fail.
Not sure if this is possible but we will try it in our lab and see what happens.