|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Windows Security RolesWe are creating a application where we until now has been using AzMan for authentication. We are now looking at alternatives, because we have some problems with AzMan, eg ClickOnce, Windows 2003 AD Domain level. We think that we are able to shift to only be using AD Security groups, without having to create 1000 groups. But what is best practice here? 1) Does the applications normally create the AD groups duing installation? 2) Do you normally let the users map existing groups to your handles? 3) Do you group the groups in a new ou? 4) How many groups is to many? 5) How does Microsft CRM do it? 6) Any good examples? Thanks Henrik Skak Pedersen. Hi
I agree, there are issues with using AzMan for this. Using nested groups, the group membership is flowed when delegating. Also, using AD there's no need for a separate API - just use the User.IsInRole method (if this is a web app). AD groups are created at the domain level, so it would probably be better to create them separately, rather than during application install. If your application uses load-balancing, you wouldn't want to install the groups each time. Having one layer of groups relating to permissions would possibly lead to spaghetti code, eg: if (User.IsInRole(roleA) | User.IsInRol(roleB)){} It is useful to allow nested groups, and have a heirarchy of users, user groups, role groups, ending with permission groups at the top level. This is similar to AzMan, but using AD nested groups. The extra layer of user groups allows administrators to map users to groups, and then add these groups to your role structure. Here's a white paper that discusses this, giving details for implementation. Much of it is based on a very large enterprise-scale application that I worked on with Microsoft: http://www.charteris.com/publications/whitepapers/default.asp The paper is entitled 'Security Solutions Offered by Visual Studio .Net 2005'. It would be useful to place the new groups in a new OU - easier to maintain. When you're writing scripts, it's good to be able to just delete the OU (only do this on a development machine). Try this structure: Application OU |---------RoleGroups OU We used hundreds of groups, and AD can cope with thousands.|---------PermissionGroups OU We used Windows scripts to create the groups - use the ADSI methods. Hope this helps Chris Seary Show quoteHide quote "Henrik Skak Pedersen" wrote: > Hi, > > We are creating a application where we until now has been using AzMan for > authentication. We are now looking at alternatives, because we have some > problems with AzMan, eg ClickOnce, Windows 2003 AD Domain level. > > We think that we are able to shift to only be using AD Security groups, > without having to create 1000 groups. > > But what is best practice here? > > 1) Does the applications normally create the AD groups duing installation? > 2) Do you normally let the users map existing groups to your handles? > 3) Do you group the groups in a new ou? > 4) How many groups is to many? > 5) How does Microsft CRM do it? > 6) Any good examples? > > Thanks > > Henrik Skak Pedersen. > > > Hi Chris,
Thank you very much for your reply. We have about 300 operations/permissions and 5 roles. Would you really create them all as security groups? What does system administrators think of that idea? Do you have any examples of how to create and remove the ou's and the groups using Windows script? Does Windows 2000 Server support this as well? Including the nested hiearchies? I also need the system to be able to run in "demo mode" on a Windows XP machine. Can I then use ADAM for this? If yes do you have any examples of how to do that? Regards Henrik Show quoteHide quote "oldbear" <oldb***@discussions.microsoft.com> wrote in message news:86C40091-C8D9-436F-82DC-27105E156621@microsoft.com... > Hi > > I agree, there are issues with using AzMan for this. Using nested groups, > the group membership is flowed when delegating. Also, using AD there's no > need for a separate API - just use the User.IsInRole method (if this is a > web > app). > > AD groups are created at the domain level, so it would probably be better > to > create them separately, rather than during application install. If your > application uses load-balancing, you wouldn't want to install the groups > each > time. > > Having one layer of groups relating to permissions would possibly lead to > spaghetti code, eg: > > if (User.IsInRole(roleA) | User.IsInRol(roleB)){} > > It is useful to allow nested groups, and have a heirarchy of users, user > groups, role groups, ending with permission groups at the top level. This > is > similar to AzMan, but using AD nested groups. The extra layer of user > groups > allows administrators to map users to groups, and then add these groups to > your role structure. > > Here's a white paper that discusses this, giving details for > implementation. > Much of it is based on a very large enterprise-scale application that I > worked on with Microsoft: > > http://www.charteris.com/publications/whitepapers/default.asp > > The paper is entitled 'Security Solutions Offered by Visual Studio .Net > 2005'. > > It would be useful to place the new groups in a new OU - easier to > maintain. > When you're writing scripts, it's good to be able to just delete the OU > (only > do this on a development machine). > > Try this structure: > > Application OU > |---------RoleGroups OU > |---------PermissionGroups OU > > We used hundreds of groups, and AD can cope with thousands. > > We used Windows scripts to create the groups - use the ADSI methods. > > Hope this helps > > > Chris Seary > > > "Henrik Skak Pedersen" wrote: > >> Hi, >> >> We are creating a application where we until now has been using AzMan for >> authentication. We are now looking at alternatives, because we have some >> problems with AzMan, eg ClickOnce, Windows 2003 AD Domain level. >> >> We think that we are able to shift to only be using AD Security groups, >> without having to create 1000 groups. >> >> But what is best practice here? >> >> 1) Does the applications normally create the AD groups duing >> installation? >> 2) Do you normally let the users map existing groups to your handles? >> 3) Do you group the groups in a new ou? >> 4) How many groups is to many? >> 5) How does Microsft CRM do it? >> 6) Any good examples? >> >> Thanks >> >> Henrik Skak Pedersen. >> >> >> Hi Henrik
We created a vast number of groups representing permissions across a nationwide public sector portal, with several internal applications contained in the portal. We never came across any issues regarding the number of groups. Be careful to make sure that this is waht you want - sometimes people create roles for accessing things like document files, which could be more of a many to many relationship in a database. Use the role and permission group idea for access to system objects, such as buttons, pages, components. You may wish to cache some of the information pulled from AD in one go and encrypt it in a cookie, to improve performance. You could also put a database layer on top of the users ie. keep users in AD (thus being able to take advantage of auditing, authentication features of Windows) and create the role and permission groups in a database (relating to the SID of the user). This would mean it's a great deal easier and quicker to alter the role/permission matrix, and you can do it transactionally (AD can have problems when performing huge numb ers of updates via scripts). Look up the ADSI interfaces for creating/changing/deleting objects in MSDN. It's too vast a subject for this post. I'd recommend you create functions around these basic method calls that perform error trapping and logging, so that you can see if there were any errors in the batch. Not sure about ADAM - I'm not as familiar with this as I am with AD. When I have to do soemthing like this, I create a virtual PC that's a domain controller, and work from that. Hope this helps Chris Seary Show quoteHide quote "Henrik Skak Pedersen" wrote: > Hi Chris, > > Thank you very much for your reply. We have about 300 operations/permissions > and 5 roles. Would you really create them all as security groups? What does > system administrators think of that idea? > > Do you have any examples of how to create and remove the ou's and the groups > using Windows script? > > Does Windows 2000 Server support this as well? Including the nested > hiearchies? > > I also need the system to be able to run in "demo mode" on a Windows XP > machine. Can I then use ADAM for this? If yes do you have any examples of > how to do that? > > Regards > Henrik > > > "oldbear" <oldb***@discussions.microsoft.com> wrote in message > news:86C40091-C8D9-436F-82DC-27105E156621@microsoft.com... > > Hi > > > > I agree, there are issues with using AzMan for this. Using nested groups, > > the group membership is flowed when delegating. Also, using AD there's no > > need for a separate API - just use the User.IsInRole method (if this is a > > web > > app). > > > > AD groups are created at the domain level, so it would probably be better > > to > > create them separately, rather than during application install. If your > > application uses load-balancing, you wouldn't want to install the groups > > each > > time. > > > > Having one layer of groups relating to permissions would possibly lead to > > spaghetti code, eg: > > > > if (User.IsInRole(roleA) | User.IsInRol(roleB)){} > > > > It is useful to allow nested groups, and have a heirarchy of users, user > > groups, role groups, ending with permission groups at the top level. This > > is > > similar to AzMan, but using AD nested groups. The extra layer of user > > groups > > allows administrators to map users to groups, and then add these groups to > > your role structure. > > > > Here's a white paper that discusses this, giving details for > > implementation. > > Much of it is based on a very large enterprise-scale application that I > > worked on with Microsoft: > > > > http://www.charteris.com/publications/whitepapers/default.asp > > > > The paper is entitled 'Security Solutions Offered by Visual Studio .Net > > 2005'. > > > > It would be useful to place the new groups in a new OU - easier to > > maintain. > > When you're writing scripts, it's good to be able to just delete the OU > > (only > > do this on a development machine). > > > > Try this structure: > > > > Application OU > > |---------RoleGroups OU > > |---------PermissionGroups OU > > > > We used hundreds of groups, and AD can cope with thousands. > > > > We used Windows scripts to create the groups - use the ADSI methods. > > > > Hope this helps > > > > > > Chris Seary > > > > > > "Henrik Skak Pedersen" wrote: > > > >> Hi, > >> > >> We are creating a application where we until now has been using AzMan for > >> authentication. We are now looking at alternatives, because we have some > >> problems with AzMan, eg ClickOnce, Windows 2003 AD Domain level. > >> > >> We think that we are able to shift to only be using AD Security groups, > >> without having to create 1000 groups. > >> > >> But what is best practice here? > >> > >> 1) Does the applications normally create the AD groups duing > >> installation? > >> 2) Do you normally let the users map existing groups to your handles? > >> 3) Do you group the groups in a new ou? > >> 4) How many groups is to many? > >> 5) How does Microsft CRM do it? > >> 6) Any good examples? > >> > >> Thanks > >> > >> Henrik Skak Pedersen. > >> > >> > >> > > > Hi again,
So now I absolutely don't know what to do? Her is my scenario. I have aprox. 300 operations, 35 tasks and 5 roles in my current AzMan setup. Currently we only have a Windows application. We are now creating a web service and a web application which whould share the authentication store with the current windows application. So what would you actually recommend me to do. As I see it I have several possibilities: 1) Create 300 permission groups and 4 roles as security groups in AD and group them into Application OU ---------RoleGroups OU ---------PermissionGroups OU 2) Create the roles as security groups in AD. Create 2 SQL server tables to hold the permissions and the mapping to the AD roles. 3) Create everything as sql tables. What would you recommend me to do? Thanks Henrik. Show quoteHide quote "oldbear" <oldb***@discussions.microsoft.com> wrote in message news:AA0FC4CC-F7FD-4C66-BE32-3776F0116712@microsoft.com... > Hi Henrik > > We created a vast number of groups representing permissions across a > nationwide public sector portal, with several internal applications > contained > in the portal. We never came across any issues regarding the number of > groups. Be careful to make sure that this is waht you want - sometimes > people > create roles for accessing things like document files, which could be more > of > a many to many relationship in a database. Use the role and permission > group > idea for access to system objects, such as buttons, pages, components. > > You may wish to cache some of the information pulled from AD in one go and > encrypt it in a cookie, to improve performance. > > You could also put a database layer on top of the users ie. keep users in > AD > (thus being able to take advantage of auditing, authentication features of > Windows) and create the role and permission groups in a database (relating > to > the SID of the user). This would mean it's a great deal easier and quicker > to > alter the role/permission matrix, and you can do it transactionally (AD > can > have problems when performing huge numb ers of updates via scripts). > > Look up the ADSI interfaces for creating/changing/deleting objects in > MSDN. > It's too vast a subject for this post. I'd recommend you create functions > around these basic method calls that perform error trapping and logging, > so > that you can see if there were any errors in the batch. > > Not sure about ADAM - I'm not as familiar with this as I am with AD. When > I > have to do soemthing like this, I create a virtual PC that's a domain > controller, and work from that. > > Hope this helps > > Chris Seary > > > > "Henrik Skak Pedersen" wrote: > >> Hi Chris, >> >> Thank you very much for your reply. We have about 300 >> operations/permissions >> and 5 roles. Would you really create them all as security groups? What >> does >> system administrators think of that idea? >> >> Do you have any examples of how to create and remove the ou's and the >> groups >> using Windows script? >> >> Does Windows 2000 Server support this as well? Including the nested >> hiearchies? >> >> I also need the system to be able to run in "demo mode" on a Windows XP >> machine. Can I then use ADAM for this? If yes do you have any examples of >> how to do that? >> >> Regards >> Henrik >> >> >> "oldbear" <oldb***@discussions.microsoft.com> wrote in message >> news:86C40091-C8D9-436F-82DC-27105E156621@microsoft.com... >> > Hi >> > >> > I agree, there are issues with using AzMan for this. Using nested >> > groups, >> > the group membership is flowed when delegating. Also, using AD there's >> > no >> > need for a separate API - just use the User.IsInRole method (if this is >> > a >> > web >> > app). >> > >> > AD groups are created at the domain level, so it would probably be >> > better >> > to >> > create them separately, rather than during application install. If your >> > application uses load-balancing, you wouldn't want to install the >> > groups >> > each >> > time. >> > >> > Having one layer of groups relating to permissions would possibly lead >> > to >> > spaghetti code, eg: >> > >> > if (User.IsInRole(roleA) | User.IsInRol(roleB)){} >> > >> > It is useful to allow nested groups, and have a heirarchy of users, >> > user >> > groups, role groups, ending with permission groups at the top level. >> > This >> > is >> > similar to AzMan, but using AD nested groups. The extra layer of user >> > groups >> > allows administrators to map users to groups, and then add these groups >> > to >> > your role structure. >> > >> > Here's a white paper that discusses this, giving details for >> > implementation. >> > Much of it is based on a very large enterprise-scale application that I >> > worked on with Microsoft: >> > >> > http://www.charteris.com/publications/whitepapers/default.asp >> > >> > The paper is entitled 'Security Solutions Offered by Visual Studio .Net >> > 2005'. >> > >> > It would be useful to place the new groups in a new OU - easier to >> > maintain. >> > When you're writing scripts, it's good to be able to just delete the OU >> > (only >> > do this on a development machine). >> > >> > Try this structure: >> > >> > Application OU >> > |---------RoleGroups OU >> > |---------PermissionGroups OU >> > >> > We used hundreds of groups, and AD can cope with thousands. >> > >> > We used Windows scripts to create the groups - use the ADSI methods. >> > >> > Hope this helps >> > >> > >> > Chris Seary >> > >> > >> > "Henrik Skak Pedersen" wrote: >> > >> >> Hi, >> >> >> >> We are creating a application where we until now has been using AzMan >> >> for >> >> authentication. We are now looking at alternatives, because we have >> >> some >> >> problems with AzMan, eg ClickOnce, Windows 2003 AD Domain level. >> >> >> >> We think that we are able to shift to only be using AD Security >> >> groups, >> >> without having to create 1000 groups. >> >> >> >> But what is best practice here? >> >> >> >> 1) Does the applications normally create the AD groups duing >> >> installation? >> >> 2) Do you normally let the users map existing groups to your handles? >> >> 3) Do you group the groups in a new ou? >> >> 4) How many groups is to many? >> >> 5) How does Microsft CRM do it? >> >> 6) Any good examples? >> >> >> >> Thanks >> >> >> >> Henrik Skak Pedersen. >> >> >> >> >> >> >> >> >> Hi
In a number of applications, I've seen the following implemented successfully: create users in AD (in order to take advantage of authentication features of IIS and windows) create a sql database holding the roles and permissions link the roles to the users in the database by mapping roleid to Active Directory SID How you interrogate role membership in code is up to you, but Keith Brown in his book 'The .Net Developer's Guide to Windows Security' suggests a useful approach would be to create a GenericPrincipal object (which contains roles from the sql database) but using the WindowsIdentity object that is provided when authenticating ie. passing the WindowsIdentity into the constructor of the GenericPrincipal. You have the ability to impersonate the WindowsIdenitity whenever you need, but you can use roles from sql server. I've not done this myself - I contructed a genericprincipal with a genericidentity, which didn't have the advantage of the impersonation. However, I don't see why it wouldn't work. The principal could then be assigned to the HTTPContext.User property. This would apply to both the web service and the aspx page. Use can then use User.IsInRole This could be set up in an HTTPModule at the beginning of each request (see the white paper I mentioned on this). If the web service is using wse, you may need to put this 'plumbing' into a soap extension instead. Be careful about using AD. The main issue is how many users you need. AD can hold a vast number of users without any problem, but admin (such as backup and restore) is much harder than with a database. Several thousand users should not be a problem, however. Hope this helps Chris Seary Show quoteHide quote "Henrik Skak Pedersen" wrote: > Hi again, > > So now I absolutely don't know what to do? > > Her is my scenario. I have aprox. 300 operations, 35 tasks and 5 roles in my > current AzMan setup. Currently we only have a Windows application. > > We are now creating a web service and a web application which whould share > the authentication store with the current windows application. > > So what would you actually recommend me to do. As I see it I have several > possibilities: > > 1) Create 300 permission groups and 4 roles as security groups in AD and > group them into > Application OU > ---------RoleGroups OU > ---------PermissionGroups OU > 2) Create the roles as security groups in AD. Create 2 SQL server tables to > hold the permissions and the mapping to the AD roles. > 3) Create everything as sql tables. > > > What would you recommend me to do? > > Thanks > > Henrik. > > > "oldbear" <oldb***@discussions.microsoft.com> wrote in message > news:AA0FC4CC-F7FD-4C66-BE32-3776F0116712@microsoft.com... > > Hi Henrik > > > > We created a vast number of groups representing permissions across a > > nationwide public sector portal, with several internal applications > > contained > > in the portal. We never came across any issues regarding the number of > > groups. Be careful to make sure that this is waht you want - sometimes > > people > > create roles for accessing things like document files, which could be more > > of > > a many to many relationship in a database. Use the role and permission > > group > > idea for access to system objects, such as buttons, pages, components. > > > > You may wish to cache some of the information pulled from AD in one go and > > encrypt it in a cookie, to improve performance. > > > > You could also put a database layer on top of the users ie. keep users in > > AD > > (thus being able to take advantage of auditing, authentication features of > > Windows) and create the role and permission groups in a database (relating > > to > > the SID of the user). This would mean it's a great deal easier and quicker > > to > > alter the role/permission matrix, and you can do it transactionally (AD > > can > > have problems when performing huge numb ers of updates via scripts). > > > > Look up the ADSI interfaces for creating/changing/deleting objects in > > MSDN. > > It's too vast a subject for this post. I'd recommend you create functions > > around these basic method calls that perform error trapping and logging, > > so > > that you can see if there were any errors in the batch. > > > > Not sure about ADAM - I'm not as familiar with this as I am with AD. When > > I > > have to do soemthing like this, I create a virtual PC that's a domain > > controller, and work from that. > > > > Hope this helps > > > > Chris Seary > > > > > > > > "Henrik Skak Pedersen" wrote: > > > >> Hi Chris, > >> > >> Thank you very much for your reply. We have about 300 > >> operations/permissions > >> and 5 roles. Would you really create them all as security groups? What > >> does > >> system administrators think of that idea? > >> > >> Do you have any examples of how to create and remove the ou's and the > >> groups > >> using Windows script? > >> > >> Does Windows 2000 Server support this as well? Including the nested > >> hiearchies? > >> > >> I also need the system to be able to run in "demo mode" on a Windows XP > >> machine. Can I then use ADAM for this? If yes do you have any examples of > >> how to do that? > >> > >> Regards > >> Henrik > >> > >> > >> "oldbear" <oldb***@discussions.microsoft.com> wrote in message > >> news:86C40091-C8D9-436F-82DC-27105E156621@microsoft.com... > >> > Hi > >> > > >> > I agree, there are issues with using AzMan for this. Using nested > >> > groups, > >> > the group membership is flowed when delegating. Also, using AD there's > >> > no > >> > need for a separate API - just use the User.IsInRole method (if this is > >> > a > >> > web > >> > app). > >> > > >> > AD groups are created at the domain level, so it would probably be > >> > better > >> > to > >> > create them separately, rather than during application install. If your > >> > application uses load-balancing, you wouldn't want to install the > >> > groups > >> > each > >> > time. > >> > > >> > Having one layer of groups relating to permissions would possibly lead > >> > to > >> > spaghetti code, eg: > >> > > >> > if (User.IsInRole(roleA) | User.IsInRol(roleB)){} > >> > > >> > It is useful to allow nested groups, and have a heirarchy of users, > >> > user > >> > groups, role groups, ending with permission groups at the top level. > >> > This > >> > is > >> > similar to AzMan, but using AD nested groups. The extra layer of user > >> > groups > >> > allows administrators to map users to groups, and then add these groups > >> > to > >> > your role structure. > >> > > >> > Here's a white paper that discusses this, giving details for > >> > implementation. > >> > Much of it is based on a very large enterprise-scale application that I > >> > worked on with Microsoft: > >> > > >> > http://www.charteris.com/publications/whitepapers/default.asp > >> > > >> > The paper is entitled 'Security Solutions Offered by Visual Studio .Net > >> > 2005'. > >> > > >> > It would be useful to place the new groups in a new OU - easier to > >> > maintain. > >> > When you're writing scripts, it's good to be able to just delete the OU > >> > (only > >> > do this on a development machine). > >> > > >> > Try this structure: > >> > > >> > Application OU > >> > |---------RoleGroups OU > >> > |---------PermissionGroups OU > >> > > >> > We used hundreds of groups, and AD can cope with thousands. > >> > > >> > We used Windows scripts to create the groups - use the ADSI methods. > >> > > >> > Hope this helps > >> > > >> > > >> > Chris Seary > >> > > >> > > >> > "Henrik Skak Pedersen" wrote: > >> > > >> >> Hi, > >> >> > >> >> We are creating a application where we until now has been using AzMan > >> >> for > >> >> authentication. We are now looking at alternatives, because we have > >> >> some > >> >> problems with AzMan, eg ClickOnce, Windows 2003 AD Domain level. > >> >> > >> >> We think that we are able to shift to only be using AD Security > >> >> groups, > >> >> without having to create 1000 groups. > >> >> > >> >> But what is best practice here? > >> >> > >> >> 1) Does the applications normally create the AD groups duing > >> >> installation? > >> >> 2) Do you normally let the users map existing groups to your handles? > >> >> 3) Do you group the groups in a new ou? > >> >> 4) How many groups is to many? > >> >> 5) How does Microsft CRM do it? > >> >> 6) Any good examples? > >> >> > >> >> Thanks > >> >> > >> >> Henrik Skak Pedersen. > >> >> > >> >> > >> >> > >> > >> > >> > > > 
Other interesting topics
Login failed for user ''. The user is not associated with a trusted SQL Server connection.
Role based security flaw? Encrypted Data Storage ? HowTo ? WebService Windows Authentication ASP.NET 2.0 Impersonate Digital Signaturing users and roles Problems with AzMan interop and CLR 2 Best option for file encryption? internet explorer 6 sp2 |
|||||||||||||||||||||||
