Active Directory Roles and Permissions 2

[krshaikh]

Hi,

I am new to active directory and need some help. I have been assigned a task to authenticate active directory users. Once the user has been authenticated and if he is the admin he should be able to create new custom roles like Store Keeper / Accountants within the active directory. Also I need to add Custom permissions to those roles like Departments/Categories etc. Once this is done the Active Directory users will be assigned to custom roles and the persmissions they have will help them to access certain reports on the server using Reporting Services. I have been able to come up with custom roles creation but creating custom permissions is still stuck. Does anyone has an article, code sample on this. Thanks in advance.

Regards,

- krshaikh -

 

[BoulderBum]

Well, I think there's a confusion of concerns here. Your app really shouldn't create or assign Active Directory roles for security reasons: all of that should be handled through Windows.

After you create and assign roles in Windows, you enter into the realm of SQL Server security. This, of course, is better handled directly through SQL Server role management (your app shouldn't touch it).

Only after you configure security for Windows then SQL Server should you worry about what your application is doing. Specifially, what you'd want to do then configure the app to use Windows integrated security and just pass the credentials through to SQL Server (using SSPI).

That way, all of the authentication will happen automatically through Windows or SQL Server.

 

[Tarwn]

Perhaps I am a little confused here, but you stated that:

Your app really shouldn't create or assign Active Directory roles for security reasons

Could I ask why?

The reason being, I have a web service that ties into Active Directory to allow a large number of web admin sites to authenticate users and group membership for administration capabilities in the various sites. While I could just as easily used SQL Server and integrated authentication, I did not see the point in adding another layer on top of AD and also wanted the capability for users using IE to log in with their own credentials, even if at a computer that someone else was currently logged into.

 

[chrissie1]

I agree with Tarwn.

Your app should do what you want it to do. His wants to create users and roles and then he should use ADSI sdk if I remember correctly or.

Christiaan Baes
Belgium

I just like this --> [Wiggle] [Wiggle]

 

[BoulderBum]

Could I ask why?"

Simply because it could allow a malicious user to compromise your network (instead of reducing reducing the attack surface to just your site).

To clarify, there is nothing wrong with using AD to authenticate users, but it's security suicide to allow web manipulation of network security. Poor practice, period.

Windows security should be handled by Windows. There are relatively secure mechanisms you can use to allow admins to configure security remotely (like VPN, remote desktop, etc.) but you really don't want to open the can of worms that comes with exposing network security configuration through a website.

"I have a web service that ties into Active Directory..."

This is authentication. There's a big difference between letting an application impersonate a user and letting an application change/add a user and add network roles. If you want web-configurable roles, you'd want to opt for forms authentication otherwise a new user wouldn't only be allowed access to your site, but all the other network privileges that come with being a user of such-and-such a role (including, potentially, the ability to read confidential company documents, log on to network computers, install Trojans on machines and more).

"I did not see the point in adding another layer on top of AD"

Actually, the nature of "integrated" security is that it doesn't add any layers. That's the point. You just use what's there (which makes the web app as secure as your network).

Speaking of SQL Server specifically, you need to configure security to stored procedures, etc. somehow, and if you want certain Windows roles to have access to certain database objects, then why not use the functionality already built into SQL Server? No need to write additional code or come up with a custom authentication mechanism.

"and also wanted the capability for users using IE to log in with their own credentials, even if at a computer that someone else was currently logged into."

I can see the usefulness of such a scenario, but, again, this is impersonation. There's nothing wrong with allowing a user to adopt a certain Windows identity (under certain circumstances), but there is a big reason to avoid opening up the configuration of network security to the Web.

 

[Tarwn]

Hmm, while I think I see your viewpoint, I don't agree with your general conclusion.

This is my viewpoint on the issue. I started writing it this morning and got sidetracked by a slew of meetings, so I'll try to sum it back up.

I think we are operating under a few assumptions with your arguments, namely:
1) The web application that assigns roles is accessible from outside the company or there is a weak infrasturcture that would allow an outsider to physically get on an unsecured WLAN, etc
2) The web application can assign network security roles with rights used beyond those necessary for the web apps and beyond those already held by the editing users

