Securing LDAP over SSL Safely [Windows Server 2019] 

Glad to hear you say that thank you. Much appreciated. This is a great special case so I am pinning this comment for anyone who may also be in your situation. If I understand correctly, my best guess right now is you are using the "Kerberos Authentication" certificate template I covered in the video. This will not work for your situation unfortunately because the CA is not going to look at the SAN value. You will need to use the "Web Server" certificate template (Version Windows Server 2003 under General Tab). Because the CA is a third party we need to create our request manually with certutil I tried creating a "request.inf" file for you to use. You will need to add your servers FQDN to the subject value and SAN values where appropriate CONTENTS OF request.inf ################################################################################################### [Version] Signature=”$Windows NT$” [NewRequest] Subject = “CN=hostname.domain.com” ; Must be FQDN of Domain Controller EncipherOnly = FALSE ; Default value and is optional I believe Exportable = TRUE ; Private key is exportable KeyLength = 2048 ; Key sizes: 2048 KeySpec = 1 ; AT_KEYEXCHANGE (Key Exchange) KeyUsage = 0xA0 ; Digital Signature, Key Encipherment MachineKeySet = True ; The key belongs to the local computer account ProviderName = “Microsoft RSA SChannel Cryptographic Provider” ProviderType = 12 RequestType = CMC [EnhancedKeyUsageExtension] OID=1.3.6.1.5.5.7.3.1 ; Server Authentication ;[RequestAttributes] ;CertificateTemplate= WebServer ; Include the above line and below two lines if CA is a stand-alone CA and remove the Extensions section below ;"SAN="dns=san.domain.com&dns=san2.domain.com&dns=san3.domain.com" ; SAN Values go here separated by & ;I assume it is not a standalone CA so we do this [Extensions] ;2.5.29.17 is the OID for a SAN extension. 2.5.29.17 = "{text}" _continue_ = "dns=san1.domain.com&" _continue_ = "dns=san2.domain.com&" _continue_ = "dns=san3.domain.com&" ##################################################################################################### # COMMANDS TO CREATE CSR REQUEST USING ABOVE FILE certreq -new request.inf newcert.req certutil newcert.req # Submit the above certificate request to your 3rd Party CA Hope that helps. If you would like to feel free to email me at info@osbornepro.com

@@OsbornePro Hi I have my CA third party certificate with above details with SAN details. I want if want to install that certificate chain what the exact steps , or I can just import that pfx/p12 which contain all my CA certificate chain in place like which includes (certificate.pub certificate.key certificate.cer ). thanks , waiting for reply.

@@tusharjambhekar sorry I am just noticing this response now. My notifications seem to sometimes tell me and sometimes not. You can just simply right click on the pfx certificate in Windows and select install. For anyone who may not know, Pfx means the private key is in there which you need as the LDAPS server will use it. Make sure the other devices in the domain trust the root CA’s of that third party. You will need to export those separately before installing them on other devices in the environment. This is because we don’t want that private key leaving the Domain Controller

Thanks for watching! Glad it was helpful. I love hearing when things like this get implemented you are killing it

Thanks for watching! Glad it helped

@@pstz_800 thanks for watching glad it was helpful!

Thanks appreciate you saying that and you support! I do my best to try to always answer. It’s still doable at this point :)

​@@OsbornePro very thanks for your effort. My english is not very well, but i shared in some group from India.

@@RodrigoLelesMiranda haha right on man. Props on being bilingual

Thanks appreciate it. I know that feeling

Thanks for watching! I appreciate your support!

Thanks for watching I appreciate the support. I will put it on my list

Thanks for watching! I love hearing when people are able to get that going. That is not ringing a bell, what is L desu? Did I miss out on something

@@OsbornePro That is a hard one to explain If you haven't watched the Japanese or subbed version of Death Note. One of the characters L sometimes says it as shortened version of watashi wa L desu to say who he is.

Thanks for watching! Linux devices only need to trust the Root CA certificate to use LDAPS successfully. To join a Linux server to a Windows domain and configure LDAP authentication is a good idea for a video thanks

@@OsbornePro Thanks. Is the imported certificate can only be a valid cert to use for Linux clients? Or does a third party certificate also work?

@@237311 as long as the certificate is trusted it will work

@@OsbornePro Is there a PowerShell command to check for LDAP authenticated Windows clients?

Thanks for watching!

Thanks for watching! Appreciate the support

Thanks for watching! Glad they were helpful

Thanks for watching, glad it was helpful!

Thanks appreciate the feedback!

Thanks for watching and the support! Will do!

Thanks for watching! LDAP requests will still be made and will go through. The type of LDAP request that is clear text is an LDAP bind. Anytime an LDAP bind is performed by a client it will force the use of LDAP over SSL

