RE: [ActiveDir] permissions requests

[joe]

Title: RE: [ActiveDir] schema updates

Rich my friend. (That sounds better as my Rich friend...)   You need a good group story. I will give you A story, not necessarily a good one. I will tell you my story or more likely our story with our being the company I do the contract work for - names withheld because I am not allowed to say.   I will have to say I agree with what someone else said in that you need to be consistent. It may not be as flexible as some want, but that may be how it has to be unless they want to pony up the dollars for a tool that can be as flexible as they want which still is very maneagable.   The best part of the story (in my Windows 2000 opinion) is that it works with native tools and is based on my favorite... DOMAIN LOCAL GROUPS!  These are groups that live in the domains but when you are in native mode you can use them on your member machines as well as on the domain controllers.   The whole Global Group into Local Groups into resources is just plain ugly... (booooooo).  That was always the right thing to say about that scheme.   Sometimes global groups may make sense but usually not when you want to be granular. You use it when you throw the bucket of paint, not when you want to paint the trim. Anyway I like domain local groups because they are much closer to the resource but still give you flexibility in changing the hardward on the resource without completely breaking your neck or doing special migration things.   What we do and again it may not be the best story but works tolerably well is we set up our OU structure by building code and then under that we have a servers OU and under that we have multiple OUs for admin groups. We always have say a FP ou for file and print since usually it is one admin group that handles all of that. We may have a couple of APP OUs named after the app or APP1 APP2, etc. These OUs have one group called xxxx-yyyyAdmins where xxxx is the building code, yyyy is the server subou like you might see 1234-FPAdmins or 6789-APPSAdmins. The permissions these admins have are group membership/description modification and the ability to join precreated server machine accounts in those OUs. Additionally they are allowed to request us to precreate (or delete if necessary) server machine accounts and groups for them and generally that group is also placed into the administrators group of the servers that are contained  in that OU.   DLGs for the resources on the servers in the OU are housed in that same OU and from what is listed above, the local admins have the rights to modify the membership. Now these groups are added to the ACLs of the resources.     I will give a real example here to make it more clear.   Building Code: 5623 They have two main server admin groups, File and Print and Web Server guys   OU looks like   5623-----Servers-----FP                          |                          ---WEB   So right off we have 5623-FPAdmins and 5623-WEBAdmins.   Under the FP OU they have say 2 file and print servers - SRV00001 and SRV00002. Under WEB they say have 3 servers; SRV05001, SRV05002, SRV05003.   By standard, the 5623-FPAdmins group should be in the Admin groups of SRV0001/2. 5623-WEBAdmins should be in the admins group of SRV05001/2/3.   If you have someone that you want to be an admin on one of the Web servers but not have group rights, you could create a group in the OU and then place that group in the admins group of the specified server.   We have some basic standards for shares too. There are two main ones and then shares for home drives. So you say you have a share called P for project data and one called A for app bins and installs and then a userid$ share for every user. These are on the FP for sure as they are cookie cutter at least to start. Shares are all set Everyone:FC. Things locked down with NTFS. The A share is read only for NTFS because the installs and Network App Bins don't need to be written to. The home share NTFS perms are Admin:FC, userid:C. Those are the simple ones.   The project data share P is (by standard) to have various project folders under it. Each top level folder gets 2 groups really by default. One granting read and one granting write. The group names should have the folder name in it so they are easy to correlate but we don't enforce that at our level, someone wants to stick a group called 5623-Flirt on a folder called Explosives that is fine by us. I further recommend (but it isn't the standard) to name the group with the subou name in it so that it is self explanatory and possibly the server name name in it as well... By default the group has to be prefixed with the building code... So say you have a folder called REORG on SRV00001 you would like to have groups in AD like   5263-FP-0001-REORG 5263-FP-0001-REORG-R   Looking at those groups I can logically tell you that the group is for building code 5263, FP Server SubOU, Server SRV00001, the first four characters are standard based on 3 character site prefix and 0 for server. REORG is the top level folder. R is for read only.   Knowing that, you would know that   5263-WEB-5002-HR 5263-WEB-5002-HR-R   give access to the SRV05002 server which is in the web subou and 5263 building.     Now for Web you might want to something slightly different (as we once did when I managed a resource domain ages ago).   You might want to have those main folders off the P share be say departments and then under each department you have groups and each group wants to manage their own web content... So you add a layer to the group naming....   5263-WEB-5002-HR-PAYROLL 5263-WEB-5002-HR-PAYROLL-R   So that protects the \\srv05002\p\hr\payroll folder.   You can keep getting deeper like that if you want but eventually hit the SAM Name size limit... (MS we should be able to turn off SAM Name compatability where we don't need a SAM Name...). At that point you either start making up numeric SAM names that don't have any relation to the folder structure and just use the AD names or get creative in other ways.   Users are placed directly into those groups, no U->G->L->permissions stuff. If you have say 30-40-50 thousand groups in a single domain, you can easily filter on the names to find the ones that apply to you and your OU. Auditors can quickly look at an ID and have an idea of what accesses someone has. When you migrate server hardware, you copy the data with the ACLs and everything is fine. No local groups to worry about moving or recreating.   The more logical and consistent you are the more you get to script and automate for auditing and implementation and management.   Again, local sites don't have to follow this. If they want to protect each folder under the main root folder, that is up to them, they have to do all the management of it so whatever floats their boat. We don't recommend it though because it is complicated and has to be audited.   I personally feel this is a good story for distributed data management. It isn't as flexible as some would want but it is difficult to be completely flexible but still be manageable and I would rather be manageable than flexible especially with IT budgets shrinking like crazy. It works well with the native tool sets and is easy to script around. Also for auditing, if you can assume the permissions are being set properly on the server (say you set them and don't allow anyone to modify them, just the group in AD), you can quickly modify who has access to what by looking at the AD groups.   The people who have the data put the data in the proper places based on who should get it and they manage the groups themselves (gots to love delegation...) so top level admins are out of it.   The one problem I have run into on this is when assigning rights on a server. I haven't tried it yet with W2K3 but in W2K there is a bug where you can not select a domain local group to apply to a right on a server, it only lists people and local groups (maybe global groups but I didn't look). You can still do this from the command line with like ntrights. The other option is to create a local group on the server and nest the domain local group into the local group.         Now centralized data for distributed users... that is tougher. I was starting to look at it last summer and now in the last week have been thrown into the deep end on it. Say you have many terabytes of centralized storage that is going to be farmed out by project name or some other criteria (basically anyone who can cut a P.O. to storage) and the delegation is completely handled by the project owners and you need to be out of the way as much as possible and there will be thousands of projects with who knows how many different layers of delegation and groups needed under each project and everyone is going to be wanting to pick their own names... This is my new thing to play with. I am imagining completely getting away from the native tools and doing everything through some web interface and group names being generated by the system and people manage by folder name and that translates in the backend to group management. This way you don't get two groups from two different divisions who both feel they are entitled to have the group called OA-SUPPORT or whatever and seriously escalate the issue through management where managers start the "I have more power than you struggle"... I'm Serious. The way I visualize it when they get approval (and submit cash) for the new project area, they get some generated name for the top level folder, probably a generated number so it doesn't ever have to be changed. Then they do whatever they want for the folder structure under it and just say they need a group to lock down some folder. The group name is generated (sequential numbering would work, use HEX) and one attribute in the directory is the folder name it locks down and maybe whether it is change or read or whatever. Then when they go into manage they say the need to give X read access to folder blah... The system does a query for the right group name, finds it and then updates it. Or something along those lines. Also I would think the tool needs to allow infinite number of subdelegations below the main level so that the main storage group would delegate to the project owner who would delegate folders to the leaders of various aspects of the project who would delegate folders to the various team members, etc.   This is very very rough. I really am going to have to sit down and work out requirements and look at the tools from Quest and Aelita and NetPro et al. (Note I am not looking for a salesman to call those salespeople who know where I work...though I may be looking for that shortly so Mongolian BBQ lunches may be order in a month or two...). I doubt there is anything that will do what I want right off. But I haven't had a chance to look yet. My main priority right now is deployment of W2K3 but this isn't going to go away and really is something I always needed to work out. I am kind of wondering if this is the time to learn Dot NET and whip up the web app to do this... If it were my only project for the next 6-8 months, I probably would; I think it would be terribly exciting to work out.   Anyway, I hope that helps out a little in terms of maybe giving some additional ideas or thoughts.       joe   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Milburn Sent: Friday, January 30, 2004 10:05 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] permissions requests I have to mention this up front – the solution to this can’t be a $25,000 admin tool J We’ve got an issue I’ve mentioned in passing before regarding permissions.  We tend to assign global groups NTFS permissions to files on our servers, and leave Everyone modify share permissions intact (domain admin full control).  This is because one or two people here have been burned with the Users -> Global -> Local -> Resources practice when they had to move to a new file server (open to suggestions on that).  Anyway changing the entire security structure is not an option right now, and I’m here doing mostly SMS so… What happens is contractors come and go in development, and people are forever requesting that so-and-so have access to this one folder so they can do this one thing.  Not like so-and-so is working on the BigDev Project and needs to be in the BigDev group.  And only Network Services group has access to change permissions.  Here is an example of the requests we get (names have been changed to protect the innocent):   Give Tom Cruiser read/write access to the following and change George Doublya access to read/write access to the following (remove any other access George Doublya has to other subfolders within these shares besides what is listed below):   fileserver\support\how to fileserver\support\MCI fileserver\support\Menu Exports fileserver\support\Pos-DataCD fileserver\support\Zipdata sqlserver11\help\Tablechart sqlserver11\help\Franchise   Also, give George Doublya read/write permissions to fileserver\opsserv and all subfolders.   So to start with, I have no idea what function either of these people do.  There is not a group that matches the rights they need, and adding them to a global group can give them other rights, who knows what all that might be (answer:no one)  least of all the person making the request.  Such knowledge is unnecessary for them, and beneath them.    So what I have to do first is find the users’ logon names (enter a script I wrote for something completely different).  Then I try to find which groups they are a member of (q’n’d way is getuserinfo – thanks Joe).  Then I pull up Computer Management with \\fileserver and go to Shares, check the share permissions (some of them still have share level permissions).  Then I pull up the actual directory in explorer, check NTFS permissions.  I’m looking for common groups.  If something is obvious to map to a group, I add that.  So I open ADUC.  I know dsmod can do this but that means lots of DN typing…   This is all very labor intensive, inefficient, and scary.  So please, offer any and all suggestions as to how to streamline this, how to better use command lines for this, any scripts someone might have found or other best practices for some of these tasks.  I’m also interested in how people deal with local groups when a server needs to be migrated.  And any suggestions as to how we might get from here to a more efficient security model without disrupting the users (big no-no).  Sorry so long… and thanks   Rich -------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY NOTICE------- PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this message or any attachments. This information is strictly confidential and may be subject to attorney-client privilege. This message is intended only for the use of the named addressee. If you are not the intended recipient of this message, unauthorized forwarding, printing, copying, distribution, or using such information is strictly prohibited and may be unlawful. If you have received this in error, you should kindly notify the sender by reply e-mail and immediately destroy this message. Unauthorized interception of this e-mail is a violation of federal criminal law. Applebee's International, Inc. reserves the right to monitor and review the content of all messages sent to and from this e-mail address. Messages sent to or from this e-mail address may be stored on the Applebee's International, Inc. e-mail system.