This document outlines best practices for designing, installing
and rolling out Hitachi ID Password Manager to manage credentials for
on-premise and SaaS systems and applications.
This document outlines best practices for designing, installing and rolling out Password Manager to manage credentials for on-premise and SaaS systems and applications.
The remainder of this document is organized as follows:
A credential management system should deliver three benefits:
Fewer credentials for users to remember and manage and simpler, quicker and more convenient resolution for login problems.
Fewer help desk calls related to login problems such as forgotten passwords, intruder lockouts or tokens left at home.
Stronger and more consistent enforcement of policies around password composition, change frequency and reuse, as well as more reliable processes to authenticate users who experience a login problem, before assisting them.
A mission statement documented before the system is deployed is helpful for getting all stake-holders to cooperate. One way to formulate this mission statement is to capture the state of affairs before the system is deployed and the desired end state. Following is an example:
|Credential management system objectives|
|User service / SLA|
Users manage 8 different passwords, on average.
|With password synchronization, users will only have to manage 2 passwords.|
Only some passwords expire and they do so at different times
|Users will be prompted to change all passwords at the same time.|
Different systems enforce different password policy rules.
|A uniform password policy will supersede multiple, inconsistent rules.|
Users sometimes forget their pre-boot password.
|Enable self-service filesystem unlock via smart phone app.|
Users sometimes forget their OS login password, in some cases while off-site.
|Enable self-service password reset from the PC login screen, with VPN+WiFi integration to support users working outside the office.|
|IT support cost|
30% of total help desk call volume is due to login problems.
|Password synchronization and self-service problem resolution will reduce this call volume by at least 80%.|
5% of total call volume is due to OTP token problems.
|Offer self-service PIN reset and emergency passcodes via smart-phone app.|
Help desk calls to resolve login problems take 10 minutes to resolve,
|Consolidate caller authentication, technician login, problem resolution and ticket generation behind a single UI, to reduce call duration to 2 minutes.|
|Security / authentication|
Users have too many passwords and write them down.
|Synchronization will eliminate the main user motivation for writing down passwords.|
Different systems and applications enforce different password policies.
|Implement a uniform policy with a superset of password composition, reuse and change frequency rules.|
Users calling the help desk are not reliably identified.
|Move most incidents to self-service and apply uniform authentication processes in both self-service and assisted-service contexts.|
Not all systems log password changes.
|Will record who changed passwords, on a central credential management system.|
Too many IT support staff have logins with elevated rights,
required to reset passwords for people who call the help desk.
|Support staff will reset passwords through an assisted-service portal, eliminating the need for such accounts.|
Before deploying a credential management system, it is useful to identify and start recording metrics. Once the system is deployed, continuing measurement of the same metrics will show its impact.
Following are some relevant metrics:
A credential management system has many integrations, each of which has an owner: endpoint devices, servers, applications, incident tracking systems, e-mail infrastructure, VPN, VoIP or other telephony systems and multi-factor authentication platforms. It impacts security, IT support and audit.
It is important to get buy-in from every stake-holder early in the project, to avoid objections, delays and implementation risk.
An authoritative sponsor is essential to get buy-in from a diverse group of stake-holders. Because of the large number of interested parties, it is almost inevitable that somebody will raise objections, try to change priorities or alter previously agreed-to designs. Too many interruptions like this will derail the project. A high profile business sponsor reduces these risks.
The following stake-holders should be engaged as early as possible when deploying the system and should sign off on objectives as described in (1):
Identity management and access governance projects tend to be long and indeed may never end, as deliverables are continually added over the life of the system. Organizations go through both business and infrastructure changes: reorganizations, hardware upgrades, new operating systems, new applications, etc. These changes trigger matching requirements in the identity management and access governance infrastructure and consequently lead to implementation and maintenance effort over the life of the system.
This is not to imply that individual deliverables cannot be implemented quickly and operated at low cost. Rather, it means that successful implementation of one feature or integration usually triggers interest by a wider range of stake-holders, who request further work, to deliver more features and integrate with more infrastructure.
With this in mind, it can be helpful to think of identity management and access governance implementation in terms of a process of continuous optimization, which is the responsibility of a permanent team, rather than a single, finite project.
Successful organizations respond to this by instituting a permanent identity management and access governance program, rather than staffing for a finite-term deployment project. This team should include a permanent technical application administrator and a permanent application owner, at a minimum.
The Hitachi ID Identity Manager product administrator position should be a single FTE. The Password Manager product administrator position can be a fractional FTE (e.g., 0.25). The Hitachi ID Privileged Access Manager product administrator position can be a fractional FTE (e.g., 0.5).
As with any long term program, it is important to have clear buy-in from stake-holders and an up-front agreement on project scope, deliverables, duration and cost in order to sustain investment and deliver on business expectations. Without such early commitment by stake-holders, project work may be aborted before deliverables are reached.
The permanently assigned Hitachi ID Systems customer team should consist of one or two individuals who have as many of the following skills as possible:
The first step in deploying a credential management system is to specify what processes it will implement. All stake-holders must sign off on a design, preferably in writing.
Hitachi ID Systems recommends deploying as many automated processes as possible, as each process adds value. It's a good idea to capture the motivation for each feature before starting deployment, as this helps new stake-holders understand not only what's being undertaken but also why.
Following is a list of Password Manager features. Customers typically deploy most of these, but which ones they include depends on their priorities and whether they actually have the relevant infrastructure (e.g., full disk encryption software, smart cards, etc.).
When users change their password natively on a system where a password synchronization trigger has been installed, the new password is tested for strength against the Password Manager password policy and, if accepted, is changed both locally and on other systems where the user has accounts.
Password Manager includes password synchronization triggers for Windows server or Active Directory (32-bit, 64-bit), Sun LDAP, IBM LDAP, Oracle Internet Directory, Unix (various), z/OS and iSeries (AS/400).
Using a familiar and mandatory password change process guarantees 100% user adoption.
Using an interactive web page to change passwords has educational benefits but requires user awareness and cooperation.
Users who have forgotten a password or triggered an intruder lockout can sign into Password Manager using other types of credentials to reset their password or clear the lockout. Non-password authentication options include security questions, voice biometrics, smart cards, hardware tokens and random PINs sent to a user's mobile phone using SMS.
Access to self-service is available from a PC web browser, from the Windows login screen, using a telephone or using the mini web browser on a smart phone.
Users with full disk encryption software on their PC, who have forgotten the password that unlocks their computer prior to OS startup, can unlock their hard disk using a self-service process accessed via telephone.
Password Manager includes a turn-key integrated voice response (IVR) system designed to automate password resets, PIN resets and unlock of encrypted filesystems via a self-service phone call. It ships with connectors for popular full disk encryption products from McAfee, CheckPoint, Symantec and Microsoft.
Users with a token who have forgotten their PIN or need an emergency pass code can access self-service PIN reset with a web portal or using a telephone. Users with a smart card can also reset their own PIN using an ActiveX control embedded in a web browser -- launched from their Windows desktop or login screen.
Authorized IT support staff can sign into a Password Manager web user interface to look up a caller's profile, authenticate the caller by keying in answers to security questions and reset one or more passwords. A ticket can be automatically submitted to the help desk incident management system.
Password Manager normally enforces a global password policy to supplement the various policies enforced on each system and application. This policy ensures that passwords accepted by Password Manager will work on every system.
The built-in policy engine includes over 50 built-in rules regarding length, mixed-case, digits, dictionary words and more. Regular expressions and plug-ins enable organizations to define new rules. Password history is infinite by default.
Password Manager can remind users to change their passwords, either using a native password change dialog or via the Password Manager web portal. Warnings are normally sent to users before their password actually expires on AD, LDAP or other systems. These invitations can be sent via e-mail or launched in a web browser when users sign into their PCs. Users can even be forced to change passwords by launching a kiosk-mode web browser when the user signs into their PC.
Password change reminders are normally only sent at the start of users' work day and work week, to discourage users from changing passwords right before leaving work and subsequently forgetting the new password.
Users should be able to resolve login problems wherever they happen to be, using whatever device is most appropriate and convenient, regardless of the state of their device. This means on-site at the office and also remote, from a browser on their PC, or their PC login screen, or a mobile device, and from the password prompt of their PC login screen, which asks for a (forgotten) password.
Some of these contexts present technical challenges, which the credential management system should address:
Password reset via phone call or mobile app or another PC is not a satisfactory solution, because the user's password is cached locally on the PC and should be updated by the password reset process. For the same reason, VPN integration is required, so that when a user is off-site and forgets their PC login password, the new password can be injected back into the PC, making it usable again.
Since there is no web browser in the pre-boot context, resolving pre-boot lockouts requires either a voice phone call or an app on the user's smart phone.
Password Manager is normally configured to enforce a uniform password policy across all systems, to ensure that any new password will be acceptable to every integrated system. This provides the most clear and understandable experience to users. Password Manager is configured such that it will never accept or propagate a password that will not meet this global password policy.
For instance, in the case of an organization that has both Windows Active Directory (AD) and z/OS passwords, where users may enter very long passwords on AD but only 8 characters on the mainframe, Password Manager can require that passwords be exactly 8 characters long. Alternately, Password Manager can support longer passwords, but truncate them when it updates the mainframe (users generally prefer a fixed length, as it is easier to understand).
All systems enforce two types of password rules:
A global password policy is normally created by combining and strengthening the best-of-breed complexity requirements from each system affected by the policy. Password Manager then combines these with the most restrictive storage constraints. This forces users to select strong, secure passwords on every system.
The alternative, of defining different password policies for every target system or for groups of target systems, is less user friendly. To update their passwords, users must select a system, choose a password, wait for the password update to complete, choose another system, select and input a different password, etc. Users must then remember multiple passwords and will continue to experience many password problems. It has been shown that users with many passwords have a strong tendency to write down their passwords.
The recommended global password policy depends on the system with the most limited password fields. In many large organizations, this is often a z/OS mainframe, which only supports 8-character passwords, composed of letters, digits and three "special" characters (@, #, $).
There are 39 possible characters in a password (letters, digits, 3 specials).
Note: the total search space is 397 + 398 = 5,489,240,267,160 possible passwords.
There are 95 possible characters in a password (lowercase, uppercase, digits, 32 symbols on a US keyboard, space).
Note: the total search space is no less than 957 = 69,833,729,609,375 possible passwords.
Password policy is enforced on both the Password Manager server and each of the managed systems. Ideally, each managed system enforces the largest possible subset of the policy rules enforced on the Password Manager server. In cases where a managed system initially had a rule that conflicts with the new global policy (i.e., it is impossible to compose a password that is simultaneously compatible with both the old native policy and the new global policy), the native policy should be adjusted to be compatible.
Password policy must not be disabled on any existing system, as this would allow users to bypass policy by making native password changes, without interacting with Password Manager.
Password policy must not be disabled on the Password Manager server, as this would allow users to bypass policy by making password changes using Password Manager, whose password resets are often subject to lesser restrictions when it commits new passwords to integrated systems.
Password synchronization makes the security of managed systems equivalent, in the sense that if an intruder can compromise one password, the intruder can infer the value of the same user's passwords on other systems.
Password reset processes make passwords equivalent to the non-password authentication used to identify users who forgot their passwords or locked out their account.
Single sign-on makes the security of all in-scope applications the same as the security of an initial authentication.
Enrollment processes create security equivalence between the process used to sign into the enrollment system (usually a password) and the security questions or other data that are subsequently enrolled.
Organizations that do not take these connections into account can inadvertently lower the security of their entire organization. For example, if password reset processes authenticate users purely using security questions, and if the answers to those security questions are collected in an enrollment process, then the security of user profiles is only as good as the security of the credentials used to enroll those security questions.
Some organizations use a PIN, sent via e-mail or physical mail, to authenticate users prior to enrolling security questions. This makes the security of all subsequent passwords only as a good as that first PIN -- incredibly weak.
To ensure that user profiles are secure, follow these guidelines:
Most organizations use security questions as at least part of the process for authenticating users who forgot or locked out their password.
A password reset process makes the security of password authentication equivalent to the security of non-password authentication. This means, for example, that there is no sense in enforcing a strong password policy if users are authenticated to a password reset system with a 5 digit PIN, such as the last part of a social security number.
Since password reset is provided to users who forgot their password, it makes sense to setup security questions whose answers users will not easily forget:
Some additional recommendations for authentication with security questions:
Ask users to enroll answers to standard questions, as the difficulty of guessing answers to these can be estimated.
Also ask users to define their own question/answer pairs, as an attacker will not know what questions to research. Users often choose weak questions, so these should always be combined with standard questions, of a known 'quality.'
Always prompt users to answer standard questions first, and only ask for answers to self-defined questions if correct answers to standard questions were entered. This reduces the odds that an attacker will know what user-defined questions to research.
Ask legal counsel to review the offered, standard security questions. Avoid questions which may have legal consequences, such as social security numbers.
Ask each user to enroll more question/answer pairs than will be used in any given authentication process. Prompt the user to answer only a random sample of those questions at login time. If the user answers incorrectly, prompt the user to answer the same questions again (not a new/random sample after a failed login), as this prevents attackers from "shopping" for questions whose answers they have already worked out.
If a given user fails to sign in several times in a row, lock out his user profile and do not accept further login attempts for a period of time. The number of failed attempts can be higher than might at first seem reasonable -- say 10 failed logins in 30 minutes. The lockout can be automatically cleared after a while -- say 20 minutes. The objective is simply to slow down guessing attacks against passwords or security questions.
Intruder lockouts should apply to IP addresses as well. If user connections to Password Manager originate at distinct IPs, rather than a load balancer or reverse web proxy, then it's reasonable to lock out addresses that generate many login failures, as those may be used by an attacker. Be sure not to lock out any network infrastructure that aggregates traffic, however.
Sample security questions, which may have alpha-numeric questions and so are suitable for a text user interface, include:
Sample security questions, that have numeric answers and so are suitable for authentication using a touch-tone phone, include:
Security questions can be vulnerable to "social engineering" attacks, where an attacker does background research on a target user and subsequently impersonates that user by answering their security questions. It is therefore desirable to augment security questions with another credential. It is advisable to use the other credential before asking the user to answer security questions, so as not to show a would-be attacker what questions a user has enrolled answers to.
Common options for a second factor are:
Which factor to use depends on what the user in question has. For example, does the user have an RSA token? Has the user enrolled their mobile phone number? Has the user provided their personal e-mail address?
A credential management system must first integrate with the systems on which it sets passwords, PINs, certificates, biometrics, etc. This card management systems (smart cards), token authentication servers (OTP validation) and full disk encryption systems.
Credential management systems frequently also integrate with other IT infrastructure:
Purpose of the integration
|When to activate|
Invite users to enroll; remind users to change their passwords;
notify users of events relating to their profile, such as queued
password changes or intruder lockouts.
|Initially. Every Password Manager system should be able to send e-mails.|
Incident management (ticketing)
Create, update and/or close tickets to reflect events.
Support centralized metrics of IT support activity, including
self-service. Raise incidents to resolve technical problems,
such as faults reported by connectors.
|Useful in every deployment, but many defer this beyond the initial deployment.|
Full disk encryption system
Enable users to unlock their PC if they forgot their pre-boot password.
|Essential in every organization that has (a) full disk encryption and (b) password authentication pre-boot. Should be deployed early if possible.|
Enable users to reset forgotten, locally cached Windows passwords
|In organizations where many users work off-site, or even where fewer but high-value people work off-site, providing password reset to these users is essential. This can only be done via deployment of client software and integration with the VPN. Should be deployed early if possible.|
One time password tokens
PIN reset, clock synchronization, issuing emergency pass codes.
|Enable users who forgot their token at home or forgot their PIN to regain access. Usually deployed in the first phase where required at all.|
Telephony infrastructure, IVR
Offer self-service password or PIN reset, filesystem unlock
via phone call.
|Filesystem unlock and PIN resets for tokens used to sign into the VPN cannot be accessed from a PC browser, because the former is pre-boot and the latter is off-site. Phone call access to self-service can address these problems.|
Mobile device management (smart phones)
Offer self-service via smart phone apps.
|Deploy smart phone apps to enable users to manage credentials from BYOD.|
Smart cards, card management system
PIN reset, emergency pass codes. Requires client-side code to
integrate with card readers and integration with the CMS to retrieve
card unblock codes.
|Enable users who forgot their smart card at home or forgot their PIN to regain access. Usually deployed in the first phase where required at all.|
Where users have different login IDs on different systems,
any pre-existing mapping data should be leveraged. Accelerate
creation of credential management system user profiles (do not wait
for auto-discovery to run).
|The first scenario applies where IDs are inconsistent across systems. The second applies where new users are onboarded and need to use the credential management system immediately.|
Leverage pre-existing security question data.
|Either an initial bulk load or real-time lookup/validation.|
Proxy system in DMZ or "cloud"
Mediate communication between on-premise systems and BYOD.
|Phones and tablets are usually not attached to the corporate network. Allow these BYOD's to connect to a public URL, which authenticates a local app and forwards information to one of a pool of connections accepted from the on-premise credential management system.|
Most deployments call for two or three Password Manager servers, preferably at two locations, each with its own local database instance and with the application arranging for real-time data replication between the database instances. User connections are load balanced across the servers.
This arrangement has many advantages:
Too many servers can create high network traffic for replication. Too few mean inadequate redundancy in the event of a disaster.
A Password Manager server is typically configured based on standards set out in the data center where it will be installed.
The file-system of the servers may be segmented as follows:
|Password Manager Server Configuration|
|The operating system and downloaded patches. The MSSQL database server software.|
|The Password Manager application and any third party software.|
300 or more
|Database contents (MSSQL)|
Three working environments are normally deployed:
Separating development from integration testing environments enables Hitachi ID Systems to proceed with developing new features and integrations and with troubleshooting, at the same time that Hitachi ID Systems customer tests previously released versions.
Separating integration testing from production environments enables Hitachi ID Systems customer to apply strict quality and change controls over its production environment, to avoid outages, misconfigurations and ultimately any adverse user or systems impact.
These three environments should have the following characteristics:
In some cases, the connection to a target system may be slow, insecure or simply blocked by a firewall. This is often true when the connection is made over a wide area network or requires the use of an insecure protocol but must cross an untrusted network segment.
To address such connectivity problems, Password Manager includes an application proxy server. When a proxy server is deployed, the main Password Manager server ceases to communicate with one or more (usually distant) target systems directly and instead forwards all communication to those systems through one or more proxy servers, which are co-located with the target systems in question.
Communication from the main Password Manager server to the proxy server(s) is encrypted, efficient and tolerant of high latency. It uses a single, arbitrarily-numbered TCP port number. Connections are strictly from the main Password Manager server to the proxy server (never back). A single TCP port supports an arbitrarily large number of target systems at the proxy server's location.
These characteristics of the communication between a Password Manager main server and a proxy server mean that firewall administrators will normally be willing and will always be technically able to route or forward a TCP port from the main server IP address to the proxy server IP address.
Communication between the proxy server and target systems continues to use native protocols. It is normally physically secured, in a high-bandwidth, low-latency, high-security data center network.
Deployment of the secure Password Manager proxy server is illustrated in Figure [link].
Hitachi ID Systems makes available detailed instructions for hardening Password Manager servers. These instructions are available on-line here:
Password Manager runs on the Windows server platform, but aside from client libraries for target systems, actually uses very little Windows technology. This makes it possible to disable almost every component of the Windows server OS, significantly reducing the attack surface.
Server hardening typically involves the following:
Some of the most effective security measures are common sense:
Password Manager servers should be physically protected, since logical security measures can often be bypassed by an intruder with physical access to the console:
Put Password Manager server(s) in a locked and secured room. Restrict access to authorized personnel only. Password Manager administrators should install and configure the server(s) and then only access it remotely via HTTPS to its web portal or RDP to the OS.
Ensure that server power is protected, that graceful shutdowns occur when power is interrupted and that there is surge protection at least on incoming power connections.
Configure the server to boot from its physical or virtual hard drive and not from USB or optical drives.
Where the Password Manager server is virtualized, apply the above controls to the hypervisor.
Install the latest service packs, as these frequently include security patches and updates.
Keep up-to-date with the latest Windows security upgrades by subscribing to Microsoft's security bulletin at:
One way to limit the number of users who can access the Password Manager server is to remove it from any Windows domain. If the Password Manager server is not a member of a domain, it reduces the risk of a security intrusion in the domain being leveraged to gain unauthorized access to the Password Manager server.
For any accounts that must remain, limit their access. At a minimum, block access by members of 'Everyone' to files and folders on the server.
If feasible, turn off the remote access and management features on the server to protect the server from remote access attempts using brute force password attacks. This includes the following:
If remote administration of the OS is required:
Open ports are an exploitable means of system entry. By limiting the number of open ports, you effectively reduce the number of potential entry points into the server. A server can be port scanned to identify available services.
Use packet filtering to block all inbound connections other than the following default ports required by Password Manager:
Default TCP port
|443/TCP||IIS / HTTPS web service.|
|5555/TCP||Password Manager database service default port number (iddb).|
|2380/TCP||Password Manager file replication service default port (idfilerep).|
|3334/TCP||Password manager service (idpm).|
|2340/TCP||Session monitoring package generation service (idsmpg).|
|4444/TCP||RSA Authentication Manager Service (psace) - if RSA tokens are managed.|
On Windows Server 2012, packet filtering is accessed by running the wf.msc control.
IIS is more than a web server; it is also an FTP server, indexing server, proxy for database applications, and a server for active content and applications. Disable these features as Password Manager does not use them.
Create two separate NTFS partitions - one for the operating system and one for content IIS serves up. This will protect the OS from IIS compromise.
Always deploy a proper, issued-by-a-real-CA SSL certificate to Password Manager servers and disable plaintext HTTP access. Never use a self-signed certificate in a user-facing system, as this may condition users to ignore SSL validity warnings.
Assign the IIS user the right to execute CGI programs but not other executables on the Password Manager filesystem.
Disable directory browsing -- there is no reason why a user connecting to the Password Manager web portal should be able to list files in any folder.
Don't install anything beyond the core SQL server software. Specifically, leave out or disable:
Password Manager will connect to the database locally, so network access can and should be disabled. Use SQL Configuration manager to disable all but shared memory access to the database.
After installing the SQL Server database software and Password Manager, remove access by the OS Administrators group to the database and change the password for the sa account.
Configure a dedicated, local-admin account for use by the The SQL Server Agent service, so that it runs in a different security context than the database itself.
Since Password Manager is a sensitive security application, with privileged access to many other systems in an organization and with access to sensitive personal data, most organizations are unwilling to expose Password Manager directly to the public Internet. This creates a problem for mobile device access to self-service, as illustrated in Figure [link].
Hitachi ID Systems has developed a solution to this problem, by installing and activating an app natively on iOS and Android devices and hosting a proxy server in the cloud. This arrangement is shown in Figure [link].
Using this architecture:
In most deployments, Password Manager fetches a full list of user IDs from every managed system, every night. This minimizes the need to manage accounts in Password Manager directly.
In most installations, Password Manager is configured to "trust" one or more systems to be an authoritative source of Password Manager user profiles. Any user who is added to an authoritative system will, during the auto-discovery process, be automatically added to Password Manager. Conversely, users removed from all authoritative systems will be automatically removed from Password Manager.
This process ensures that users do not have to be explicitly or manually enrolled in or removed from Password Manager.
Users sign into Password Manager with their login ID on the authoritative system.
Where there is no obvious authoritative system, e-mail addresses or employee IDs can be extracted from an existing system and used as the authoritative ID.
Every enterprise identity management and access governance system, regardless of its features, must support login ID reconciliation. Users have login accounts and other records on various systems and these have to be attached to a single profile, in order to create a user-centric identity system. The process of attaching non-standard login IDs and other user identifiers to a single profile is called login ID reconciliation.
Password Manager supports multiple options for login ID reconciliation, as follows:
When self-service login ID reconciliation is required, it works as follows:
Self-service reconciliation is inexpensive (about 5 minutes per user), reliable, fully automated (users are reminded to register until they actually do) and very secure.
Both self-service and administrative login ID reconciliation are logged. Other forms of login ID reconciliation are typically batch oriented and can be configured with logging if required.
Note that attempts to reconcile login IDs by matching on attributes of user profiles on target systems are often costly and/or insecure, especially when combined with a password management system:
Where self-service login ID reconciliation is required, the process is both inexpensive (25,000 users spending 5 minutes each costs nothing, while one consultant spending weeks or months is expensive) and error-free (since IDs are claimed with a validated password). This process is, to the best of Hitachi ID Systems knowledge, unique.
In many organizations, deployment of a credential management system requires a user enrollment process. Enrollment may be to get users to:
Where enrollment is required, it is helpful for the credential management system to automate the process by identifying users who must be enrolled, inviting and reminding them to enroll and provide a strongly authenticated enrollment user interface.
Password Manager includes built-in infrastructure to securely and automatically manage the user enrollment process:
Figure [link] shows a dashboard that tracks enrollment progress.
To all users: Acme, Inc. is activating a credential management system. This system will help you to manage your own passwords by: * Synchronizing passwords across your various login accounts. * If you forget your password or lock yourself out, you will be able to resolve the problem without calling the help desk. Please take a few moments to register with the credential management system now: * Click on the URL below. * Sign in with your Windows/AD ID and password. * Answer security questions as prompted. * Enter your mobile phone number and/or personal e-mail address as prompted (these will only be used to send you PINs at login time). * Please install the Hitachi ID Mobile Access app on your phone (it's on the Apple and Google markets) and activate it. This will help you access the system while away from the office. Register now: https://password.acme.com/ Once enrolled, whenever you change your Windows password, all other logins will automatically get the same, new password. After completing your profile and installing the app on your phone, if you forget or lock out your Windows password, you will be able to click the 'Password Reset' tile on your Windows PC to get help, use the app to unlock your pre-boot password or reset your RSA SecurID PIN. If you have any questions, please contact email@example.com. Thank you! -- The IT department.
Password Manager generates a return on investment (ROI) by lowering IT support cost. This only happens when users experience fewer problems and choose self-service rather than calling the help desk. In other words, user adoption determines ROI.
Following are best practices for increasing user adoption and ROI.
Help users help themselves:
Send mass e-mails introducing the system and explaining (a) why it is being deployed and (b) how to use it.
Offer incentives to users who complete their profiles early. Incentives can be quite inexpensive compared to the cost savings due to lower call volume and reduced head count at the help desk. Examples may include a draw for gift certificates, physical prizes (often electronic gadgets), etc.
Users should get automated reminders to complete enrollment:
Failure to send automated, personalized, persistent invitations to users leads to low adoption rates. This feature is really not optional.
Some organizations opt to enroll callers to the help desk who have not already completed their profiles. This can be effective but is a very expensive strategy, effectively negating any ROI from the system. Not recommended.
Consider departmental charge-backs and e-mails to a user's manager whenever a user opts to call the help desk rather than utilizing self-service. This is a negative incentive, making it clear to users that continuing with business as usual is undesirable.
If users continue to call the help desk, park their calls on an audio message explaining self-service before they can speak to a human. This acts as another dis-incentive to continued calls to the help desk for services that are better completed via self-service.
The key point regarding user adoption is to plan for a user engagement program. Failure to plan is really planning for failure.
The following sections describe the routine ongoing administration of Password Manager:
Periodically test the functionality of the Password Manager server. If any component should fail, it is better to discover it pro-actively than wait for users to notice and complain.
Create a test user that has at least one login ID on every system where Password Manager manages passwords. Regularly use either the administrator (PSA.EXE) or self-service (PSS.EXE) UI to change every password for this user. Make sure all passwords are changed, both through success messages in the UI and by trying to sign into each system with the new password.
If you implemented web-based registration, verify that a test user can update his own security questions, phone number and e-mail address.
If you deployed transparent password synchronization (highly recommended), periodically verify that a native password change does, indeed, trigger automatic password updates for the same user on other systems.
Verify that help desk staff can log into the application and have the rights to reset passwords for users (e.g., for the test account mentioned above). Create a help desk user account for this purpose.
Monitor e-mails sent by the system. It should regularly send e-mails to users reminding them to change passwords and to new users inviting them to enroll. This is a critical feature, without which user adoption will be very low.
If you implemented ticket system integration, trigger relevant events, such as intruder lockouts, and verify that tickets are generated and populated appropriately.
If you implemented an IVR user interface, verify that it is reachable, is able to identify and authenticate a test caller and can reset passwords and PINs.
If you enabled access from smart phones (highly recommended!), verify that it remains possible to sign into the system from an activated smart phone. Verify that new users are invited to install the app on their phones and are able to activate it.
If you enabled access to self-service password reset from the Windows login screen from off-site, verify that this remains possible. Take a corporate laptop to a nearby coffee shop and access self-service from the Windows login screen.
If you enabled access to self-service filesystem unlock for PCs or laptops that require a pre-boot password, ensure that unlock is accessible, using either the IVR or smart phone app to access Password Manager.
Changes made to the configuration on some targets can have an impact on Password Manager. Be sure to include testing of password changes in the change control process for every integrated system and application.
Verify that all Password Manager services, including the database service (IDDB), the password management service (IDPM), log service, etc. are running at all times.
Use the Password Manager dashboard to monitor how many users there are in the system and how many of them have completed enrollment. Use built-in reports to monitor utilization of the system -- number of logins and passwords changes per day and per week.
Regularly run reports to search through logs and find error messages and e-mail those to the Password Manager administrator, to investigate and follow up on.
Password Manager deployment is straightforward and can be completed in a matter of weeks, typically requiring only a few days of professional services.
Because Password Manager impacts so many groups in an IT organization, it is important to have powerful and visible program sponsorship and to involve all stake-holders as early as possible.
Password Manager should be made available where users are, because users will need it to resolve login problems. This means pre-boot if users type a password to unlock filesystem encryption; at the PC login screen if laptops cache domain passwords; on-site and off-site; using their smart phones (app), a phone call and of course using a full screen web browser.
A successful deployment will expand over time. Some organizations start small - simple on-premise AD password reset, but then grow over time, to include access from mobile phones, pre-boot unlock for users with encrypted filesystems, password synchronization across legacy and SaaS applications and password reset for off-site laptops. To achieve this, long-term staffing is required. A single, strong technical resource is more than adequate, and in fact a fractional FTE is often all that's required.
This document outlines numerous best practices regarding features and integrations, network architecture, policies, user enrollment and adoption stake-holder engagement and ongoing support. These should be taken as guidelines and combined with specific organizational requirements to produce an implementation design and project plan.