ok thank you, but why my firewall watchguard can no longer connect to ldap without adding the ldaps option as well as the domain certificate while my w10 clients can always connect to the domain with the gpo on "None" for LDAP signed connections ?

@@mcdmofr if you set the Default Domain Controller Group policy object to only accept LDAPS binds, the server will require the LDAP binds to be secured from external devices like your firewall.

@@OsbornePro thank you it's clear

Thanks for watching appreciate the support!

Thanks for watching!

Hey thanks for watching! As far as functionality goes it does not matter whether you use a dedicated service account or the default service account. The purpose of a dedicated service account is to limit the accounts interactions with other services if it is ever compromised. I can get lost in thought doing the videos and probably was thinking about something else during the time I should have changed it

Thanks for watching! The LDAPS policy would only be applied to Windows domain joined devices. The LDAP client setting tells client machines to use LDAP over SSL whenever performing LDAP binds against the DC. The certificate configuration for LDAPS will work on its own. However, the windows clients are not being told to use it without that setting. You could still trust the root CA certificate on any Unix based device and successfully tell the device to use secure LDAP binds. I had other policies in the video that were from other videos I had done or just playing around.

Thank you for the quick response! Perfect! This will definitely help out 👍🏼

Thanks for watching! The length of the video may be deceptive in how much needs to be done. Prerequisites: 1. Certificate Authority a. Contains an LDAPS Certificate Template to issue to DCs 2. Domain Controller a. Assigned the LDAPS certificate from the CA b. LDAPS Certificate template attached to the NTDS service You do not necessarily need an Enterprise CA however it does make the implementation simpler. The LDAPS certificate template can likely be obtained from whatever you are using as your Certificate Authority. The tricky part is the LDAPS certificate can not use a typical SSL certificate such as one you would attach to HTTPS. This is why the service is unable to be a wildcard certificate and it cannot have a Subject Alternative Name.

Thanks for watching! If the Domain Controllers policy is set to require signing, the LDAP Clients are required to have their policy set. The client policy can NOT be set to "None". If the clients do not trust the certificate issuer the SSL connection will not be successful. The below links are the references for your question. LDAP is a language used to query a directory service. The types of LDAP requests can be Add, Bind, Delete, Modify, or Unbind. An LDAP Bind request authenticates a client to the directory server. Active Directory is not the same as an LDAP server but it does understand the language. This is why non-Windows devices need to perform authentication requests using LDAP Binds where Windows clients can utilize I believe Kerberos. (EDIT: I just looked into it and LDAPv3 is able to use SASL authentication, Simple/LDAP Bind, or Anonymous. The use of SASL is what allows Kerberos and TLS to be used) I am not familiar with when exactly Windows clients use LDAP Binds but they do seem to still be utilized based on Microsoft's recommendations. When you tell the Active Directory server to require signing for LDAP the Cisco ASA for example, needs to trust the Root CA that issued the LDAPS certificate. Otherwise the initial connection will fail. The alternative to an LDAP Bind would be allowing anonymous authentication which would allow anyone who can communicate with your Domain Controller to retrieve directory information from it. CLIENT: docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements SERVER: docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements

@@OsbornePro Dear Osborne, you are amazing! Thank you so much for your explaination!

@@BGPNetworks thanks for watching! It is not recommended to user your DC as a CA however, that should not affect the setup. The CA cert still needs to be trusted by the server and clients. It is still able to do what you need it too

Thanks for watching! You are able to place the CA and AD on the same server. It is not considered a best practice to do that in a production environment. There is no harm in doing it in your test environment

@@OsbornePro thank you 👍

Thanks for watching! As long as you follow the testing steps I outlined there won’t be any issues. If you were to apply the DC enforcement policy first without applying the client policy it will break authentication on the clients. Any non-windows devices performing secure ldap binds will be logged by 2889 on the DC and will need to have their config updated and the ldaps’ root ca certificate trusted in order to use LDAP over SSL. Anytime the root ca certificate expires it will need to be updated in ldap client devices. Some people don’t enforce secure binds on the DC as a just in case and instead receive email alerts whenever an insecure LDAP bind generates event id 2889 That is pretty much the extent of what could happen if not carried out properly. The worst thing would be enforcement on a DC where clients have the opposite configuration via group policy. That would require rejoining a whole lot of devices to the domain

@@garethofer1619 Definitely, that is no problem to do

Right on thanks for watching! I would suggest doing so however the LDS service does not need to be installed for LDAPS to work. I included so if the environment needs to add the service at another time and the domain controller is set to force SSL usage, someone who watched the video doesn’t blame me for it not working haha. I would suggest having the domain controllers latch so if it is installed on one install it on the other. As long as you are able to connect to 636 it should mean it is working. The certificate is not assigned to the service by default so if you or someone else has not done that it will need to be done to attach the LDAPS certificate to the port.

