localzuk Posted January 30, 2020 Posted January 30, 2020 That's £1500, no way I'd be getting that, nor could I see the point of running over 12 Windows VMs on one host. We run 46 VMs across 2 hosts... It’s around £250 PA on OVS-ES. Indeed it is. We pay for 2 of them for our 2 hosts. Covers all of our VMs. So over 6 years same cost, although it EOLs in 9 years, so cheaper to buy outright No it isn't. A new version of Windows Server comes out every couple of years. So, buying outright is simply not cost effective in schools. VL agreements save you funds so long as you're upgrading when new versions come out. My aim is to provide the best solution to the tasks we have, with up to date technology and resources. If that is by spending with Microsoft, so be it. If that's with Google, fair enough. On topic - we run our CA server in its own VM as a member server. We've had no issues, and its a small VM that barely uses any resources. So, can't see any reason you wouldn't go this route. 1
Duke5A Posted January 30, 2020 Posted January 30, 2020 The previous admin at my work installed ADCS on a DC and it when it came time to decommission the DC it made the task far more complicated. Sure, a lot of times the recommendations from MS are simply to sell more licenses, but this isn't one of those times. Domain controllers typically have short lifespans due to wanting to upgrade before support even runs out and you cannot perform in-place upgrades on them. A member server with the ADCS role has a longer shelf life, and I believe it can be upgraded in place. Stick it on a member server - your future self will thank you. 2
synaesthesia Posted January 31, 2020 Posted January 31, 2020 OK, so we've hit a stumbling block. There appears to be an "issue" with standards. LDAPS over 636 appears standard for anything Windows based, however talk to anyone Linux based, if I understand correctly, that was deprecated a dozen or so years ago and they don't support it. So, anything running something like OpenLDAP (PHP is a good example) refuses to work over SSL and needs StartTLS instead, working on the start port 389. Getting information on getting that working on windows though seems to be like blood from a stone!
3s-gtech Posted January 31, 2020 Posted January 31, 2020 Rather than hitting my head against a wall, I got to the stage of grinding my bare skull against a breezeblock so got bored and stopped. However - I set our PHP based LDAP auth'd internal web services over to LDAPS simply by changing the connection string: $server = "ldaps://server.domain.uk.com:3269"; $base_dn = "DC=domain,DC=uk,DC=com"; // Connect to ldap server $ldapconn = ldap_connect($server); I changed $server to point to a particular server rather than the FQDN of the actual domain in testing, as I was wondering about certificate SANs etc. It seems to work either pointing at a DC or at the domain as standard though. Once I changed this, the number of unsecure binds dropped hugely and the application still works. I've only ever used port 3269 for secure binds though. This seems to be a fairly standard setup when I was researching this. I must note that this application resides on a Windows server, but it's running WIMP rather than WAMP.
mavhc Posted January 31, 2020 Posted January 31, 2020 OK, so we've hit a stumbling block. There appears to be an "issue" with standards. LDAPS over 636 appears standard for anything Windows based, however talk to anyone Linux based, if I understand correctly, that was deprecated a dozen or so years ago and they don't support it. So, anything running something like OpenLDAP (PHP is a good example) refuses to work over SSL and needs StartTLS instead, working on the start port 389. Getting information on getting that working on windows though seems to be like blood from a stone! https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/8e73932f-70cf-46d6-88b1-8d9f86235e81 seems to imply both just work. You're saying that LDAPS is working but LDAP STARTTLS isn't working?
synaesthesia Posted January 31, 2020 Posted January 31, 2020 https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/8e73932f-70cf-46d6-88b1-8d9f86235e81 seems to imply both just work. You're saying that LDAPS is working but LDAP STARTTLS isn't working? Pretty much yes, although can't be sure if it's server side or client. I imagine it's the client (in this case it's our OSTicket helpdesk installation on Server 2016 IIS) - this is on PHP 7.latest.
mavhc Posted January 31, 2020 Posted January 31, 2020 LDAP Admin: Download has a windows client that can do port 389 tls connections to test if it's working, you probably want LdapAdminExe-w64-1.8.3.zip 1
timbo343 Posted February 3, 2020 Posted February 3, 2020 Was given a link to this document https://docs.microsoft.com/en-gb/archive/blogs/microsoftrservertigerteam/step-by-step-guide-to-setup-ldaps-on-windows-server for those who are setting up LDAPS on Windows Server.
mavhc Posted February 3, 2020 Posted February 3, 2020 That's probably not the LDAPS you are looking for. There's also an LDAP(S) interface to AD that is what most people will be using.
localzuk Posted February 3, 2020 Posted February 3, 2020 Was given a link to this document https://docs.microsoft.com/en-gb/archive/blogs/microsoftrservertigerteam/step-by-step-guide-to-setup-ldaps-on-windows-server for those who are setting up LDAPS on Windows Server. Yeah, that's for setting up a separate LDAPS server - not setting up AD as LDAPS.
mavhc Posted February 3, 2020 Posted February 3, 2020 Wordpress plugin AuthLDAP works with LDAP STARTTLS, and LDAPS, but only if you import the server cert, not just the CA cert
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now