[SOLVED] LDAP and VPN Issues following ad-takeover

UCS - Univention Corporate Server
#1

Hello,

I was able to successfully do the ad-takeover after following the advice from an employee here. I had to install an older version of UCS in order for the ad-takeover of W2K3 to be successful. However, I’m running into issues now that the server is up and running. Some users’ passwords no longer work, even after resetting them or changing them via the UCS web-client. Other windows 10 users can sign in, but they’re signed in as a different user with the same name (i.e. their user profile gets recreated and they must start fresh.) Other users still can sign into the domain, but are created as temp accounts and windows throws an error saying that the account cannot be signed in.

I asked about users unable to sign in, and was told to use kinit . some passwords work, others don’t. But then what do I do?

Additionally, a user-group was created in the W2K3 server called VPN_Users that allowed our SonicWall firewall to use user authentication for VPN access. This is non-functioning under UCS.

Any help with these issues would be greatly appreciated.

NOTE Since UCS is currently non-functional, I have pulled it from the network and setup a test environment. The W2K3 server is still the main ad/dc at this time.

#2

After much deliberation, I decided to simply reset all of the users passwords within my test environment. This salved the issue of unrecognized users as I was simply using incorrect passwords. I also left the domain and rejoined the domain to ensure that functionality would work. The temp account issue was solved by deleting old user entries from System Settings -> System Info -> Advanced System Settings -> User Profile Settings.

Additionally, I learned that you can use this settings panel to move user accounts and duplicate them in case leaving/rejoining the domain wipes user data.

Now, focusing on the VPN issue. Our SonicWALL has built-in functionality that points to our ldap (previously W2K3 Active Directory). The SonicWALL requires users use their full name rather than their username. So, say we are using John Doe as the Domain Admin, and his username is jdoe; we would need to use John Doe as the username in the SonicWall. The issue arose when ad-takeover took place, the user that was used was a single name, “ldap.” The name became “ldap none,” because with UCS, a last name is required, but with W2K3, only a name is required.

I was also able to connect using TLS so I changed the port from 389 to 636.

Additionally, there were several legacy settings that transferred from the old W2K3 server, such as DNS settings, that were simply wrong and threw a wrench in the entire network. I was able to solve all of these issues in the test environment and will soon implement the new UCS into the live environment once further tests have been completed. Such as joining the domain, GPOs, etc.

#3

I remember some Sonicwall VPNs have either a “Active Directory” or a plain LDAP mode. The “plain” LDAP mode allows you to set the attributes like the username it should use. That might be worth a consideration as it is more flexible AFAIR.

#4

From what I’ve found, you’re only allowed the ldap mode. Here’s the documentation I found during this process.

#5

OK, my experience is based on the Sonicwall SSL VPN boxes (SRA line) which have different firmware. These have an option for Active Directory and LDAP (also local users, RADIUS and certificate auth).

(http://help.sonicwall.com/help/sw/eng/8112/8/0/0/content/Chapter14_Users.18.15.html)

Even in the case of a MS AD I ended up using LDAP as it was the only working way to get group matching and policies working this way. I also remember that even though they write (standard) LDAP that their Appliances still more an AD-like LDAP directory structure (attributes).

#6

From what I’ve experienced, SonicWALL gives you the ability to implement both SSL VPN and WAN group VPN. (Not really sure what they call it, but it utilizes IKE, IPSEC, and xauth.)

Both VPN implementations utilize the ldap settings configured under the User Settings page.
One interesting thing to note is that even though there is an option for Samba SMB AD, when running autoconfigure; SonicWALL sees UCS as Microsoft AD.
This is likely due to the ad-takeover mentioned earlier.

Mastodon