@@OsbornePro Okay, so I must've misunderstood then. The LDS service is not technically required for LDAPS at all? Then the question is how to roll out LDAPs on my other DCs. I can connect to the one running the certificate authority on 636, no problem. On the others, which are only DCs with no other services, I cannot. Is it as simple as registering a cert for those and attaching them to the NTDS service?

@@Killerpixel11 Exactly you only need to skip installing the AD LDS Service in the video. The CA needs to have its certificate in the trusted root and trusted intermediate authority certificate stores on each domain controller and LDAP client. This trusts the certificates issued by that CA. Then with the LDAPS certificates attached to that service/port you are good to go. It is fairly simple. It mainly about making sure there is no broken communication before enforcing anything

@@OsbornePro Well then, I know what my monday will entail. Thank you for the replies, this helped immensely.

Thanks brother glad to hear it

Thanks for watching! You can skip installing the AD LDS role and just move on to the certificate assignment

Thanks for watching! There is not a way to automatically manage Linux certificates unfortunately. You could write a script on your Linux devices that automatically obtains the Root CA certificate. Typically Root CA certificates in Linux go into the directory /usr/local/share/ca-certificates and get updated using the "update-ca-certificates" command. Also I typically use dpkg-reconfigure ca-certificates which I feel is easier to ensure your new cert is added because of how visual it is when doing the process manually. The below script should be a good starting place. If you need help refining it just let me know what you need ###### SCRIPT TO UPDATE ROOT CA IN LINUX ######## # # GET THE ROOT CA CERTIFICATE ONTO THE LINUX DEVICE # EXTRACTION METHOD FROM PFX FILE------------------------------------ echo "[*] This is an openssl command to extract the Root CA's from a PFX file if needed (optional)" openssl pkcs12 -in certs.pfx -cacerts -nokeys -chain -out /tmp/cachain.pem -passin pass:"Password123!" # RED HAT METHOD TO GET ROOT CA FROM WEBSITE # Red Hat claims hammer can be used in the below manner to obtain the Root CA from a site. I have not tested this # hammer --fetch-ca-cert server.domain.com # OR DOWNLOAD ROOT CA CERT FROM AN INTERNAL LOCATION echo "[*] Download the Root CA certificate from an available network location or internal site" curl -k server.domain.com/cachain.pem -o /tmp/cachain.pem # UPDATE YOUR TRUSTED CERTS------------------------------- echo "[*] Copy the certificate to the appropriate directory to update your trusted certificates" sudo cp -v /tmp/cachain.pem /usr/local/share/ca-certificates/domain-cachain.pem # Update the your trusted CA's on the linux device sudo update-ca-certificates # VERIFY IT IS NOW TRUSTED--------------------------- echo "[*] Verify the certificate is trusted" openssl verify /usr/local/share/ca-certificates/domain-cachain.pem echo "[*] Test the LDAPS connection" openssl s_client -connect dc.domain.com:636 -CAfile /usr/local/share/ca-certificates/domain-cachain.pem ###### END SCRIPT #######

@@OsbornePro sorry I meant the ldaps on the domain services certificate

Renewing the ldaps active directory domain services certificate. Auto renews, It’s a manual effort right?

Ah sorry. Yeah there is no way unfortunately to auto-renew certificates on Linux from a Windows CA. If you ever find one please let me know. Yes you care correct it is a manual effort. Saying that reminded me I meant to write a PowerShell script to reassign the new LDAPS certificate to the NTDS service. I will post the github link to it here once I write it. Ill try and get that done today or Monday. The LDAPS Certificate will be auto-renewed as long as it is set up to do so

Thanks for watching! Typically you have to point a service to only one LDAPS server, so if you only have one server hosting that it should not be an issue. LDAP stands for Lightweight Directory Access Protocol. It is basically a protocol used by Active Directory services for transferring info about objects in the directory from your Domain Controller. It will always use LDAP. You can disable LDAP on clients by not joining them to a domain and adding firewall rules to block the ports. If you have a directory server and you disable LDAP no clients will be able to authenticate to it if that answers your question. LDAPS is only used for secure LDAP binds which is a simple/basic authentication method for transferring credentials. That happens in clear text so it is a good idea to encrypt any of those communications. Typically you will only be securing like GiT services, web apps, and VPN connections that authenticate users to your DC. Typically all other methods use port 389 and don’t transfer any sensitive info in clear