Now, I think we can also classify any potential attacks in two very general categories. The first category is for any front door maneuver - ie, someone has gained a username and password through a man-in-the-middle attack, has used social engineering to get a user/pass, works for the company and is hacking internally, etc. The second category would cover all attacks that bypass login protocols, including form spoofing, etc.

The second category is partially protected by obscurity. Provided an outside user can even find it, by requiring authentication in ASP.Net before serving pages the webserver will not be processing any request without a valid login. If someone finds a way around the built-in authentication methods then they stil stall out without getting very far because of the need for AD authentication in both situations to connect to either AD or SQL.

The more dangerous of the two, the first category, has a fatal flaw. Both systems (an AD-only or an IIS-AD-SQL) have already lost as the end user has managed to login successfully, either because they are a trusted user or because they are masquerading as one. Under the assumption that any base user could assign higher level AD permissions from the web application, I agree that we now have a problem. However, the fact that the user can pass AD authentication already means that they have at least limited access to at least this one system which in turn has access to listing other machines on the domain. Depending on how tightly the security for the company is locked down, they may even have the ability to create files in the Inetpub directory or execute VBScript functions. If we instead suppose the network accounts are locked down to keep things like this from happening, than it is equally likely that the developer writing the web app would not be able to give users the ability to assign higher levels of security then their current level. In fact, this actually breaks our second assumption because I doubt the system admins would allow the user to assign roles that have any permissions on the network at all, perhaps actually forcing the developer to use something like group memberships instead.


I also partially disagree that using NT Authentication in IIS as well as data in SQL Server is not adding additional layers of complexity. The NT Authentication portion does not add complexity because that is a basic setting that you would have to set for any ASP.Net application (either disabling, forms, nt, whatever settings). However, adding a SQL Server database to the mix is definately adding a level of complexity as well as an additional point of failure. With a straight ASP.Net and AD implementation you have two major systems that your depending on. With an AD/ASP.Net/SQLServer setup you now have three systems, one of which (SQL Server) also has the possibility of adding a third machine to the mix (if not installed locally), as well as requiring a requirement for an additional backup scheme or addiiton to an existing scheme.


I think in the above situation an AD implementation would be just as safe as an SQL implementation. I did not see a requirement for a user to be able to create other users, only to be able to add roles to an existing user. Personally I like groups as that also gives me an easy way to contact all users of a certain app if it needs changes, etc. Provided the role or group does not give it's users more capabilities and that the web app only allows a user to select new roles from a short list that is validated again on submission (to protect from spoofing), I think that you not only have just as safe a system, but one that is lighter, easier to maintain, and much lighter in requirements.

---

In response to the original question, I have to admit we have run up against problems doing this from .Net as well and have had to fall back on Chrissie's method of using the SDK.

 

[krshaikh]

Thankyou All. You have been a great help. Tarwan your post specially helped a lot. You deserve a star for this.

Regards,

- krshaikh -

 

[BoulderBum]

The second category is partially protected by obscurity"

There is a saying in security circles that goes "obscurity isn't security". A common excuse from developers for poorly implemented security is that a potential attacker just won't know how to get to a page/application (ever seen an app with limited navigational links but no actual credential checks on the page as the "security" model?), but that's an unsafe and unprofessional.

While I think your argument differs somewhat from the intended target of the saying, I strongly disagree with what you're proposing. It's just not solid, here's why:

To make security robust for an application, you should minimize the assumptions, lower the attack surface, limit the privileges of the application, and program for extensibility and maintainability. The problem with having the application add roles is that it doesn't do any of this. You can say the app might be safe if the roles an application adds are low-privileged (a conditional assumption) and if the application is only an internal website (another assumption), but then your application is coupled to a specific set of assumptions.

