Jump to content

Recommended Posts

Posted

Hi folks,

I have signed up to a web service which has it's own authentication system but is moving over to AD authentication. I would like to move my school over to the AD authentication, but the service provider isn't using Federation Services, and is instead suggesting that one of my AD servers should have a public IP address so that they can use LDAP to read authentication data. Is this normal? I've never even considered giving one of my AD servers a public IP address, as the security implications slightly scare me.

Some feedback on this would be greatly appreciated.

Cheers

Posted
Be wary. I write a lot of PHP code that interfaces with LDAP and its easy to get a connection without even binding, imagine someone running a script that connects to your LDAP and tries to bind 1,000,000 times?
  • Thanks 2
Posted

NO!

 

Exposing a DC to the public\internet is not a good idea. This leaves the host vulnerable to exploit and attack and with the high number of Microsoft vulnerabilities and exploits available I wound strongly suggest you re-consider. I suspect that the vendor would require a web service to run thus allowing for potential MITM and SQL Injection attacks. IIS is very vulnerable, even Microsoft use Apache!

 

Also take into consideration data protection and what would happen if sensitive\personal data when missing from the DC?

 

Matt

  • Thanks 1
Posted

That is a truly terrible idea. Really truly terrible.

 

If the company wish to connect to LDAP, they should either have a VPN connection to the server in question, use ADFS or have their own agent doing the intermediary bit.

 

So, my answer would be NO! NO! NO!

  • Thanks 1
Posted (edited)

We have two external services which connect to us over LDAPS, our email filter and our Office 365 federation service. However, the DCs not connected directly to the tubes; we are using our SonicWALL as a publisher for them. They are also locked down to listen only from specific IP address ranges. If anyone on a different range tries to connect they're shut off.

 

IIS is very vulnerable, even Microsoft use Apache!

 

Utter nonsense. Modern versions of IIS are no more or less vulnerable than any other web server. Microsoft don't use Apache either but some their peering services do.

Edited by Norphy
  • Thanks 2
Posted (edited)
IIS is very vulnerable, even Microsoft use Apache

 

Umm, you are right about not exposing AD, if it was absolutely required with no other way available I'd firewall it to only be accessible to the providers IP but totally not a good idea, ADFS and ADAM were designed and built for a reason.

 

As to MS running Apache, maybe on a few sites but not on their main ones Which Web Server Does That Web Site Run On? and ISS was left unscathed by stuff like heartblead which wholesale compromised almost all Apache installs. As with everything a lot of it is down to patching and configuration.

Edited by SYNACK
  • Thanks 2
Posted

Utter nonsense. Modern versions of IIS are no more or less vulnerable than any other web server. Microsoft don't use Apache either but some their peering services do.

 

IIS combined with a windows OS is not great in terms or security especially in a public facing environment (you should see the results of penn tests). In terms of your "Utter Nonsense" comment neither did I say Apache was any better than IIS in terms of vulnerabilities. This was purely to point out a fact that Microsoft do use Apache servers in some instances as well as there own product and that there are alternatives to Microsoft products available.

 

Sorry for offending a Microsoft fan club member.

Posted (edited)
We have two external services which connect to us over LDAPS, our email filter and our Office 365 federation service. However, the DCs not connected directly to the tubes; we are using our SonicWALL as a publisher for them. They are also locked down to listen only from specific IP address ranges. If anyone on a different range tries to connect they're shut off.

 

Office 365 doesn't use LDAP's :) - It either uses DirSync Password Sync or ADFS.

Edited by FN-GM
Posted
Office 365 doesn't use LDAP's :) - It either uses DirSync Password Sync or ADFS.

 

We are using Federate 365 for authentication with Office 365. This is essentially a hosted ADFS service. To sync data with them, they are using LDAPS.

Posted

Wow, thanks for your responses so far. I have expressed my reluctance to the service provider and the response was:

 

Your AD server should be accessible to us through a specific port on a public IP address. To avoid security issues we recommend the following :

- limit access to that port and IP address to the specific list of IP addresses we have provided you through your firewall configuration

- ensure that the user you provide us with has only read rights to the AD server

- ensure that you have SSL mode on so that any traffic between our servers is encrypted

 

I'm still not convinced. Your thoughts?

Cheers.

Posted
Wow, thanks for your responses so far. I have expressed my reluctance to the service provider and the response was:

 

Your AD server should be accessible to us through a specific port on a public IP address. To avoid security issues we recommend the following :

- limit access to that port and IP address to the specific list of IP addresses we have provided you through your firewall configuration

- ensure that the user you provide us with has only read rights to the AD server

- ensure that you have SSL mode on so that any traffic between our servers is encrypted

 

I'm still not convinced. Your thoughts?

Cheers.

 

It's better than leaving a DC wide open to the internet but it's still a really bad idea imo. They need to get with the times, to be honest: There are lots of better solutions out there and (regardless of platform) exposing your internal central authentication provider to directly to the outside world is never ever going to stop being a bad idea.

  • Thanks 1
Posted
Ok, I can't actually believe that I'm entertaining this idea, but I'm considering building a core installation 2012 R2 Standard server with read only AD and giving that the public IP. The server will be protected by its own firewall, the Grid's firewall and Symantec AV. I think this is as much as I can do to minimise the risk.
Posted

Ok if they must have access to an internet accessbile "ad" you need to setup a directory server in a DMZ and push user changes to that security would be configured to only allow these changes to come from the IP's of your internal AD servers and then their service can auth against this server.

 

Ben

  • Thanks 1

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 account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...