Member Server in DMZ - How to authenticate back to the domain?

I need to set up a member server in the DMZ that will be running a SQL server and a SFTP server.

There will be local accounts on the member server for the customers that are dropping off / picking up files off the SFTP server, but the customer wants the employee accounts on the server to be authenticated back to the windows domain they are running - because the (l)users are too dumb to remember two different accounts and/or passwords.

I know a DC in a DMZ is not smart so I started looking at a RODC, but you have to turn the NAT'ed connection between the office network that has the DC and the DMZ into swiss cheese to get it to work. Will AD-LDS work where I can put the member server into the domain and accomplish my goals and maintain security? The server is already a member of the domain and they already have the SQL server running using domain accounts.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Oleksiy GaydaCommented:
LDAP over SSL should indeed be the best option (unless you want to pursue deploying a RADIUS server) and it's easily configurable on the firewall (you just need two ports - TCP 636 and 3269). If you do want to check out the RODC, there is a good whitepaper from Microsoft on that as well. Personally, I wouldn't go the RODC route, the thought of having a cached copy of your AD SAM in DMZ, where someone can potentially get a hold of it and run it through a password cracker, makes me uneasy.
btanExec ConsultantCommented:
AD LDS can be considered as a standalone AD local to this specific external deployment use case with specific local user authorised for access to those apps and system request. Let LDS proxy between internal user from AD DS backend (not exposed) which holds your full trust in user identity store, and external apps access which is populated with instances of "external" users or partner or public account identities.

In other words, LDS serves as an extranet authentication store. AD LDS is then be used simply as an application-specific data store. The SQL systems and FTP should use AD LDS accounts for external user access. You should not expose these system directly into public access too.

Having said that, managing identity across store need some planning too. E.g. If your application or services cannot authenticate against AD DS directly since they are outside or restricted from access due to security policy btw DMZ, you still need to support synchronize directory contents between AD LDS and your backend AD DS. You like to go for a synchronization service, such as Microsoft Identity Integration Server (MIIS) as your trusted service to mediate such synchronization. This can have some latency incurred though not significant since it within internal n/w (hopefully not cross WAN or remote side).

Also as advised earlier, maintain LDAP over SSL (LDAPS) on a stand-alone AD LDS, though it can extend to SSO but it depends on your use case. Keep it simple.

RODC is good and secure (e.g. create a new forest in DMZ and establish forest trust with the forests in the internal network) as it serve only and only what role it is given, but can be restrictive (e.g. increased administration costs of maintaining an extra forest and the added complexity of managing firewall rules cross trust boundaries) if you plan for scale up or further integration. You need more granular filter control of credential attributes to reduce exposure such as use of Filtered Attributes Set (FAS).

But I see this is one off and dedicated purpose (read-only copy internal AD DS if replicate is planned forth) as shared. I still do think we need not exposed "all" identities e.g. passwords, credentials, or encryption keys "replicated" and stored on an RODC can be lost, in case (worst case and probable too) in view, RODC is really compromised since it is "outside" to public access even though they are still "read-only" attributes.

Overall, just has to weight pro and cons of RODC and AD LDS which i prefer the latter though. AD LDS also has cons as it will not be full exact copy of your identity store and apps specific with much sync to be done. ALso do not neglect to maintain strict tier boundaries checks by the proxy of maybe TMG or proxy FW where possible. The VLAN segments will still applies

For info, Cerberus SFTP server with AD LDAP etc support - may be worth looking into too...

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows OS

From novice to tech pro — start learning today.