Thanks for watching, appreciate the feedback! I will definitely take a look at doing a video on that. If you are familiar with a tool called PRET (github.com/RUB-NDS/PRET), you may already know printer languages can be used to execute commands on the printer without the need for a password. This can be used to do things such as reset printers, damage printers, and steal documents. Full disclosure I have looked into trying to lock this down before unsuccessfully. I remember seeing something on only allowing the print server to communicate with the printers using printer language or something along those lines. I was not able to successfully find good information on this. It may be as simple as defining ACLs or firewall rules. I will have to play around to find out for sure. If anyone else has experience with this I would be happy to hear about it. If I am not able to find out how to do that I can at least cover other best practices. I can also say to never have your printer server role installed on a domain controller. An attacker can use unconstrained kerberos delegation to obtain Domain Admin privileges remotely. It will likely be one of the first things they check for once a DC is discovered.

Thanks for watching! You actually are do not need to install the Active Directory Lightweight services role and it will not harm anything to remove it. That was bad information circulating at the time I released the video. You do not need to install that Feature and it can be safely uninstalled. As long as the NTDS service is running LDAP and LDAPS are available. The certificate attached to the NTDS service is required and the clients need to trust the Root CA that issued it. If you are moving to a new DC you will need to request an LDAPS certificate for it and attach it to the NTDS service. Once that is done simply point whatever third party apps you need to towards the new DC.

Thanks for watching! Make sure you are opening the “Certificate Authority” add in in MMC and that you have Enterprise Admin or Cert Admin permissions. That snap in connects to your CA and should show that green check mark. The Certificate Templates tree will be there

Thanks for watching! I will make an updated video for that this weekend for server 2022

Thanks a lot for sharing a lot and exclusive knowledge. Rob i never seen stuff like that. If i am not ask a lot, i have another doubt, if i have 5 domain controller i need to do that in each one? Thanks again...

@@RodrigoLelesMiranda no you really only need one DC with LDAPS I would say. The. You can point third party applications to it that use LDAP Bind requests. I am not familiar with any behavior really where Windows devices make LDAP binds

Rob very thanks for your help

@@RodrigoLelesMiranda No problem thanks!

Sorry for the delayed response I did not realize I needed to approve this comment and thought you it was a post remove because you found the issue. That was my mistake. If you are not able to choose the certificate to request it means the user you are using does not have permissions to request that certificate using that template. Try recreating the template and add your user to the "Security Tab" of the certificate template to ensure you can make the request.

Thanks for watching! The printer is probably older and not capable of using modern ciphers. You may be able to find out what is available by using this cmdlet. You will likely need to enable CBC using Enable-TlsCipherSuite learn.microsoft.com/en-us/powershell/module/tls/enable-tlsciphersuite?view=windowsserver2022-ps This cmdlet shows you negotiated protocols github.com/tobor88/PowerShell-Blue-Team/blob/master/Test-SslOptions.ps1

@@OsbornePro Thanks for your reply. I'll dig into it!

@@leonardoruiz6006 no problem

I actually don’t fully understand what AD LDS role does. My best understanding is it adds some attributes and functionality to Active Directory with the communication happening on the local domain controller. I included it to ensure those communications are encrypted for anyone who wants to set their domain controller GPO setting to require encryption. This way if that setting is configured and the AD LDS role gets added next year there is no broken communication

Thanks for watching! On the Linux client device you will just need to add the RootCA certificate that assigned your LDAPS certificate to your trusted certificates store. Export the root ca certificate in Base64 format. Then save the file into /usr/share/ca-certificates/mozilla Make sure the file extension you use matches whatever is in that directory. I forget if it’s cer or crt. Then run the command sudo dpkg-reconfigure ca-certificates That will trust your certificate and allow you to use LDAPS. This should help you configure the rest www.golinuxcloud.com/configure-ldap-client-auth-ldap-server/ I typically set LDAPS up on both but you can also just use one which is less management to take care of on your part

Hey thanks for watching! Yes it is fine to leave both LDAP and LDAPS enabled. You should actually never disable LDAP because it is still used. The purpose of LDAPS is to secure LDAP binds which send credentials in clear text. You can still choose to use LDAP. Yealink phones for example are not able to trust custom certificate authorities. So to sync an address book to the phone using insecure LDAP binds would be required in that situation. It will not negatively hurt any service

Thanks for watching! Yes you can. Just have to assign each DC its own LDAPS certificate where the FQDN of each individual DC is in the Subject of the certificate.

Hey thanks for watching! My initial thoughts on that would be did you install an Enterprise CA or Standalone CA? Stand-alone CA’s do not use Active Directory directory services to issue certificates. Is the CA server joined to the domain and is the CA root certificate installed in Trusted root and intermediate authority certificate stores on the DC/domain? Can the DC ping the CA and vice a versa? Have you modified RPC or WMI permissions in any way?

@@OsbornePro I think the part that got me was : CA root certificate installed in Trusted root and intermediate authority certificate stores on the DC/domain? I check this morning and it was there and i was able to import my LDAPS cert on both DC. Thanks again !

@@yannickhache643 right on! Happy to help

