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.
Raising the domain/forest level had no impact in the lab. We have tried using our Primary AD Server and our Secondary AD Server in the Active Directory Connection wizard. Both by FQDN and by IP. With no success with either one. We have opened all AD required firewall ports and added UCS Domain Master ports to be open on the Windows Firewalls, we have checked for any routing issues and those have been corrected, still no success.
This worked prior to rebuilding UCS under 4.1-4.
The only error we are getting in this whole thing is in the log file /var/log/univention/management-console-module-adconnector.log and the entry is:
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @104.153.46.198
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37147
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;. IN NS
;; Query time: 112 msec
;; SERVER: 104.153.46.198#53(104.153.46.198)
;; WHEN: Thu Dec 1 13:39:07 2016
;; MSG SIZE rcvd: 17
01.12.16 13:39:07.277 MODULE ( PROCESS ) : stderr:
01.12.16 13:39:07.370 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’}
01.12.16 13:39:07.479 MODULE ( WARN ) : Failure:
01.12.16 13:39:07.479 MODULE ( PROCESS ) : The command has failed: Could not connect to AD Server BEBW12MTASVRP1.bebconsultingservices.com. Please verify that username and password are correct.
01.12.16 13:49:07.144 MAIN ( WARN ) : Shutting down all open connections
01.12.16 13:49:40.521 DEBUG_INIT
01.12.16 13:50:15.946 MODULE ( PROCESS ) : Lookup ADDS DC
01.12.16 13:50:16.005 MODULE ( PROCESS ) : running [‘dig’, '@104.153.46.198’]
01.12.16 13:50:16.140 MODULE ( PROCESS ) : stdout:
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @104.153.46.198
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10904
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;. IN NS
;; Query time: 112 msec
;; SERVER: 104.153.46.198#53(104.153.46.198)
;; WHEN: Thu Dec 1 13:50:16 2016
;; MSG SIZE rcvd: 17
01.12.16 13:50:16.140 MODULE ( PROCESS ) : stderr:
01.12.16 13:50:16.236 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’}
01.12.16 13:50:16.344 MODULE ( WARN ) : Failure:
01.12.16 13:50:16.344 MODULE ( PROCESS ) : The command has failed: Could not connect to AD Server BEBW12MTASVRP1.bebconsultingservices.com. Please verify that username and password are correct.
01.12.16 14:00:16.316 MAIN ( WARN ) : Shutting down all open connections
These logs are empty…
ad-connector-certificate.log
connector.log
The log file connector-status.log has this…
root@bebucsmtasvrp5:/var/log/univention# cat connector-status.log
Thu Dec 1 13:10:36 2016
connector/ad/ldap/host not set
We have tried several different passwords for Administrator on the Windows Side. All with the same error. We REALLY need to get this working. To provide UCS Resources to Windows Users and Windows Resources to UCS Users.
I am pushing to get formal Univention Support Subscription purchased, but that will take several weeks to get approved.
01.12.16 13:39:07.277 MODULE ( PROCESS ) : stderr:
01.12.16 13:39:07.370 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'}
01.12.16 13:39:07.479 MODULE ( WARN ) : Failure:
01.12.16 13:39:07.479 MODULE ( PROCESS ) : The command has failed: Could not connect to AD Server BEBW12MTASVRP1.bebconsultingservices.com. Please verify that username and
password are correct.
01.12.16 13:49:07.144 MAIN ( WARN ) : Shutting down all open connections
01.12.16 13:49:40.521 DEBUG_INIT
01.12.16 13:50:15.946 MODULE ( PROCESS ) : Lookup ADDS DC
01.12.16 13:50:16.005 MODULE ( PROCESS ) : running ['dig', ['@104.153.46.198](mailto:'@104.153.46.198)']
01.12.16 13:50:16.140 MODULE ( PROCESS ) : stdout:
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @104.153.46.198
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10904
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
The UCS cannot reach the AD - the answer (incorrect username/password may be misleading if the server is not reached at all) is rather clear. I do not understand, why a UCS would not reach the DC if the IP Config is okay (i.e. for a lab-env in the same subnet) and there are no additional network routing, etc. between them. Since I cannot reproduce the error in any way I am sure there must be something we still do not know about your environment, that hinders the connection. That has to be present at the lab too.
Well I guess I will have to wait and see if I get formal support subscription approved. I’m not sure how I could provide environment infomation. It pretty much as been provided in this thread.
Its pretty basic…
We have two windows servers in Co-Location A, the UCS Server in Co-Location B. There are no physical firewalls on these servers on their internet connections. No ports are being blocked. Windows Firewall has all AD ports and UCS Domain ports opened on both our Primary Windows AD and Secondary Windows AD. Both Windows ADs provide DNS services. Other Windows Systems have NO issues finding and joining the Windows Domain.
This was working under 4.0.x and 4.1-3. We had to rebuild it so we rebuilt it to the latest version 4.1.4 and ever since AD Connector has not worked.
We did the same setup in our lab. Only difference is there is NO CO-LOCATION for the lab.
Not sure what else I could provide.
[quote=“BrianBonnell”]
This was working under 4.0.x and 4.1-3. We had to rebuild it so we rebuilt it to the latest version 4.1.4 and ever since AD Connector has not worked.
[…]
Not sure what else I could provide.[/quote]
mostly, the difference between your lab and mine. As I said, it is working fine with my repeated installations of UCS and Windows Server in the versions you used and with the domain and servernames you have active (see above - I told of the the process earlier in detail). What do you mean by “rebuild”? I use a stock UCS and a stock Windows in the same physical space to cross out routing issues. Did you managed to fix the traceroute problem from the UCS?
The UCS cannot reach the Windows Server even if the Windowsserver is newly installed and the process of the AD-Join of the UCS happens within the installationroutine of the UCS, that problem has to be fixed first. Maybe hardware issues with the network of the UCS? More then one networkcard in the UCS and only one with an IP? Switchport dekativated, Networkcable defect, etc.?
Did you try another UCS 4.0 or 4.1-3 installation in the lab to verify that this works in this environment?
What do you mean by “rebuild”?
By rebuild I mean wipe the drives clean. Do a FRESH install of the Univention Corporate or Microsoft Windows 2012 R2 Standard OS.
Did you managed to fix the traceroute problem from the UCS?
After investigation by our co-location providers at both ends, it was discovered that there WAS no routing issues, the output for TRACEROUTE was NORMAL for both those providers.
Maybe hardware issues with the network of the UCS?
We have swapped hardware twice with known good hardware…same problem still results.
Did you try another UCS 4.0 or 4.1-3 installation in the lab to verify that this works in this environment?
4.0 and 4.1.3 do work in the lab. Out of pure curiosity we did an upgrade on the lab system to 4.1.4. and NOW AD Connector is now broke with the exact same errors.
So based on this SOMETHING with upgrading to 4.1.4 breaks AD Connector and a straight up 4.1.4 install does not work period with AD Connector.
With the install of 4.1.0 which also works for AD Connector, when joining to the AD we did not get this screen in the 4.1.4 install.
We are giving up on this at this time. We will rebuild again as 4.1.4 (We need to be the most current for security compliance.) so we will rebuild as a separate domain, with separate user logins and run Active Directory Compatible Controller as it’s own domain, with a subdomain in our DNS. We still still proceed with purchasing support as well. We just will run as two separate domains.
[quote=“BrianBonnell”]With the install of 4.1.0 which also works for AD Connector, when joining to the AD we did not get this screen in the 4.1.4 install.
[attachment=0]Missing Screen.jpg[/attachment][/quote]
This is kinda important: this screen tells you basically that another UCS master is already present in the network. Normally a fresh UCS joined in a windows AD will join as master - you do not get to choose a role. If you think you install the first UCS to the AD and you get this screen, there is an old master present in the AD somewhere. The AD has to be scrubbed then. I had another case in the forums regarding that, the most likely place is in this thread.
I am sorry you are giving up on the membermode but I think a Samba4 domain as you plan it will work too.
There has never been a UCS Master in the Production AD Domain, we have NEVER been able to get it to JOIN due to the previous forum replies. We have checked the production/development (lab) domains. There is NO other UCS Masters. In the lab we always do a FRESH install so it wipes out the AD and UCS domains each time we rebuild the lab. In production there is no UCS Master, as it NEVER joined the domain. We only have a Primary and Secondary Windows Active Directory Servers.
Since we cannot seem to get UCS AD Connector to work. We have built it as it’s OWN separate DOMAIN (FQDN:ucs.bebconsultingservices.com/NETBIOS:UCS) with separate user logins and passwords. Our end users will just have to maintain two accounts one for Windows Resources, and one for UCS Resources. As we could not wait for getting Official UCS Support (still waiting on Support Purchase approval on our end) and then open a case to see if UCS Support could fix the issue as we needed to get some production UCS applications ON-LINE for our end users. Once we get official UCS support, we can take another run at this issue in the LAB and work from there. Until then we will just have to have this configuration as a work around.
[quote=“BrianBonnell”]There has never been a UCS Master in the Production AD Domain, we have NEVER been able to get it to JOIN due to the previous forum replies. We have checked the production/development (lab) domains. There is NO other UCS Masters. In the lab we always do a FRESH install so it wipes out the AD and UCS domains each time we rebuild the lab. In production there is no UCS Master, as it NEVER joined the domain. We only have a Primary and Secondary Windows Active Directory Servers.
[/quote]
That is the point I mean with “There has to be something I do not know about your environment”. You say, there can not be another UCS Server (with many a capital word), but the UCS gets the information, that there is another server. Either we talk about different things when talking about “wiping” or the UCS tries to join another server or it can reach another net, or, or, or. To get to a conclusion, we would need to take a step back and have a look at the configuration of the lab and the servers therein I think.
One other thing: in the DNS there is a setting for “domaincontroller_master” - you can check if there is an entry for a server (that is one place, where the UCS sets himself up in the AD DCs).
[quote=“BrianBonnell”]
Since we cannot seem to get UCS AD Connector to work. We have built it as it’s OWN separate DOMAIN (FQDN:ucs.bebconsultingservices.com/NETBIOS:UCS) with separate user logins and passwords. Our end users will just have to maintain two accounts one for Windows Resources, and one for UCS Resources. As we could not wait for getting Official UCS Support (still waiting on Support Purchase approval on our end) and then open a case to see if UCS Support could fix the issue as we needed to get some production UCS applications ON-LINE for our end users.[/quote]
You can use the AD-Connector in Sync Mode (to sync userdata, etc.): https://docs.software-univention.de/manual-4.1.html#ad-connector:ad-connector-einrichtung Maybe that can help in your current situation.
[quote=“BrianBonnell”]
Once we get official UCS support, we can take another run at this issue in the LAB and work from there. Until then we will just have to have this configuration as a work around.[/quote]
We will need to have a closer look at the lab, etc. either way.
Hi Thorp-Hansen,
Hopefully I am not hijacking other members post but I think I am facing similar problem like BrianBonnell
Please check below link for details
Regards,
Nitin
I am unsure if we can compare these cases, since you seem to have created something like a forest structure and you seem to have general issues with DNS. Mr Bonnel has a seemingly working networkinfrastructur (from what I could gather) and DNS and the UCS cannot connect to the AD even if they stand in the same lab next to each other (at least that was my understanding and proposition for the last tests).
This issue is exactly what I had.
To resolve it was easy. Go to the DNS on your AD Domain Server and remove any existing DNS entries
equal to the one you’re trying to add.
I.e. if your ownloud computer has IP 172.22.40.100
most likely in the AD DNS there’s already an entry for that IP and thus it errors on you exactly the same way as you described, because I got exactly that same error message.
You might as well just erase all non-static IP anyway…
after it you can join the domain without an issue.