Active Directory Security Advice/Insight For Intranet Application

Question

I have been tasked with coming up with the authentication/authorization for an enterprise intranet web application. The requirements I were given were:

1. Must authenticate against Active Directory
2. All Active Directory password requirements must be the same as that is in AD
3. The authorization within the application must take place OUTSIDE of AD. Locking/unlocking users should still take place with AD via a Support team.

Originally what I did was authenticate against LDAP with the users provided credentials in which the user would get locked out of the APPLICATION only after x amount of attempts (NOT AD). I am now being told that if the user fails to login after x amount of times, they should be locked out of ALL APPS and ALL ENTERPRISE connections (essentially logged out/force signed off of Windows). My feelings are the following:

1. It sounds like we are trying to have our cake and eat it too. We want to use AD but at the same time we don't as in the actual authorization takes place outside of it. I don't see what the purpose of this is. They seem to be trying to use SSO but at the same time aren't.
2. I don't see why this should lock the user outside of the the entire network. To access the site, the user must first be signed in over VPN (already logged in on Windows and through the VPN with 2FA). They then are required to login to the site again with their Windows password only. I don't understand the security benefits of doing this.
3. ANY user could type in whoever user they wanted to and lockout everyone from their accounts from this website. So in theory I could type in the CEOs AD name and just type in the password into the application to lock them out of the entire corporate network.

Is there any rationale for the requirements I am given that makes sense from a security standpoint? Should invalid logins to an application be something that locks something out of a Windows account especially when any user on the network can access the application? Please help me understand the pros/cons of both approaches. I understand neither are "ideal", but I don't think the one I am instructed to make is appropriate.

Answer 1

This seems like a fairly typical scenario. I assume you're hosting an ASP.NET app in IIS. In that case, simply configuring your app for Windows authentication would take care of all three requirements, except for the authorization bit in requirement 3. For that, you would typically code your own authorization scheme that involves storing user roles specific to your requirements in your app database.

You may be confusing authentication and authorization. The former is the process of verifying the user's identity, whereas the latter is the process of verifying the user's specific access to various resources. Your requirement is to use AD for authentication only, and this again is typical. Organizations apply lockout policies in AD to lock out accounts that have undergone multiple unsuccessful login attempts anywhere in the environment. This has nothing to do with your app, except that the policy would be enforced there as well--because why should your app behave differently than other apps in the system? This is handled by AD and your app need not worry about it. As far as authorization, that would be handled entirely by your app, and you can code logic that decides what (if anything) the user gets to do with your app now that AD has let them in.

To respond to your specific points:

1. Why not use AD for authorization? You can do this, as by creating AD groups corresponding to roles in your app and having your app read from them. But some organizations may prefer not to clutter AD with ad hoc groups created by myriad apps that they don't control.

2. Why should bad password attempts within the app lock users out of the network? Why should the app even prompt for a password? Even though it's an intranet app, it would theoretically be possible for a malicious insider to access your device after you have logged in to Windows and left your desk. That said, if your organization allows it, you can configure your app for integrated Windows authentication (SSO) so that users get logged into your app automatically once they have successfully logged into the network.

3. What's to stop a bad actor from locking out accounts deliberately by entering bad passwords? Not much, although sys admins have various tricks they can employ to help detect and defend against this type of attack. But this is an AD concern and not a problem that would be specific to your app. Any app on the network could potentially be used for this.

I do think there is a case to be made for every app enforcing a lockout after bad password attempts. It helps protect against the case mentioned above involving malicious insiders. It's also an extra layer of security in the hypothetical case where a bug or misconfiguration may in the future expose your app to the internet. Far-fetched perhaps, but possible. Whether or not it makes sense in your scenario comes down to data sensitivity and the appetite for risk tolerance in your organization.