Thanks for watching! When creating a CA on a server different from your DC you may get an RPC not available error. Typically the reason for this is you need to add the security groups "Domain Users", "Domain Computers", and "Domain Controllers" to members of the "Builtin" Active Directory group "Certificate Services DCOM Access" Make sure you have your DC set as the DNS server for your CA server as well which could also cause that touble

I finally figured it out. My CA root certificate was expired. Once it is renew, I see the LDAP certificate is now available.

Thanks for watching! Right on appreciate you sharing that. My approach would have been checking RPC and Windows Firewall. That did not even cross my mind.

Thanks for watching! No the AD LDS role is not required for LDAPS to work. You are only required to assign the certificate to the NTDS service

Thanks for watching! If you can not use SSO and need to use LDAP for authentication I would set that up as you mentioned. I would have a secondary DC in the DMZ with a port forward on the firewall with a whitelist and ACLs if possible.

Thanks for watching! If you are seeing insecure LDAP Bind requests, it is because the Agent or Firewall is configured to use normal LDAP Bind requests instead of encrypted ones. The steps you mentioned relate to trusting the certificate. You will also need to tell the firewall/agent to use LDAPS. I found this FSSO Agent: community.fortinet.com/t5/FortiGate/Technical-Tip-Fortinet-Single-Sign-On-FSSO-Agent-SSL-connection/ta-p/210850 KeyStore explorer is a Java thing. Java keystore is only capable of trusting one certificate. The Java Keystore exists because Java does not trust certificates found in the Windows Certificate stores. Windows applications will not know to look at the Java Keystore for trusted certificates. Java applications do not look at the windows certificate store for trusted certificates. You should not need the private key in a separate file. The LDAPS certificate is exportable so you can install it on the NTDS service. You only need export the Root CA certificate and trust that on the firewall. The FSSO agent uses an LDAP dropdown to select your server according to this. This leads me to believe the Firewall LDAP server you create is responsible for the configuration of LDAP over SSL docs.fortinet.com/document/fortigate/7.0.5/administration-guide/460616/fortinet-single-sign-on-agent For your LDAP over SSL configuration, at the below document in Step 2 "2) Create a new 'LDAPS' server in the GUI and select the imported certificate:"; there is an image on how the LDAP over SSL server should be configured. Your "what I did" steps did not mention where you configured LDAPS which makes me think it could have been overlooked. community.fortinet.com/t5/FortiGate/Technical-Tip-Configuring-LDAP-over-SSL-LDAPS/ta-p/189972

@OsborneProLLC Thank you! I'm starting to think using the Keystore explorer to export .cer and .key files for the agent is where I went wrong. All of the cert files I used to import on the fortigate and the agent were exported from the .pfx using keystore explorer. I went back and looked at the fortigate, I do have LDAPS selected in the external connectors setting. I will revisit this Monday and start from scratch with the FSSO.

@@Live4thamuzik right on sounds good. Have a great weekend!

@@OsbornePro Fortinet Support and I were able to confirm that I have the FSSO and DC agent are setup properly to use LDAPS. After doing some packet captures on the FortiGate and the Domain Controller, we can see that all traffic is being sent over port 636. The issue that is causing me to get Event ID 2889 is that when The Fortigate sends "Client Hello", my DC responds with "Server Hello, Change Cipher Spec" instead of "Server Hello, Certificate, Certificate Request, Server Hello Done". Essentially my cert is not being passed in the 3-way handshake. As part of my setup when following this guide, I chose not to install Certificate Authority on my Domian Controller. I elected to spin up a new 2022 server VM in vCenter and only install the role of Certificate Authority on that server after giving it a static IP and DNS name. Is there something I need to do to have the cert passed in the handshake? Web enroll via IIS?? I am starting to wonder if maybe I should install ADCS on my DC as a subordinate CA or start over by having the DC as the CA (even though, I understand it is best practice not to do that.) What are your thoughts? Do you have any recommendations for resources to brush up on my lack of understanding SSL and Certificate Authority? I am hitting a point where I feel like I might need to pay for help to finish this project as I am sure the other SSO apps I used that pass through a SNAT may trigger the same 2889 event.

@@OsbornePro I was finally able to get this working! I went with a 2-Tier PKI (Offline Standalone Root CA server 22 & Enterprise Subordinate CA server 22). RootCA has CRL and AIA extensions pointing to SubCA for issuing, verification, and revocation. Template was made on Subca, I did change some settings though. Key componant to this was Fortinet tries to verify the CA over TLS 1.3. In server 2003-2019 this is not supported. Server 22 supports TLS 1.3 but is is disabled by default. Needed to add reg keys and dword values to enable this followed by a reboot. Verified TLS 1.3 with "IIS Crypto GUI.exe" tool. Had to upload the RootCA.cer file to FortiGate as CA Cert and uploaded the ldapspk.pfx to the Fortigate as local PKCS12 file. Fortigate now is able to verify the CA using the LD DS LDAPS service. Cert is used for Directory Lookup, binds and Application Data on TLS 1.2. FortiClient SSL-VPN uses TLS 1.3 for verification.

