If you do go ahead with this put in extensive monitoring of the user ID that they use to access the Directory. If possible have all connects restricted to a single OU as well. I would in addition have some kind of reporting in place to report all connections to your directory.
Jon On Fri, Nov 20, 2009 at 3:12 PM, Mayo, Bill <[email protected]> wrote: > I could possibly live with the SSL encryption of the traffic if it was a > short term situation. You could probably make an argument that the VPN > connection isn't signficantly more secure than LDAP over SSL, but the VPN > connection gives you an extra layer of authentication. > > Is it an option to just have a secondary authentication on their box? I > know and understand that multiple usernames/passwords isn't desirable, but I > personally haven't run into a situation where a 3rd party wanted to > authenticate against our domain from their server. > > I'm sure that there are folks that know more than I do, but I would offer > the following potential security issues (that come to mind at the moment): > > - IP addresses can be spoofed and someone could run an attack against > your DC. Depending your lockout policies, they could detect > usernames/passwords and/or lockout accounts. They could also do some kind > of DOS attack. > - A disgrunted employee at the 3rd party could take action to capture > your usernames/passwords (at least there is some possible remedy for that). > *This one is a potential issue no matter how you secure the connection. > * > > The bottom line is that you are opening a port directly to a domain > controller over the internet. Make sure you point out the potential > issues. If the powers that be decide to go-ahead, you have at least done > your duty to warn them. > > ------------------------------ > *From:* Chyka, Robert [mailto:[email protected]] > *Sent:* Friday, November 20, 2009 2:56 PM > > *To:* NT System Admin Issues > *Subject:* RE: Cisco Question > > Thanks for the great points!! So if we can’t get a VPN setup, would you > fight to kill the project or would you trust the SSL cert encryption? > > > ------------------------------ > > *From:* Mayo, Bill [mailto:[email protected]] > *Sent:* Friday, November 20, 2009 2:54 PM > *To:* NT System Admin Issues > *Subject:* RE: Cisco Question > > > > I think opening port 389, even restricted by IP, over the internet is a > non-starter. That means that the logon credentials are being sent over the > internet in the clear. Make sure you insist on the SSL variant, although I > would note that I personally wouldn't even be happy about that. I would > much prefer some kind of VPN setup directly to the box, if possible. > > > ------------------------------ > > *From:* Don Ely [mailto:[email protected]] > *Sent:* Friday, November 20, 2009 2:27 PM > *To:* NT System Admin Issues > *Subject:* Re: Cisco Question > > create an ACL allowing only access from their IP address to your NAT'd > address. Also, I'd put an SSL cert on your AD servers and use 636 > instead... > > On Fri, Nov 20, 2009 at 11:25 AM, Chyka, Robert <[email protected]> > wrote: > > Hello, > > > > We have a Library Catalog server that is hosted by the company that we > subscribe to their databases. It is a server dedicated to our school, but > hosted in their data center. They need to have LDAP access from their > outsourced box to our internal AD Controllers for LDAP authentication for > our users to the database server. > > > > Our AD servers sit behind a ASA Firewall. How would I set up the rule to > allow port 389 to be open for the IP address of the outsourced server? > > > > Any help is greatly appreciated. > > > > Bob > > > > > > > > > > > > > > > > > > > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