What happens if IT adds mistakenly adds privileges to the roles your application uses (perhaps because they looked like the real role name they were targeting) unaware of the ramifications it would have on your security assumptions? What happens if, all of a sudden, the network admins want access to their own part of the site (a very plausible scenario) and your app ends up dynamically assigning network admin privileges to users? What if the name of the role to add a user to is passed as a string, and a careless developer makes it assignable from a field or query string variable which an attacker can arbitrarily assign a value to (thus granting himself whatever role desired)? What happens if management decides they want to expose the application as a public website to allow travelling salespeople to access it? Bam, your assumptions crumble and so does the application security because you didn't program for change. Besides, the majority of attacks statistically come from within a company (disgruntled employees, etc.) so you can't just think of potential attacks as coming from outside the network!

To even allow for the application to users to roles in AD you have to give a web application power far beyond what it should have (think "principle of least privilege").

Contrast this with leaving security to the network admins and simply hooking website privileges into the existing security model: if you want only users in the "Sales" role to access part of the site, no problem, you just restrict sales people to parts of your site with easy mechanisms like IPrincipal.IsInRole and Web.Config <authorization>. If the admins add privileges to the "Sales" role to view sensitive company documents, who cares? For the purpose of your application, you have only read-access to roles so the actual configuration of network security behind the scenes is none of your concern (as it should be).

Do the network admins want access to their own section of the site? No worries, you can safely add that capability with no fears because you never add roles to your application, you simply let Windows pass the security token through!

What if a developer carelessly uses a query string to glean role info to access part of a site? Well, at least the damage is limited to your application and you didn't expose the breach network-wide because you reduced the attack surface.

The "let Windows handle security" approach means fewer assumptions, lower risk, and therefore increased maintainability and higher security.

"I also partially disagree that using NT Authentication in IIS as well as data in SQL Server is not adding additional layers of complexity"

Well, I'm not sure we're on the same page here because I don't see how the approach I'm talking about could result in more code/heavier requirements.

The developer wants to connect to a SQL Server database (to retrieve data) and he wants to restrict access to the database based on certain roles. He can either:
1. ...configure the database to use Windows (AD) security, then restrict access to parts of the database (tables, stored procedures, etc.) based on Windows roles (a configuration that requires literally zero code for database security when using Windows security on an application level and using SSPI for the DB [SSPI, btw, is widely documented as the strongest security mechanism for data access]).
2. ...code a custom security layer to map roles to database privileges which are persisted somewhere or another adding to both coding/ debugging time, and introducing a proprietary security configuration which may not be as widely understood or potentially secure as Windows security for SQL Server.

I think you're thinking I'm talking about coding a custom security layer where credentials are stored in SQL Server (approach 2) when actually I'm proposing that he configures access to SQL Server using Windows roles (approach 1).

I would agree that approach 2 is more work, which is precisely why I think the developer should configure the database security to look to Windows roles so there's no additional code involved for security.

 

[Tarwn]

I apologize for not responding sooner, I have been out of town on a much needed vacation. Also, sorry to the original poster, we seem to have hijacked your thread

I definately agree with several of your points. Minimizing the profile of the application, limiting it's priviledges, etc. Maintainability and extensibility don't really apply directly to the authentication issue, but are always assumed targets in my book. I'm allergic to one off apps, because even a one off app can be documented and dumped into a code library as an example. It was probably not a good idea to mention the obscurity portion, it was more of a side thought at the time. By no means do I think an app should ever depend on obscurity, in this case it would require authentication no matter what page was hit first.

Now, I agree that it is possible that an IT user could mistakenly assign extra rights to a role being used for the website. No one is perfect, but we can minimize the chances of this. I am not an AD expert by any stretch of the imagination, but if we were using groups to define access and also allow us to contact all users of a specific group at the same time, we could easily nest these groups, provide descriptions, etc to minimize the chances that a user would unwittingly receive additional access priveledges. On a side note, if IT is going around giving role permissions on a best guess principle, we likely have much deeper problems than the possibility of someone getting in through the website.