Thanks for watching! Yes this process is still the same today. You don’t need to install that Rile and Feature in the beginning. Just need to assign the certificate to the port and trust it on your client. Good luck on your project

Check your certificate templates permissions. If you have more than one domain controller the other possibility is the domain replication needs to happen.

Thanks for watching! If you are trying to connect with a Python script you do not need to enforce anything with group policy. You will need to just attach the certificate to the NTDS service on your domain controller. Your Python script may need help trusting the certificate if you are on a host that doesn’t trust the root ca that issued the LDAPS certificate

@@OsbornePro okay, thank you for the quick response. I will try this when I'm back at the lab tomorrow. Much appreciated!

@@invenorofstaw7570 no problem happy to help

Thanks for watching! When you export the certificate, are you ticking the box to export the private key? If you can not tick that box you may need to re-create the certificate template where you enable the exporting of the private key. Then reassign the certificate to your DC and try exporting it with that box ticked.

@@OsbornePro Useful video. I dont see the "box to export the private key" as an option when Im exporting the certificate.

@@237311 you will need to remake the template on your Root CA and tick the box that says mark key as exportable. Then reassign the certificate to the device. That will ungray that box

@@OsbornePro "mark key as exportable" is not there. How did you download the file .pfx to your local folder? By the way, I've installed Certificate Authority within DC, so DC and Cert. Authority are in the same server. Or should I install them separately on a different server or what? Thanks!

Thanks for watching! I love hearing that right on! SCRIPT: github.com/tobor88/PowerShell/blob/master/Set-NewLDAPSCertificate.ps1 TESTING: At line 16 you can change the -ExpiringInDays parameter in the Get-ChildItem cmdlet from 30 to 365. This will make the script believe the LDAP cert needs to be renewed. CERTIFICATE CHANGES: Changing the LDAP cert will not make any difference to the Windows devices. As long as the Root CA that issued the LDAP certificate is trusted, the LDAPS certificate will work. A Root CA might expire before an issued certificate. Keep the old Root CA certificates in the client trust store. This is to ensure that certificates issued by the Root CA, before their expiration date, are still trusted. EXCEPTIONS: If you utilize Bastillion in your environment as an SSH manager, they use Jetty for web hosting. This in turn uses the Java Keystore instead of the Windows cert store for trusted certificates. Java cant trust a Root CA certificate. Javas keystore only allows you to trust 1 certificate. To use LDAPS authentication you need to import the LDAPS certificate into their keystore. If you have any Jetty web servers and want a line to add to your script/automation that imports the trusted LDAP certificate I can provide you with one. The other exception I have seen before is Alertus. Alertus required importing the Root CA and the LDAPS certificate for some reason. There may be others out there which can be a downside to some open source projects or developers who cant be experts in everything. IMPORT/EXPORT: Originally when figuring out how I could automate reattaching the certificate to the NTDS service I was thinking I would need to renew the certificate in the Computer Personal store, export it to a file, and finally import it into the NTDS store. I was able to simplify it instead and just left those old lines in the script.

@@OsbornePro many thanks for the quick reply. Understood. Keep up the awesome work. Your material trully stands out from others.

@@leonardoruiz6006 thanks appreicate it!

Thanks for watching! Glad it was helpful

Thanks for watching! If you are trying to export the root CA certificate I would suggest following the instructions in the section “Export CA certificate(s) from the public certificate” at the below link. docs.microsoft.com/en-us/azure/application-gateway/mutual-authentication-certificate-management

After you duplicate the template (6:58) and assign your permissions (7:47), you need to tell your Certificate Authority it is a template you want being assigned (9:29). If you have more than one domain controller your replication needs to finish before the template can be assigned (10:32). With your permissions correctly set on your Enterprise CA and your domain controllers successfully replicated to the other domain controllers you will be able to request your certificate. Make sure you are able to request and assign other certificates. If you are not able to request any certificates than the issue may lie in how the Certificate Authority service was set up. Make sure you are using an Enterprise CA that is domain joined and verified as the CA for your domain.

@@OsbornePro I'm actually noticing the exact same behavior Visa reported. After duplicating the certificate with all settings properly set, it does not display in the "new" certificate window or in the certificate template window. I'm trying to run some updates and a reboot to see if this resolves it as this is a fresh CA I stood up a few months ago. So far great video, I'll update if I find the fix!

@@chrismoore8116 thanks for watching! If you do not see the certificate there is either a user permissions issue, a DC replication issue, or either the DC or Root CA don’t view each other as the trusted service for the domain

