Shared Account Management

Shared Account Management (SAM) solves customer’s problems regarding controlling and audit access to shared accounts, in two ways: Applicative and Administrative. Both of these approaches solve important problems for the customer:

1: Remove hard-coded passwords from scripts.

SAM allows customers to remove clear-text passwords from scripts and instead to enable the script to retrieve the password for the shared account securely and automatically at run-time.

Detailed Explanation: Many customers embed passwords for shared accounts in scripts so that databases, system processes and applications can start without operator intervention. For example, during a system reboot, it may be necessary to start the Oracle database. Starting the database might require logging in as the Oracle user and executing some commands. The administrators who use the Oracle account might not be available every time the system reboot happens, so instead the customer uses a script to run the Oracle commands. The script contains the password for the oracle user account so it can run the Oracle utilities and start Oracle automatically when the system starts.

The problem with this approach is that now anyone can find and use the password for the oracle account by simply reading the script, which contains the password in clear text. This can lead to abuse of the shared account (in this case oracle). Finding passwords in clear text in scripts is “low hanging fruit” for auditors, who are going to require the customer to remove the passwords from scripts. So how does the customer still start the processes automatically? Answer: Use the SAM utility for password retrieval.

2: Change Service Accounts on Windows.

SAM changes the passwords for services accounts in AD and updates the service on each Windows server with the new password, on a regular schedule. This feature also works for Windows scheduled tasks, which also require a hard-coded user ID and password in order to run. (This also works for Windows run-as operations)

Detailed Explanation: Windows Services frequently are configured to use a specific user ID and password to login when the service starts. The user ID and password that the services uses are “hard coded” into each service on each Windows server. If the user ID and password are not correct, the service will not start. So if the customer has 100 Windows servers, and each one has a service called “Telnet”. The telnet service on each system is configured to initiate using the user ID ServiceUser, and the password of ABC123. ServiceUser is an AD user account whose password is ABC123, so when the telnet service starts, this operation will succeed.

However, the customer has a requirement to change user passwords at regular intervals, including the ServiceUser account. If the customer changes the password of Service User to XYZ987, the Telnet service will fail to start on all of the 100 Windows servers because the Windows service still thinks the password for ServiceUser is ABC123. So the customer would have to manually change the password for each Telnet service on everyone one of the Windows servers. This task is tedious and for this reason service account passwords often do not get updated at all. How does the customer change service account passwords on a regular basis and ensure that the Windows services all know the new password? Answer: SAM’s service account feature.

(BTW, SAM also includes a feature for removing hard-coded passwords from applications that are using those to login to databases)

SAM hides and controls the passwords for shared accounts, and allows the passwords to be retrieved by authorized users through a process called Check-out. When the user is done with the shared account, he will release it through a process called Check-in. All steps are logged. SAM provides access controls and accountability over the use of shared accounts such as *ix root account, Windows Administrator, and other shared accounts on databases, systems and applications.

1: Pre-Approved accounts.

The user logs into the SAM interface (probably using his AD domain credentials) and sees a menu of the shared account that he is pre-authorized to used, based on his role. The user checks out the password and uses the shared account. When the user is done using the shared account, he checks in the password. SAM resets the password when it is checked in. The check-out and check-in operations are logged for accountability and the password can only be used once because it is reset on check-in.

2: Emergency Access (Break Glass accounts).

The user logs into the SAM interface (probably using his AD domain credentials) and sees a menu of the shared account that he is pre-authorized to used on an emergency basis (the break-glass accounts), based on his role. The user checks out the password and is required to enter an explanation of why he is using the emergency access, such as by entering a ticket ID number. After entering the explanation, the user gets the password and uses the shared account. When the user is done using the shared account, he checks in the password. SAM resets the password when it is checked in. The check-out and check-in operations are logged for accountability and the password can only be used once because it is reset on check-in. The entire break-glass process is submitted to a workflow process so that a manager can review the operation afterward.

3: Request Temporary Access to a Shared Account.

The user logs into the SAM interface (probably using his AD domain credentials) and needs permission to check out an account that he is not presently approved for. The user selects the shared account he needs, provides an explanation as to why, and how long (the expiration date). The request is submitted to the SAM workflow engine and is reviewed by an approver who reviews the request and optionally adjusts the expiration date. If the request is approved, the user will then be able to access the shared account as a pre-approved account (just as in use #1 above). The privilege of accessing the shared account will expire on the expiration date.

4: Automated login.

Any of the above use cases can be supplemented by automatically launching the application that the user has checked the password and logging the user in. This provides convenience for the user and better security because the password is not revealed to the user. Automated login is an optional feature for applications that can be launched via RDP, putty or web browser.

5: Session recording.

When automated login is used, SAM can also implement session recording to make a video recording of the user’s session, for maximum accountability. Video session recording is only available when automated login is used.

 

Solution Brief Link:  http://www.ca.com/~/media/Files/SolutionBriefs/ca-controlminder-solution-brief.pdf

Wordpress SEO Plugin by SEOPressor