The passing of a string method you mention is a danger that has been around for a while, due to form spoofing. It appears I removed it from my previous post when I rewrote it, but I originally suggested checks on the submission page (or in this case, in the onClick event) to make sure that a passed value was one of the allowed values. As I am sure you know, its never a good idea to trust any user input without double checking both it's type and content validity. This helps protect against both accidental or less than intelligent submissions as well as form spoofs.

To even allow for the application to users to roles in AD you have to give a web application power far beyond what it should have (think "principle of least privilege").

I agree wholeheartedly. The best solution is to make use of existing groups for access, allow the admins to do their jobs, etc. Unfortunatly the point we started with was determining a safe method to allow users (admins) to assign roles/priveledges from inside a web application to external resources (in this case reports).
As far as travelling salesman are concerned, they don't need external access. I wouldn't even put an application like this on a system that can be accessed externally. It is simply a tool to manage a subset of what the full blown AD tool can manage. If management does request you to put up the management tool as an externally accessible resource, it's time to polish up the resume.

The additional complexity in the SQL model I am commenting on is not complexity from a developers standpoint. Complexity from the developers standpoint can be an issue (as it leads to greater possibility of error) but the complexity I am concerned with is the functioning end system. In the end, whether we write the code or not, we have more systems involved in the mix. On top of that, the users now have access to the database for which there have been a large number of vulnerabilities displayed over the years, some conveniently packaged into tools. By your own argument we cannot assume that obscurity is protection, so a user could directly access the database, at which point they then have a number of possible routes to gaining access to admin level applications directly on the server, a beachhead if you will.

In the end, the purpose of the proposed tool was to assign AD permissions so that users would be given permissions to resources like reports. So we are actually talking about two differant sets of authentication, those being assigned and those necessary for accessing the tool in the first place. It was your argument that we shouldn't create a tool that can manipulate AD in this manner, that instead we should be using Windows Authentication and SQL Server to grant access to specific tables/stored procs/etc. Where do those Windows groups come from that are being assigned permissions in SQL Server? Will we be first creating them in AD manually or will they be local groups on that speciifc server? Do we assign these roles manually or create a tool to manage these similar to the proposed AD management tool? How many databases do these reports pull data from? If we are lucky and it is only one or two databases, will we ever have reports that access differant dbs in the future? Will we then manually grant access to tables and stored procedures in every database that is accessed by a report? How is this differant from creating a tool to do it more easily with a more limited set of capabilities then enterprise manager? Or do we create a table in SQL Server that manages access to the reports (perhaps by crossreferencing windows groups with links) and query that before supplying a link to a report? How, exactly, do we figure out who has permission to what? At this point, haven't we created our own extremely specific directory service that doesn't tie into integrated windows authentication at all? I agree that SQL Server should be locked down, but I do not believe it should be the primary controller of access.

You can say the app might be safe if the roles an application adds are low-privileged (a conditional assumption) and if the application is only an internal website (another assumption), but then your application is coupled to a specific set of assumptions.

Every application has built-in assumptions. Even if those assumptions are less obvious or less dangerous, then are still assumptions. I agree it is our task to minimize these assumptions, but there is a point of diminishing returns. At the same time, is it not an assumption that the DBA will never assign greater permissions to a role or group, perhaps thinking it was a differant one? Will all of the applications that need access restrictions fail gracefully when they get access denied errors (or will they spit out very specific error information and expose internal database information to the world)? Are we not assuming that no one will be lazy enough to grant unconditional access to a database rather than step through 30 groups of people assigning very specific permissions? And are we not assuming that by not creating a production level application, that one of the IT guys will not hack together their own tool to manage these things?

My suggested route would be to create this management tool as a completely seperate resource from any websites that serve reports, etc. Use AD to authenticate that a user logging into it has the appropriate level of permissions to make modifications. If you absolutely must allow non-IT users to access the tool (by perhaps having one member of each department have the capability to manage who can access their departments reports/etc) then lock down creation of new groups or roles to an admin level group (like Domain Admins) and create a secondary group that will be allowed to assign users to a subset of groups. My logic behind this would be to allow Domain Admins to add group/role names to a SQL Server table. When a non-Domain Admin logged in that was in the secondary group they could then assign/remove users from any group in the SQL table that they themslves were also members of. Maybe add in some protection to prevent people from removing themselves from groups, as I know some user would end up doing that once a week.

 