@@OsbornePro Funny enough, it was just impatience. lol. It took about 20 minutes to show up for some reason but after that I was good to go. Thanks!

Thanks for watching. If you are running the nltest command on a device that is NOT a Windows Domain Controller there may be an issue with the trust or there is something up with the certificate trust on the client. Either of the below commands can be used to repair the trust. nltest /sc_reset:YourDomain.com Test-ComputerSecureChannel -Repair -Verbose # Run on the client device in admin powershell window Otherwise look at the System logs in Event Viewer after you do the above. Look for any events related to secure channel issues, likely with a the source Netlogon. This may help identify what exactly the trouble is.

@@OsbornePro ok thank you very much for your response. I will try to execute the commands. I just forgot to mention that i tried executing the command on a windows 11 in the same network and domain, on a windows 11 in another network (through internet) and on the DC itself. I got the same error in every case. Oh and the DC is also the DNS server

@@OsbornePro but my main issue is how to make LDAP work with iOS because iOS devices somehow dont send bind requests, only search requests from what i see through Wireshark. So i was trying to connect with SSL but apparently the iphone doesn't recognize the certificate. In Wireshark, we can see a "Unknown certificate" error.

@@aliounethiaw1443 if you are not seeing bind requests from the iOS devices they are not trying to perform authenticated searches. They may need an LDAP profile of some sort with credentials specified typically using the distinguished name as the username. An MDM solution will need to be used to push out the Root CA certificate to the devices trusted machine certificate store.

@@OsbornePro so i need to manually register the phone in the LDAP server using the phone's name and a password as credentials, then install the certificate on the phone via an MDM. And then i try to connect using the phone's credentials instead of the user's credentials. Is that what you mean?

Thanks for watching! What are you referring to by auto-enrollment? The Certificates can be auto-enrolled for domain joined computers. Any Windows devices part of the domain can be auto assigned any computer/device certificates. Same thing for user accounts.

Thanks for watching! You will need to add the self signed certificate to the trusted certificate store on the client computer. If the client does not trust the certificate it won’t make the connection. The ldap certificate needs to have a subject name that matches the FQDN of the server.

Hey thanks for watching. Sure thing, You will need - A trusted Root-CA in your environment. - The CA certificate will need to be trusted by all devices that will be using LDAP binds. Windows can push this out through group policy. Network devices and Linux will most likely need you to do this manually and it will vary per service on how that is done. Anything you are using LDAP authentication for in a web app for example will be required to trust the root ca certificate in order to use LDAPS - The domain controller will need Lightweight Directory Services installed from Roles and Features - Assign the LDAPS certificate to your created ADAM service and already existing NTDS service - The DC will need a special certificate template I defined in the video to use for LDAP over SSL. - You may need to open port 636 on the domain controller firewall if it is not open/reachable by clients already I suggest following the steps in my video to ensure you don’t have to do any possible extra work due to oversights. Configure the client devices through group policy to use negotiate signing first. Once you see the clients are authenticating with success change the policy to required for the clients. Check the event logs and/or use the LDAP alert to be notified of which devices and services are still using insecure LDAP binds and follow the services documentation to trust your PKI’s Root Certificate authority before configuring the use of LDAPS on that service or device. Every domain controller in the environment you should configure LDAPS on. Each DC will need it down LDAPS cert to be assigned to the ADAM and NTDS service. In another comment I mentioned some people never plan on forcing LDAPS on their domain controller and only force it on clients. They do this in combination with the alert so they know any time insecure LDAP binds are used. If you are being rushed on the project I would suggest doing that to ensure no communication is prevented until you can safely configure that. You may want port 389 to accept binds for troubleshooting at some point as well however environments that expect stricter security may want this done all the way. That is great, we just don’t want to break any communication. A service can always be reconfigured and in the majority of cases I have seen it is not going to hurt in the way the client devices in an environment can when the forced LDAPS is turned on too early on DCs. Clients will need to be rejoined to the domain if that communication breaks. Services just need to have their config files changes or their web GUI accessed with a local service admin account to change settings in a web GUI. If you have more questions feel free to email me at rosborne@osbornepro.com

@@OsbornePro Hi - thank you for this video, it is very helpful. Similar to the other person's post, we are moving from LDAP to LDAPs. In your reply above could you clarify this statement " Every domain controller in the environment you should configure LDAPS on. Each DC will need it down LDAPS cert to be assigned to the ADAM and NTDS service. " Are you saying if we have 4 DCs , we need to create 4 certs, one for each DC, and import each cert to each other DC ?

