llarava
asked on
Looking for ways-to-integrate in premise ad-with-saas-apps
Hello,
We are looking for ways to integrate our local AD with a saas application (Zixs). This is a mail filter solution that will be used to filter inbound/outbound mail flow. The users will have a site that they will use to authenticate to release their spam. We want them to use their AD user and password to authenticate to the site and get to their spam. The vendor mentioned they support LDAP and secure LDAP but I am not sure what my options are to get this integration done.
We use on premise AD running on windows 2012 DCs.
Thank you!
We are looking for ways to integrate our local AD with a saas application (Zixs). This is a mail filter solution that will be used to filter inbound/outbound mail flow. The users will have a site that they will use to authenticate to release their spam. We want them to use their AD user and password to authenticate to the site and get to their spam. The vendor mentioned they support LDAP and secure LDAP but I am not sure what my options are to get this integration done.
We use on premise AD running on windows 2012 DCs.
Thank you!
ASKER
I am looking for a way to avoid Azure. I would like to use secure ldap and read only DC in the DMZ. Anyone has done this setup before?
ASKER
The customer would like to leverage their existing DMZ and infrastructure.
I am looking for a way to avoid Azure.Second part of my comment is not Azure
I would like to use secure ldap and read only DC in the DMZLike published externally? Don't do that
ASKER
Sorry for the editing zixs saas supports secure LDAP.
ASKER
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
I have Mimecast for my solution and I use LDAP setup between the my on-prem AD and mimecast.
I have my firewall ACL to only allow communication from Mimecast subnet.
LDAPS is a preferred method if you can support.
If your service does support ADFS for SSO I would look into setting it up.
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs
I have my firewall ACL to only allow communication from Mimecast subnet.
LDAPS is a preferred method if you can support.
If your service does support ADFS for SSO I would look into setting it up.
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs
I have Mimecast for my solution and I use LDAP setup between the my on-prem AD and mimecast.Correct, but their main integration points are ADFS and Azure AD. I will never run LDAP(S) over the Internet.
I will look into this. Thanks Shaun.
ASKER
Why LDAPs is discouraged? Just asking to understand the cons
LDAPS is secure by default as long as proper ciphers are negotiated. Even SSL has weak ciphers. But the whole idea is to reduce exposure of your entire AD DS to the Internet.
Nothing is silver bullet so if the AD is compromised due to lapsea or misconfigurations, the privileged access gained will give chance to penetrate through the internal. It is all about risk acceptance. When something really happened and user ia alright to manage the aftermath it is fine but most if the time they are not.
Connection to Internet from remote should always consider VPN and expose portion of the internal AD that really need to be use rather the entire AD DS. External threat to DDOS attack against LDAP/S is viable and service outage may be part of it.
Nothing is silver bullet so if the AD is compromised due to lapsea or misconfigurations, the privileged access gained will give chance to penetrate through the internal. It is all about risk acceptance. When something really happened and user ia alright to manage the aftermath it is fine but most if the time they are not.
Connection to Internet from remote should always consider VPN and expose portion of the internal AD that really need to be use rather the entire AD DS. External threat to DDOS attack against LDAP/S is viable and service outage may be part of it.
LDAPS is secure by default as long as proper ciphers are negotiated. Even SSL has weak ciphers. But the whole idea is to reduce exposure of your entire AD DS to the Internet.There is a big difference between transport security, protocol security and exposure. With HTTPS you can reverse proxy the HTTPS traffic. With LDAPS you are literally exposing your DCs to the world. No one will ever be able to convince me to use it when technologies such as AD-FS, OAuth, AD Azure etc. exist
Indeed the known port for LDAPS is an obvious target. Web proxy or broker is needed and it should even be application aware to manage the access using the SAML or OAuth token. These are preferred for online identity federation with more API interfaces released for greater application eservice method call.
ASKER
Could you please advise on a a good ADFS implementation document that I can use to test it?
My link walks you through the steps.
This is what I used to implement my ADFS and Web Application Proxy.
This is what I used to implement my ADFS and Web Application Proxy.
This is also a good one directly from Microsoft.
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/set-up-the-lab-environment-for-ad-fs-in-windows-server-2012-r2
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/set-up-the-lab-environment-for-ad-fs-in-windows-server-2012-r2
Another on some key points summarized
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/design/best-practices-for-secure-planning-and-deployment-of-ad-fs
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/design/best-practices-for-secure-planning-and-deployment-of-ad-fs
ASKER
Ok
You can alternatively use an internal site (which you can publish externally with something like WAP) and change authentication method of the site to LDAP similarily to My Free/Open-Source Self-Service Password Reset tool for Active Directory (Look at the web.config)
https://www.experts-exchange.com/articles/31477/Free-Open-Source-Self-Service-Password-Reset-tool-for-Active-Directory.html