Access Management Processes
Greetings,
On a daily basis I am requested for service account passwords, local admin access, permissions for files and shares, and a host of other access related topics.
What I am looking for is a best pratice for managing such requests. I usually have them substantiated with an email, but is that enough? Should these requests be kept on a spread sheet somewhere? Does every request have to come with a manager's approval?
If anyone has any sample procedures or templates I would be most appreciative.
Thanks.
Software/Hardware used:
Software/Hardware used:
ASKED:
March 7, 2006 3:20 PM
UPDATED:
March 8, 2006 9:47 PM
Answer Wiki:
Whoa!
1 - service account passwords - NEVER. Service accounts are designed to be system and application NOT users. Why do your users want the service account password?
2 - local admin access - more problematic. I have 60-65 machines on a 2k3 network. the local administrator account is passworded with the user's name that normally sits at the keyboard. NO NETWORK ACCESS! When the users log in to the network they have 'power user' permissions. Even Palm (bless their tiny souls) can be made to work at 'power user' level after install. Our written policy includes termination for compromising a network system by elevating your local privileges.
3 - Files and shares - all shares are on servers, NO peer to peer or local file / printer sharing. All permisssions are by groups and group membership is reviewed by supervisors every 30 days. Exceptions require the appropriate supervisor's written sign off. First 90 days were miserable but has saved my job and sanity many times over.
4 - Documentation - DumpSec (formerly DumpACL) is a free and simple way to let the Active Directory report changes and track status. Export as tab-separated file into Excel for reports and you are good to go.
Good Luck - considering your questions you will need it.
To see all answers submitted to the Answer Wiki: View Answer History.
Taking into consideration of what Howard had to say…
You need a formal, written, approved, and signed policy stating what can and can’t be done, and who has the authority to approve such requests.
Next you need both a policy and then the technology to implement a change control/change management process. Yes, this can be as simple as “for these types of requests an email is fine” and “but for these types of requests your manager must approve” and even “for these types of requests a VP must approve.”
How you track those requests will first depend on policy. Companies that are under legislative requirements such as HIPAA, GLBA, SoX, etc. must have a formal change management process and must keep records of such changes for x-number of years for audit purposes.
If your company is not in that boat then the tracking of such requests will be up to you. Always keep in mind the Bus syndrome… If, God forbid, you?re hit by a bus on your way to work tomorrow, are your systems documented well enough that someone could step in and take over easily?
We are using FAROS, web tool to administrate and document the requests by the users. Any request that goes to the User administration, must be approved by the Line Manager and the application owner. In some cases, like special authorities etc. must even be approved by the system responsible manager. This is true for all our platforms, MF, Iseries, NT, Unix, etc.
This works very well.
You should have a Security meeting with each manager of a department. You should go over who has security rights to each functionality that individuals have already. You should ask the manager why he thinks those individuals should have those rights. If the rights are not soemthing that they need to perform their “Job Responsibilities” then you should say that you don’t understand why they should have that right or capability. The department manager should be the one responsible for “Signing Off” on what functions are needed to perform the departments or individuals tasks. Have all of the information for the meeting written on paper. Send the request for the meeting with the document attached. I would recommend that you have the first meeting without the individuals present to explain the concerns to the manager first. Allow the manager to call in anyone that he needs to discuss with them and you, why it is they need to have that capability or right. Allow the manager to decide if that right is needed. If it makes sense to allow that right to the indivdual have the manager sign off on it. If at the end of all of that you still feel that the department or individual should not have the rights that the manager feels that they should have, then talk to your manager (if it is a different manager) and ask for help.
Oh by the way, make sure that the whole process starts with written e-mail approval from your manager.
Both previous inputs are required. One other element is required. When you implement this type process and constraints, if upper management doesn’t back you, you will fail. Make sure you sell this well to leadership so they will back you this first time a conflict for time or money arises. Then your job will get easier.
What can I add to the great responses already received?
Well, as a complement to this process your company should have a kind of “information inventiory”, where managers in the LOB should “own” (and properly classify) the relevant information handled by their departments, then they should approve which access is granted on that info to the different groups/profiles (NEVER to individual users directly… except when technically justified), then the supervisors of each team should assign the users to the profiles/groups based on job responsibility.
After this is implemented, periodic certifications of access rights (to profiles) and profile assignment (to users) should be done and signed by the relevant “owners”.
Ah! and all this should be properly documented in policies (high level) and procedures (low level), adequately signed by management.
And from then on, maybe your job will not be easier bus surely less risky and “tidy’.
G’d Luck, and cheers from DownUnder!