[BoulderBum]

Hope your Thanksgiving went well! The vacations are never long enough!

Anyway...

"Maintainability and extensibility don't really apply directly to the authentication issue"

I think they do insomuch as you say "this is only safe if...". Not that I would personally recommend using the security model anywhere, but I think you'd clearly never wish to expose the application to anything but a local intranet, and you therefore make the application resistant to change because it becomes a huge liability with more public exposure. Alternately, taking a read-only approach to role information frees you up to allow more public access with fewer fears.

"By your own argument we cannot assume that obscurity is protection, so a user could directly access the database, at which point they then have a number of possible routes to gaining access to admin level applications directly on the server, a beachhead if you will"

Not so. They're limited to the functionality you grant them permssion to, so if you only grant them execute access to stored procedures, they can't do anything but run them which they could presumably do through the application anyway if you granted the user/role specific access to database objects.

"Do we assign these roles manually or create a tool to manage these similar to the proposed AD management tool?"

Nah, that would be reinventing the wheel and would be a waste of coding time. You'd just use the pre-made, robust tools already available (like Enterprise Manager). Sure you have to go through the trouble of deciding how to assign permissions, but that's something you'd have to deal with no matter what the approach or tool. The question, then, is if you want to rewrite your own custom tool and expose (perhaps dangerously) that capability through a web application, or just use what Microsoft already made/ make a T-SQL script.

My suggested route would be to create this management tool as a completely seperate resource from any websites that serve reports, etc. Use AD to authenticate that a user logging into it has the appropriate level of permissions to make modifications.

Actually, I can see the merit to that approach. It allows you to restrict the ASP.NET worker process to a less privilaged level, but also gives a customized management interface. Again, I'd wonder if it would be much better than just using Enterprise Manager or something, but I think it's has a big advantage over giving the web app so much power over the network.

 

[Tarwn]

Well, I think my point on the management tool direction was that I know of several of my co-workers that I would prefer not using a tool that allowed such freedom. Perhaps I am projecting some of my needs on what the original poster was asking, but I would be extremnely happy if I could give some of the lower level techs a limited, easy to use interface to manage users and groups in AD (or if we were doing it with SQL roles, then a minimal interface for that) rather than allowing them to have a tool that I have no ability to lock down to the degree I would like to.

My point on the maintainability and extensibility wasn't that there was no place for them in this app, just that they were a little further outside of the scope of what we were conversing about, ie the better method of AD vs SQL. Granted they come into play when you apply restrictions to the software model, however you can still apply restrictions internally to your software but code in such a way that the restrictions can be either removed or replced easily in a later version (if necessary)...of course I would put big fricking comments next to those functions on why I thought it was a bad idea and what I would do to anyone removing them as a temporary solution to some unrelated problem, but thats why my coworkers like me

In an attempt to shorten my previous post I moved some stuff around. The issue I originally tied to allowing users to login with their own id's was that someone could accidentally (or lazily...er sp?) give them write access to a whole db assuming the software would restrict their access. Obviously a very small chance that it owuld happen and be taken advantage of, but similar to the level of competence of your sample IOT person that was assigning extra network rights to AD roles in previous posts.

About the approach - again, I think I was projecting a little. We have had to many incidents of lower level IT users doing things in the AD interface that they shouldn't have been able to do. Like the day one deleted the admin account that every legacy app depended on, then re-added a new user with the same name ion the hopes that no one would notice (we're slowly rebuilding about the largest number of custom, flaky, legacy apps I have seen in a small company - and that week all of them stopped working). Personally I like using the AD tool and enterprise mangler, but with a custom piece of software you have more flexibility and can demand the user fulfill entry requirements that are more stringent then what are required by the big apps (ie, things like business rules and deifned common practices).

Anyways, a very enjoyable conversation and you made me research several things I hadn't looked into enough lately.

-T