I need to design an application for internal corporate use. The application must be hosted externally. Ideally I'd like that application to be able to authenticate and authorize against the corporate ActiveDirectory.

However 2 problems here:

  1. Authentication must work even if corporate network is unavailable.
  2. I'd prefer to not replicate ActiveDirectory to an external location for security reasons. BTW is it right concern?

I have a few stupid ideas like having externally hosted "LDAP proxy" which would save credential hashes for limited time. That time should be enough to bring network up. While the network is down "LDAP proxy" checks credentials against local hashes. This idea seems to be too home-made and insecure. Is it possible to implement with ActiveDirectory Lightweight Directory Services (AD LDS)?

If the ideal above isn't feasible is there any 3rd party authentication solution? With account management, password policies, API, etc.

2 Answers 2


The only way to have a secure authentication system for a company that can still function while the corporate network is unavailable, is to not use the corporate network. Consider hosting this service in the cloud, or having a cloud based hot-backup.

Having a copy of the authentication database on each device is vulnerability, and a clear violation of CWE-602. By definition this system is giving a user all of the keys to the kingdom. The database must be accessible to authenticate a user off-line, and at this point an unauthenticated attacker has access to all of the data stored on the device (buss sniffing, attaching a debugger to the authentication process or a cold boot attack, and there are other attacks...).

Attempting to "encrypt the database" is a manifestation of the DRM problem, which has no solution. (The only thread holding up DRM is the DMCA. The DMCA will not protect an insecure database from compromise.)

  • Sure I'm going to host this application + auth service externally (AWS or whatever). The question is how that auth service could be designed? Am I right that you think it isn't possible. I.e. should I use local set of credentials for that external application? Nov 6, 2013 at 0:53
  • @Sergey Romanovsky AWS has datacenters certified to house classified documents. AWS is a great choice for most companies, unless you are worried about the NSA . Hah, then good luck!
    – rook
    Nov 6, 2013 at 0:55
  • I pressed "enter" accidentally. Could you answer the question about external auth service design? How would you do that? Imagine we have more than one application. Should we build >1 auth services (one per app) or should we roll out full blown AD infrastructure externally? What about 3rd party auth solutions? Sorry for stupid questions. Nov 6, 2013 at 1:06
  • @Sergey Romanovsky maybe StackOverflow with an "architecture" tag would be more appropriate.
    – rook
    Nov 6, 2013 at 1:07
  • @Sergey Romanovsky I am a huge fan of OAuth and Kerberos. Perhaps one of these technologies solves your problem and both can be backed by AD.
    – rook
    Nov 6, 2013 at 16:44

Your two requirements are mutually exclusive:

Authentication must work even if corporate network is unavailable.
This means that credentials must be cached on the authentication server.

I'd prefer to not replicate ActiveDirectory to an external location for security reasons.
This means that credentials must not be cached on the server.

So.. pick one. Better yet, throw out the idea completely. Why are you exposing your internal corporate credentials to the external Internet?

Lets, for example, assume that you expose your Active Directory system to the Internet but only for authentication. So, anyone on the Internet could ask your AD server whether or not a username/password was correct, and perhaps get some additonal metadata if it is. So, what's wrong with that? What sort of threats can you think of that you want to avoid?

OK, so now lets change it and instead of asking your AD server whether or not its correct, you ask this external application whether the password is correct, but it somehow by security magic matches against your AD passwords. So... are there any attacks possible in the previous scenario that aren't possible now?

While there are plenty of ways to accomplish what you're talking about, the intervening technology doesn't make the idea any safer. So either accept that you're putting your internal security at risk and go ahead with it; or come up with a different strategy and don't use your internal passwords on an external service.

  • "So.. pick one" Not exactly. AD contains credentials for thousands of users. The app would be used by a dozen of users. If only a dozen credentials would be cached externally it is better than having all of them cached, isn't it? Nov 6, 2013 at 18:04
  • And what for exposing AD to internet. It isn't a core problem here. Corporate network could be unavailable. Just exposing corporate AD won't match the requirements. I need to have a backup cache externally. Nov 6, 2013 at 18:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .