Adding LDAP role to domain controller
-
@Fredtx said in Adding LDAP role to domain controller:
@dbeato So what affect will this new Windows update have in March 2020 if it's in installed on an AD server that is still using the default non secure LDAP? Basically, what will it break? I do know clients who authenticate through their mobile ssl vpn via LDAP (ad user account & pw) so I can see how that will affect them and I'm guessing they will be unable to authenticate and therefore not be able to connect to their vpn?
We have a couple of applications (internal and external) that rely on LDAP for user/group sync so it will break any of those connections that aren't using LDAPS over port 389.
-
@dbeato said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller:
@dbeato So what affect will this new Windows update have in March 2020 if it's in installed on an AD server that is still using the default non secure LDAP? Basically, what will it break? I do know clients who authenticate through their mobile ssl vpn via LDAP (ad user account & pw) so I can see how that will affect them and I'm guessing they will be unable to authenticate and therefore not be able to connect to their vpn?
The LDAP connection between the SSL VPN and your AD Server is the one affected.
In this instance, The SSL-VPN (with AD connection) would need LDAPS setup which, at minimum, would require a internal Windows CA to be setup correct?
-
@pmoncho said in Adding LDAP role to domain controller:
@dbeato said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller:
@dbeato So what affect will this new Windows update have in March 2020 if it's in installed on an AD server that is still using the default non secure LDAP? Basically, what will it break? I do know clients who authenticate through their mobile ssl vpn via LDAP (ad user account & pw) so I can see how that will affect them and I'm guessing they will be unable to authenticate and therefore not be able to connect to their vpn?
The LDAP connection between the SSL VPN and your AD Server is the one affected.
In this instance, The SSL-VPN (with AD connection) would need LDAPS setup which, at minimum, would require a internal Windows CA to be setup correct?
Yes, that is correct. We have one set up which was easy enough but there is still some overhead there.. probably easier to just buy a public cert
-
@dave247 said in Adding LDAP role to domain controller:
@pmoncho said in Adding LDAP role to domain controller:
@dbeato said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller:
@dbeato So what affect will this new Windows update have in March 2020 if it's in installed on an AD server that is still using the default non secure LDAP? Basically, what will it break? I do know clients who authenticate through their mobile ssl vpn via LDAP (ad user account & pw) so I can see how that will affect them and I'm guessing they will be unable to authenticate and therefore not be able to connect to their vpn?
The LDAP connection between the SSL VPN and your AD Server is the one affected.
In this instance, The SSL-VPN (with AD connection) would need LDAPS setup which, at minimum, would require a internal Windows CA to be setup correct?
Yes, that is correct. We have one set up which was easy enough but there is still some overhead there.. probably easier to just buy a public cert
Currently we are on a .local domain and I believe we would need a cert for the DC itself, thus I don't believe I am able to get a public cert. Please correct me if I am wrong of if there is a way around this.
I am not looking forward to creating my own internal CA but I will if needed.
-
@pmoncho said in Adding LDAP role to domain controller:
@dave247 said in Adding LDAP role to domain controller:
@pmoncho said in Adding LDAP role to domain controller:
@dbeato said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller:
@dbeato So what affect will this new Windows update have in March 2020 if it's in installed on an AD server that is still using the default non secure LDAP? Basically, what will it break? I do know clients who authenticate through their mobile ssl vpn via LDAP (ad user account & pw) so I can see how that will affect them and I'm guessing they will be unable to authenticate and therefore not be able to connect to their vpn?
The LDAP connection between the SSL VPN and your AD Server is the one affected.
In this instance, The SSL-VPN (with AD connection) would need LDAPS setup which, at minimum, would require a internal Windows CA to be setup correct?
Yes, that is correct. We have one set up which was easy enough but there is still some overhead there.. probably easier to just buy a public cert
Currently we are on a .local domain and I believe we would need a cert for the DC itself, thus I don't believe I am able to get a public cert. Please correct me if I am wrong of if there is a way around this.
I am not looking forward to creating my own internal CA but I will if needed.
You are correct. internal CA should not be complicated.
-
@dbeato said in Adding LDAP role to domain controller:
@pmoncho said in Adding LDAP role to domain controller:
@dave247 said in Adding LDAP role to domain controller:
@pmoncho said in Adding LDAP role to domain controller:
@dbeato said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller:
@dbeato So what affect will this new Windows update have in March 2020 if it's in installed on an AD server that is still using the default non secure LDAP? Basically, what will it break? I do know clients who authenticate through their mobile ssl vpn via LDAP (ad user account & pw) so I can see how that will affect them and I'm guessing they will be unable to authenticate and therefore not be able to connect to their vpn?
The LDAP connection between the SSL VPN and your AD Server is the one affected.
In this instance, The SSL-VPN (with AD connection) would need LDAPS setup which, at minimum, would require a internal Windows CA to be setup correct?
Yes, that is correct. We have one set up which was easy enough but there is still some overhead there.. probably easier to just buy a public cert
Currently we are on a .local domain and I believe we would need a cert for the DC itself, thus I don't believe I am able to get a public cert. Please correct me if I am wrong of if there is a way around this.
I am not looking forward to creating my own internal CA but I will if needed.
You are correct. internal CA should not be complicated.
And I believe someone posted about that here a couple years ago.
-
@JaredBusch said in Adding LDAP role to domain controller:
@dbeato said in Adding LDAP role to domain controller:
@pmoncho said in Adding LDAP role to domain controller:
@dave247 said in Adding LDAP role to domain controller:
@pmoncho said in Adding LDAP role to domain controller:
@dbeato said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller:
@dbeato So what affect will this new Windows update have in March 2020 if it's in installed on an AD server that is still using the default non secure LDAP? Basically, what will it break? I do know clients who authenticate through their mobile ssl vpn via LDAP (ad user account & pw) so I can see how that will affect them and I'm guessing they will be unable to authenticate and therefore not be able to connect to their vpn?
The LDAP connection between the SSL VPN and your AD Server is the one affected.
In this instance, The SSL-VPN (with AD connection) would need LDAPS setup which, at minimum, would require a internal Windows CA to be setup correct?
Yes, that is correct. We have one set up which was easy enough but there is still some overhead there.. probably easier to just buy a public cert
Currently we are on a .local domain and I believe we would need a cert for the DC itself, thus I don't believe I am able to get a public cert. Please correct me if I am wrong of if there is a way around this.
I am not looking forward to creating my own internal CA but I will if needed.
You are correct. internal CA should not be complicated.
And I believe someone posted about that here a couple years ago.
Thanks. I will do some searching.
-
@dbeato said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller:
@dbeato So what affect will this new Windows update have in March 2020 if it's in installed on an AD server that is still using the default non secure LDAP? Basically, what will it break? I do know clients who authenticate through their mobile ssl vpn via LDAP (ad user account & pw) so I can see how that will affect them and I'm guessing they will be unable to authenticate and therefore not be able to connect to their vpn?
The LDAP connection between the SSL VPN and your AD Server is the one affected.
What about:
- LDAP connection between site to site VPN due to the office not having an on-premise AD server?
*Exchange 2016 that is on-premise and in the same LAN as AD server?
- LDAP connection between site to site VPN due to the office not having an on-premise AD server?
-
@Fredtx said in Adding LDAP role to domain controller:
@dbeato said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller:
@dbeato So what affect will this new Windows update have in March 2020 if it's in installed on an AD server that is still using the default non secure LDAP? Basically, what will it break? I do know clients who authenticate through their mobile ssl vpn via LDAP (ad user account & pw) so I can see how that will affect them and I'm guessing they will be unable to authenticate and therefore not be able to connect to their vpn?
The LDAP connection between the SSL VPN and your AD Server is the one affected.
What about:
- LDAP connection between site to site VPN due to the office not having an on-premise AD server?
*Exchange 2016 that is on-premise and in the same LAN as AD server?
What is supporting the site to site VPN? does it somehow tie into AD?
My site to site VPN has no idea about AD, The Exchange/AD traffic is just that - traffic that flows over the VPN. To AD, VPN is just another router, it doesn't care.
- LDAP connection between site to site VPN due to the office not having an on-premise AD server?
-
@Dashrender said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller:
@dbeato said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller:
@dbeato So what affect will this new Windows update have in March 2020 if it's in installed on an AD server that is still using the default non secure LDAP? Basically, what will it break? I do know clients who authenticate through their mobile ssl vpn via LDAP (ad user account & pw) so I can see how that will affect them and I'm guessing they will be unable to authenticate and therefore not be able to connect to their vpn?
The LDAP connection between the SSL VPN and your AD Server is the one affected.
What about:
- LDAP connection between site to site VPN due to the office not having an on-premise AD server?
*Exchange 2016 that is on-premise and in the same LAN as AD server?
What is supporting the site to site VPN? does it somehow tie into AD?
My site to site VPN has no idea about AD, The Exchange/AD traffic is just that - traffic that flows over the VPN. To AD, VPN is just another router, it doesn't care.
There is nothing supporting it. It's just a simple site to site using a PSK with AES 256 encryption, etc. Nothing with AD. I guess I was thinking about the LDAP traffic going through the tunnel that would be of concern, but based on your response I can see there is nothing to be concerned about.
Now, I do know customers who have Synology and Qnap NAS that rely on AD for file shares and such. I would think these would be affected?
- LDAP connection between site to site VPN due to the office not having an on-premise AD server?
-
@Fredtx said in Adding LDAP role to domain controller : >
Now, I do know customers who have Synology and Qnap NAS that rely on AD for file shares and such. I would think these would be affected?
I would agree with you.
-
@Fredtx said in Adding LDAP role to domain controller:
Now, I do know customers who have Synology and Qnap NAS that rely on AD for file shares and such. I would think these would be affected?
Why would they be affected? Those are AD, AD isn't affected. LDAP is. Anything using AD should not be affected. Because it is Kerberos, not LDAP.
-
@Dashrender said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller : >
Now, I do know customers who have Synology and Qnap NAS that rely on AD for file shares and such. I would think these would be affected?
I would agree with you.
Why? They don't use LDAP, if they are affected, every Windows desktop is affected.
-
@scottalanmiller said in Adding LDAP role to domain controller:
@Dashrender said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller : >
Now, I do know customers who have Synology and Qnap NAS that rely on AD for file shares and such. I would think these would be affected?
I would agree with you.
Why? They don't use LDAP, if they are affected, every Windows desktop is affected.
You don't think they are? I think they are - only it's a non issue because MS is releasing a patch for them at the same time - or already did so Win 8 and Win 10 already support LDAPS, so it's a non issue.
-
With regards to switching to LDAPS, anyone out there with Nextcloud, Bookstack, Zimbra, other linux apps that use LDAP for logins from a Windows domain?
Just wondering what others have planned?
-
@scottalanmiller said in Adding LDAP role to domain controller:
@Dashrender said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller : >
Now, I do know customers who have Synology and Qnap NAS that rely on AD for file shares and such. I would think these would be affected?
I would agree with you.
Why? They don't use LDAP, if they are affected, every Windows desktop is affected.
I just reread this - what do you mean they don't use LDAP? I mean - OK I'm guessing you're right, but if not LDAP for authentication, and assuming they are using AD for authentication - then what protocol are they using?
-
@Dashrender said in Adding LDAP role to domain controller:
@scottalanmiller said in Adding LDAP role to domain controller:
@Dashrender said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller : >
Now, I do know customers who have Synology and Qnap NAS that rely on AD for file shares and such. I would think these would be affected?
I would agree with you.
Why? They don't use LDAP, if they are affected, every Windows desktop is affected.
You don't think they are? I think they are - only it's a non issue because MS is releasing a patch for them at the same time - or already did so Win 8 and Win 10 already support LDAPS, so it's a non issue.
Why would they be using LDAP? Do you install LDS to use them? No, they bind to AD.
-
@Dashrender said in Adding LDAP role to domain controller:
@scottalanmiller said in Adding LDAP role to domain controller:
@Dashrender said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller : >
Now, I do know customers who have Synology and Qnap NAS that rely on AD for file shares and such. I would think these would be affected?
I would agree with you.
Why? They don't use LDAP, if they are affected, every Windows desktop is affected.
I just reread this - what do you mean they don't use LDAP? I mean - OK I'm guessing you're right, but if not LDAP for authentication, and assuming they are using AD for authentication - then what protocol are they using?
Kerberos, like all AD does. AD uses Kerberos by default.
Remember these are just like Windows desktops in this scenario. Or can be, at least.
-
@scottalanmiller said in Adding LDAP role to domain controller:
@Dashrender said in Adding LDAP role to domain controller:
@scottalanmiller said in Adding LDAP role to domain controller:
@Dashrender said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller : >
Now, I do know customers who have Synology and Qnap NAS that rely on AD for file shares and such. I would think these would be affected?
I would agree with you.
Why? They don't use LDAP, if they are affected, every Windows desktop is affected.
I just reread this - what do you mean they don't use LDAP? I mean - OK I'm guessing you're right, but if not LDAP for authentication, and assuming they are using AD for authentication - then what protocol are they using?
Kerberos, like all AD does. AD uses Kerberos unless you enable LDS.
Then I'm confused - where is the issue with LDAP vs LDAP? is LDAP sending sensitive information unencrypted over the network? what things use LDAP?
-
@Dashrender said in Adding LDAP role to domain controller:
@scottalanmiller said in Adding LDAP role to domain controller:
@Dashrender said in Adding LDAP role to domain controller:
@scottalanmiller said in Adding LDAP role to domain controller:
@Dashrender said in Adding LDAP role to domain controller:
@Fredtx said in Adding LDAP role to domain controller : >
Now, I do know customers who have Synology and Qnap NAS that rely on AD for file shares and such. I would think these would be affected?
I would agree with you.
Why? They don't use LDAP, if they are affected, every Windows desktop is affected.
I just reread this - what do you mean they don't use LDAP? I mean - OK I'm guessing you're right, but if not LDAP for authentication, and assuming they are using AD for authentication - then what protocol are they using?
Kerberos, like all AD does. AD uses Kerberos unless you enable LDS.
Then I'm confused - where is the issue with LDAP vs LDAP? is LDAP sending sensitive information unencrypted over the network? what things use LDAP?
Things that connect over LDAP instead of using AD fully. Applications like people are mentioning, like NextCloud, that are generic LDAP clients, not AD clients. No normal process uses LDAP, hence why they can make the change somewhat casually. LDAP is not used by an day to day process for AD as intended. It's a fall back for non-AD clients that use generic LDAP.