@@JHSDurham Thanks for watching! If you are going to be pointing third party services like Cisco AnyConnect or Gitea or Palo Alto towards one of your domain controllers for LDAP over SSL authentication, you will need to perform those configuration steps on at least the one domain controller that will be expecting LDAPS requests. If you have 4 Windows Server DC’s I would suggest attaching an LDAPS certificate to each one. This is for the devices in your environment. If the clients are being required via group policy to authenticate using encrypted communications they will still be able to perform most communication but not all with the other DC’s. If they do something that requires LDAPS it’s nice to still utilize them. You can get by with just one DC configured

@@OsbornePro Thank you for the reply. In our case, we do have 4 static DNS entries, each the same name, but each pointing to a different IP of a DC. In our Apache config file, we point to that static DNS name for the authentication server. This way if any one of the servers is busy or down, it rolls over to another automatically. So with that in mind, based on your reply, we want to put the certification on each server. However, is this 4 unique certificates, or is it 1 certificate, the same one, imported to each of the four DCs ?

@@JHSDurham you will need a different certificate for each host name. There can only be one FQDN in the subject line of the certificate

Thanks for watching! In case you are not already aware and for future readers, group policy settings do not affect Linux machines. There is also nothing to auto manage certificates on Linux devices from a Windows Server. You need to manually trust the root certificate authority on the Linux devices and then configure them to use LDAP over SSL as it's use does not happen automatically. Since the Linux machines are not affected by group policy you can simply change the "require LDAP" setting on your domain controller so it is not required and they will be able to authenticate again. This is because nothing was changed on your Linux devices. Other Windows devices in the domain will still be configured to use group policy. After making that change on your DC, configure your Linux devices to trust the root CA and configure them to use LDAP over SSL. After trusting the Root CA on your Linux device, restart it so openssl is able to recognize the new CA. Test the certificate is trusted using OpenSSL on your Linux client and read the top output results to ensure everything is trusted. openssl s_client -connect dc.domain.com:636 # OR openssl s_client -connect dc.domain.com:636 -CAfile /usr/share/ca-certificates/mozilla/YourCAfileLocation.pem Finally configure the Linux device to use LDAPS which is beyond the scope of this video and will vary based on your distro.

@@OsbornePro Useful video. Please make a video on how to configure Linux devices to trust the root CA, and how to configure Linux devices to use LDAP over SSL. Thank you!

@@237311 for Debian based Linux distro a the comment in this thread is typically what I do unix.stackexchange.com/questions/90450/adding-a-self-signed-certificate-to-the-trusted-list

Yes LDAPS can be used with printer communications. You will need: 1.) To import the Root CA of the LDAPS certificate into the printers trust store 2.) Configure a user account with permissions to query Active Directory in the authenticationsection 3.) Ensure LDAP port 636 with the use of SSL is selected and tell the printer not to perform certificate verification. Certificate verification will only work if a paid certificate from a CA such as GoDaddy is purchased and used with LDAPS which is unnecessary and expensive

@@OsbornePro Dear Osborne.. Thank you very much for your reply. The third step is my printer don't have such a option not to perform certificate verification. How i can go about it bro?

I have seen that before that’s a tough spot. Check the printer documentation just to verify if you have not already and check for any firmware upgrades to see if that will allow you to do what you need to. Otherwise you have a couple possible options. 1.) Use LetsEncrypt and a script to assign a new valid certificate every month. If the printer is too old this may or may not work. I have never tried it. It would also be a lot of work to script an LDAP certificate upload to different apps and such so this may not be a good option. Just mentioning it in case it makes sense to your environment. Unfortunately wildcard certificates don’t match the criteria for LDAPS. 2.) OR Set the client GPO to required and leave the Domain Controller GPO set to None. This will prevent clients from communicating with the DC in clear text. Restrict permissions on the user account authenticating to LDAP from the printer so it is only good for querying Active Directory. It’s a bummer feeling to not be able to fully set that up because of a printer. I have a printer doing that in an environment I manage. I’ll take a look at it tomorrow and let you know if I am able to find anything new I missed that may allow that in case non of the above is a fit for you

@@OsbornePro Thanks Bro !. Blessed. Will give a shot..

Turns out the firmware upgrade was how I fixed the issue in the environment I was thinking of. Sorry I don't have one to play around with. Is there a firmware upgrade to fix yours as well?

Thanks for watching appreciate the feedback!

Have a Snickers and calm down.

@@user-sh5kx8cx5c I was actually calm but it bothers me when "YT experts" are making misleading videos.

Thanks for watching! Yes you are right you do not need to install that role I get asked that a lot. I initially documented my setup process during the time Microsoft was planning to force everyone to move to LDAPS and that role was mentioned in all the blog articles and clearly misunderstood. Installing that service creates a port for LDAPS and the role is easily removed. I do not see any harm. I will add a note in the description and chapter mentioning the role does not need to be installed.

That is how I felt. I did this to help teach myself and reinforce information. I would suggest try doing your own and how you think it could be better and improve the info available in the IT community. If nothing else it helps someone see what they are buying when they hire you.