If you want to develop certain user/computer polcies based on the environment the user works in - how do you go about this as a project to determine/establish exactly who are the "high risk users" - i.e. those who work with highly sensitive data - against the "low risk users" - i.e. those who dont work with sensitive data? This is a large enterprise over 6000 user objects. Im sure such a task has been required before.

The Servers and Active Directory have no knowledge regarding risk and sensitivity. Only people familiar with the business and what people do (their roles in the organization) can make such judgements. Once they do this, however, the information can be "retained" by: Assigning users to groups, perhaps one for high risk/sensitivity, etc. Standardizing values assigned to an AD user attribute, like title, to describe the risk/sensitivity. Placing users in OU's, perhaps one for high risk/sensitivity, etc. These are just suggestions. It is entirely up to the organization. Richard Mueller - MVP Directory Services

Your pretty much thinking about it already, you will face hurdles along the way. It's easy to say, R&D is all high risk, or finance. But when you start dealing with humans, it gets messy from there. You will have executives and other department managers that feel they need rights and access to stuff they really shouldn't and because of politics you will find situations where 1+1=3. Very frustrating, without a strong IT manager to enforce policies, your in a pickle. I would take a good read over AD management, you can Bing! for AD secure stratgies, and so forth and see a ton of good articles. Don't fall into the trap of putting too much or repetitive GPO's in place, to be successful, you need to Keep it Simple! You need to map out a gameplan, pre-write up proposed GPO's and policies. If you have a small lab to test run them on, you should do that, you can iron out bugs that way.:P Advice offered, If you need more help it is advised to seek the council and advice of paid professionals. The answer is always 42, or reboot.

Thanks both. What kind of user policies are applied to "higher risk" users than "lower risk" users in terms of data security / i.e. our management seem of the opinion higher risk users there will be a template of user/workstation policies that we can pick up for high risk users and a template with more lax user/workstation policies that we can pick up for low risk users. I am interested in some actual examples of policies you;d apply to high risk users and policies you wouldnt need for lower risk users. Considering the main driver is control over the data the higher risk users have access to / process as part of their day to day work. Any ideas?

Is it not just more easy to treat everyone as a high risk user and set policies for one and all? Or in reality is this overkill and not neccesary?

The more GPO's you load up the more problems you will encounter, and can impact user performance. So keep it simple, implement a locking screensaver policy for start, look at requiring complex passwords and 90 day change password requirement (45 and 30 day are too short) Look at implementing social security awareness, like users locking thier machines when they leave their desk, look at how your building physicial security is like, do you have wire locks for laptop users? Put forth a policy like no personal hardware is allowed at work (usb drives, etc), but take a commen sence approach, like allowing folks to charge thier phones. Keep a strict and tight hardware control, know where your gear is at all times, wipe all hard drives on older systems you are tossing, use a vendor that will certify data destruction. Could go on for hours....:P Advice offered, If you need more help it is advised to seek the council and advice of paid professionals. The answer is always 42, or reboot.

Thanks - we do have the HR policies to support the above. Its more the technical group policies for user/data security we need to review to check we are aligned with best practice. I cant see much benefit in setting really high user policies for user/data security for one group, and really low for another group. But in terms of "data security" I am struggling to get my head around what user group policies there are available? Can you provide some examples? I guess it could be what users can do with the data they can access? But a menu of user level policies that can be configured to protect the leakage and misuse of such data would be interesting.

If you want to develop certain user/computer polcies based on the environment the user works in - how do you go about this as a project to determine/establish exactly who are the "high risk users" - i.e. those who work with highly sensitive data - against the "low risk users" - i.e. those who dont work with sensitive data? This is a large enterprise over 6000 user objects. Im sure such a task has been required before. I think you're approaching the problem the wrong way; I mean... you're thinking at "users" when, what you want to protect are "projects"; try flipping your thought and considering projects levels instead of users levels, then setup some kind of "data hierarchy" and reflect it on the data storage infrastucture; done that start by creating whatever "user groups" you may need and assigning them the desired access level at that point you can step to the users accounts level and start assigning users to the desired "access groups" (as a note, you may also want to enable files access logging and so on) See, the basic idea here is that you should start by assigning an importance to the various data and organizing them so that data of a given "level of importance" will reside somewhere and be separated from "less important" ones; done that it will be relatively easy to set up some kind of access level infrastructure which will allow you to control "who does what"

If you want to develop certain user/computer polcies based on the environment the user works in - how do you go about this as a project to determine/establish exactly who are the "high risk users" - i.e. those who work with highly sensitive data - against the "low risk users" - i.e. those who dont work with sensitive data? This is a large enterprise over 6000 user objects. Im sure such a task has been required before. I think you're approaching the problem the wrong way; I mean... you're thinking at "users" when, what you want to protect are "projects"; try flipping your thought and considering projects levels instead of users levels, then setup some kind of "data hierarchy" and reflect it on the data storage infrastucture; done that start by creating whatever "user groups" you may need and assigning them the desired access level at that point you can step to the users accounts level and start assigning users to the desired "access groups" (as a note, you may also want to enable files access logging and so on) See, the basic idea here is that you should start by assigning an importance to the various data and organizing them so that data of a given "level of importance" will reside somewhere and be separated from "less important" ones; done that it will be relatively easy to set up some kind of access level infrastructure which will allow you to control "who does what" Can you define projects? Thanks for the reply.

Can you define projects? Maybe I used the wrong word, anyway, I was referring to a number of restricted documents belonging to a certain "access level" and I was thinking at documents related to a project (that's why I used that word); see, you may have an ongoing project which is made up by a number of different documents and each "group" of documents may (and usually will have) a different type of audience... which also means that some of those will be reserved to people having at least a certain level of "clearance" so, starting from the "documents level" and moving to groups and then users may help you better defining an authorization infrastucture Not sure if I've been clear... just hope so

If you decide a group of users has access to sensitive data, I would consider applying more restrictive password policies for them (longer, more complex passwords, that must be changed more often). You can do this with fine-grained password policies in Windows Server 2008. Also, high risk users might have one user account for high risk activities, and another user account for normal activities. This is similar to Domain Admins, who should not user their Domain Admin account for normal user activities. Richard Mueller - MVP Directory Services

If you decide a group of users has access to sensitive data, I would consider applying more restrictive password policies for them (longer, more complex passwords, that must be changed more often). You can do this with fine-grained password policies in Windows Server 2008. Also, high risk users might have one user account for high risk activities, and another user account for normal activities. This is similar to Domain Admins, who should not user their Domain Admin account for normal user activities. Richard Mueller - MVP Directory Services Thanks - I feared there may be hundreds of user level policy settings required for users who access high sensitive data. Just applying them more complex passwords to protect the data they can access seems to get us off very lightly. Are we sure theres nothing else being overlooked? It just seems a bit to simple to be true - but if it is and thats the main issue then fair enough and a big PHEW

My thinking is that if a user has access to sensitive data, then the object is to make sure only they have access. The data itself should be protected to only give access to members of specific groups, and deny access to everyone else. That might be the hard part. Other people may have other comments. Richard Mueller - MVP Directory Services

You may need to think broader on physical, social, and IT security as a whole. Isolated networks, who has access to what physical devices, doors/floors, etc.. In addition to thinking about AD policies and practices.:P Advice offered, If you need more help it is advised to seek the council and advice of paid professionals. The answer is always 42, or reboot.