Hitachi ID Password Manager Deployment Best Practices

Hitachi ID Password Manager

Deployment Best Practices

1 Introduction 1

2 System objectives 3

3 Mission statement 4

4 Metrics 5

5 Stake-holders 6

6 Deployment and support team 8

7 Features and design 10

8 User access to the self-service UI 12

9 Formulating a uniform password policy 13 9.1 Strategy ...... 13 9.2 Suggested policy rules ...... 13 9.3 Where to enforce password policy ...... 14

10 Equivalent credentials 15

11 Security questions 16 11.1 Security equivalence ...... 16 11.2 Memorable questions ...... 16 11.3 Other best practices ...... 16 11.4 Sample questions ...... 17

12 Augmenting security questions with a second factor 20

13 Infrastructure integrations 21

14 Hitachi ID Password Manager: technical architecture 23 14.1 Number and location of servers ...... 23 14.2 Conﬁguration of individual servers ...... 23 14.3 Development, test and production environments ...... 24

i Password Manager Deployment Best Practices

14.4 Proxy servers for hard-to-reach target systems ...... 26

15 Hitachi ID Password Manager: server hardening 27 15.1 Overview ...... 27 15.2 Physical security ...... 28 15.3 Operating system access ...... 28 15.4 IIS conﬁguration ...... 30 15.5 SQL Server conﬁguration ...... 30

16 Hitachi ID Password Manager: BYOD access to on-premises credential management 31

17 Auto-discovery of user profiles and accounts 33 17.1 Selecting sources of profiles ...... 33 17.2 Mapping login IDs to user profiles ...... 33

18 User enrollment 35

19 Maximizing user adoption and ROI 38 19.1 Minimize password problems ...... 38 19.2 User awareness ...... 38 19.3 Incentives for enrollment ...... 38 19.4 Automated reminders ...... 38 19.5 A call to IT support is not the right time to enroll ...... 39 19.6 Charge-backs and manager feedback ...... 39 19.7 Reduce SLA for help desk calls ...... 39 19.8 Plan for user adoption ...... 39

20 Ongoing administration and support 40 20.1 Functional test ...... 40 20.1.1 Password changes ...... 40 20.1.2 Enrollment ...... 40 20.1.3 Transparent password synchronization ...... 40 20.1.4 Help desk logins ...... 40 20.1.5 Sending e-mails ...... 40 20.1.6 Creating call tracking system ticket ...... 41

20.1.7 IVR (phone call) integration ...... 41 20.1.8 Mobile access ...... 41 20.1.9 Off-site, Windows login screen access ...... 41 20.1.10 Filesystem unlock ...... 41 20.2 Changes to target system conﬁguration ...... 41 20.3 Monitor service health ...... 41 20.4 Monitor utilization ...... 42

21 Summary 43

1 Introduction

The remainder of this document is organized as follows:

• System objectives – what credential management systems are designed to do.

• Mission statement – how organizations should structure their internal communication about priorities and objectives.

• Metrics – how to measure the impact on the system.

• Stake-holders – who to involve in design, implementation and ongoing support.

• Deployment and support team – who the core individuals are that must build out and support the system and what their initial and long term commitment will be.

• Features and design – what processes the system should automate.

• User access to the self-service UI – how to ensure that users can resolve login problems wherever they may be, at any time and on any device in any state.

• Formulating a uniform password policy – how to develop a set of password rules that work for every system and every user community.

• Equivalent credentials – caution about weak links in security and how to avoid them.

• Security questions – design considerations for enrolling security questions and using them to authenticate users who forgot their password.

• Augmenting security questions with a second factor – how to improve security by front-ending security questions with a stronger, one-time-password credential.

• Infrastructure integrations – what systems the credential management automation should integrate with.

• Hitachi ID Password Manager: technical architecture – the runtime platform and network architecture on which Password Manager is deployed.

• Password Manager: server hardening – how to lock down OS, DB and web servers to protect the system.

• Password Manager: BYOD access to on-premises credential management – how to enable users to access self-service from their phones or tablets, which are typically not attached to the corporate network.

• Auto-discovery of user proﬁles and accounts – how to minimize care and feeding of the system using auto-discovery.

• User enrollment – inviting users to answer security questions; install smart phone apps; etc.

• Maximizing user adoption and ROI – strategies to get users to enroll and to use the system to resolve login problems.

• Ongoing administration and support – what can be expected in terms of long term care and feeding of the system.

2 System objectives

A credential management system should deliver three beneﬁts:

• Improved user service: Fewer credentials for users to remember and manage and simpler, quicker and more convenient resolution for login problems.

• Lower IT support cost: Fewer help desk calls related to login problems such as forgotten passwords, intruder lockouts or tokens left at home.

• Stronger security: 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.

3 Mission statement

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 Before After User service / SLA Users manage 8 different passwords, on With password synchronization, users will only have to manage 2 average. passwords. Only some passwords expire and they Users will be prompted to change all passwords at the same time. do so at different times Different systems enforce different A uniform password policy will supersede multiple, inconsistent password policy rules. rules. Users sometimes forget their pre-boot Enable self-service ﬁlesystem unlock via smart phone app. password. Users sometimes forget their OS login Enable self-service password reset from the PC login screen, with password, in some cases while off-site. VPN+WiFi integration to support users working outside the ofﬁce.

IT support cost 30% of total help desk call volume is due Password synchronization and self-service problem resolution to login problems. will reduce this call volume by at least 80%. 5% of total call volume is due to OTP Offer self-service PIN reset and emergency passcodes via token problems. smart-phone app. Help desk calls to resolve login problems Consolidate caller authentication, technician login, problem take 10 minutes to resolve, on average. resolution and ticket generation behind a single UI, to reduce call duration to 2 minutes.

Security / authentication Users have too many passwords and Synchronization will eliminate the main user motivation for writing write them down. down passwords. Different systems and applications Implement a uniform policy with a superset of password enforce different password policies. composition, reuse and change frequency rules. Users calling the help desk are not Move most incidents to self-service and apply uniform reliably identiﬁed. 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 Support staff will reset passwords through an assisted-service with elevated rights, required to reset portal, eliminating the need for such accounts. passwords for people who call the help desk.

4 Metrics

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:

1. Number of systems that maintain their own, distinct password, rather than leveraging Kerberos, LDAP, SAML, etc. to externalize authentication.

2. Number of distinct passwords an average user must remember and manage.

3. Average number of login prompts faced by a user, during a work day.

4. Number of systems (with their own passwords) able to enforce password complexity rules consistent with enterprise policy.

5. Password change frequency – required versus actually enforced.

6. Help desk call volumes related to login problems:

(a) Forgotten passwords, per system, per month. (b) Intruder lockouts, per system, per month. (c) Filesystem lockouts (forgotten pre-boot password), monthly. (d) Token problems (left at home, lost, stolen, forgot PIN), monthly. (e) Forgotten passwords by users off-site, monthly. This is different than forgotten passwords per system because it refers to users who cannot unlock their PC until they bring it back to the ofﬁce – an especially disruptive type of problem.

5 Stake-holders

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 proﬁle 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 Section 2 on Page 3:

• Project Sponsor: Provide mandate and budget for the project. Ensure cooperation from other stake-holders.

• Project Manager: Ensure the project is managed effectively by providing and coordinating customers resources.

• Network Architect: Develop and approve network-level design documents. Place servers on the network and specify integrations, for example with VPNs, SSL concentrators, reverse web proxies, etc.

• Credential management application administrator: Responsible for ongoing conﬁguration, administration, enhancement and upgrades to Hitachi ID Password Manager, post production deployment. Assists in implementation of the system prior to moving to production, in order to gain maximum familiarity with the software and conﬁguration.

• Security Ofﬁcer: Review, document and approve any changes that impact corporate security, including policies, authentication processes, SIEM integration, VPN integrations, any service or generic accounts, etc.

• Auditor: Deﬁne audit requirements, such as data retention, periodic review of user privileges, etc. Periodically review activity on the system.

• IT support manager: Often fund the system, to reduce call volumes and head count. Provide integration details and support for ticketing system. Deﬁne user-support processes.

• System administrators: (for every integrated system) Provide integration details for each target system, provide service accounts and test IDs and verify correct operation. Assist with troubleshooting integrations.

• Intranet manager: Provide user interface standards, including sample HTML, CSS and JS, to ensure that Password Manager matches enterprise standards.

• Network operations: Support deployment of servers, including hardware, VMs, OS images, DNS names, network routes, TLS certiﬁcates and/or termination, load balancing and system health monitoring.

• Desktop support: Deploy client-side code and policies that allow/block execution of same.

6 Deployment and support team identity and access management (IAM) implementations 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 IAM system and consequently lead to implementation and maintenance effort. In other words, ongoing investment is a good thing – it means that the business beneﬁts from a constantly expanding set of capabilities.

This is not to imply that individual deliverables cannot be implemented quickly and operated efﬁciently. Rather, successful implementation of one feature or integration usually triggers interest by new stake- holders, who request additional features or integrations.

With this in mind, it is helpful to think of IAM process automation as iterative optimization. Ongoing expan- sion in the scope of system should be the responsibility of a permanent team, rather than implemented by a team assembled for a single set of deliverables.

Successful organizations create a permanent IAM program, rather than stafﬁng for a short-term deployment project. The IAM team should include at least a technical application administrator and business owner.

Organizations should assign a fractional FTE (e.g., 0.25) to manage Hitachi ID Password Manager.

As with any long term program, it is important to have clear buy-in from stake-holders and an up-front agreement on system scope, deliverables, duration and cost in order to sustain investment and deliver on business expectations.

The permanently assigned customers team should consist of one or two individuals who have as many of the following skills as possible:

• System and process design: – Security policy. – Network and data architecture. – IT support infrastructure and processes. • Product installation, ongoing administration: – Windows / AD administration. – Web server conﬁguration and management. – Web application deployment and administration. • Initial integration and ongoing updates and extensions: – Familiarity with each target system. – IT support infrastructure and processes. – E-mail infrastructure. – interactive voice response (IVR) infrastructure, if telephony integration is in scope. • Development of business logic: – Programming or scripting (e.g., Python, Powershell, VB, Java). – Familiarity with data sources: LDAP, RDBMS, etc. – Familiarity with web applications, including HTML and optionally (to support a more interactive UI) JavaScript.

• UI customization:

– HTML and CSS markup. – JavaScript and AJAX if highly interactive forms are in scope. • Deployment and ongoing support:

– IT support infrastructure and processes. – User education. – Metrics.

7 Features and design

The ﬁrst 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 Hitachi ID 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.).

• Transparent password synchronization: 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. If accepted, the password is changed both locally and on other systems where the user has accounts. Password Manager includes password synchronization triggers for Active Directory, Windows servers, OID, Linux and Unix (various), iSeries and z/OS (optional component). Using a familiar and mandatory password change process guarantees 100% user adoption.

• Web-based password synchronization: Users can change some or all of their passwords using the Password Manager web portal. The password policy is clearly explained on-screen and enforced interactively. Using an interactive web page to change passwords has educational beneﬁts but requires user awareness and cooperation.

• Self-service password reset: 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.

• Self-service ﬁlesystem unlock (pre-boot, full-disk encryption) Users with drive encryption software on their PC, who have forgotten the password that unlocks their computer pre-boot, can unlock their PC via self-service phone call or mobile app.

• Token and smart card PIN reset: 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.

• Assisted password reset:

Authorized IT support staff can sign into a Password Manager web portal to look up a caller’s proﬁle, authenticate the caller by keying in answers to security questions and reset one or more passwords or clear an intruder lockout. A ticket can be automatically submitted to the help desk incident management system. The help desk analyst does not require any privileges on the affected directories, systems or applications.

• Password policy enforcement: 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 enforcement includes over 50 built-in rules regarding length, mixed-case, digits, dictionary words and more. Regular expressions and plug-ins enable organizations to deﬁne new rules. Password history is inﬁnite by default.

• Password change notiﬁcation / early warning: 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, SMS, 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.

8 User access to the self-service UI

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 ofﬁce 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:

1. A user who forgot or locked out their PC login password needs to be able to navigate to a password reset system from the PC login screen (Credential Provider on Windows Vista and later). 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.

2. A user who forgot their pre-boot password, used to unlock a full disk encryption product, needs to be able to interact with an unlock process to boot the OS on their PC. Later, once they have started up the OS, they can update the pre-boot password. 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.

3. A user who is off-site and has problems signing into the VPN should be able to interact with a solution on the Extranet, or via a phone call, or using an app on their smart phone, to unlock their credentials (typically a one time password token such as RSA SecurID).

4. A user who forgot the PIN to their smart card needs to interact with an application on their PC, rather than a smart phone app or voice phone call, since problem resolution involves inserting the card into a reader and having software push an unblock code into the smart card. Smart cards are often used as the main PC login credential, so this kind of self-service needs to be made available at the PC login screen, rather than just from a web UI available to the already signed-on desktop.

9 Formulating a uniform password policy

9.1 Strategy

Hitachi ID Password Manager is normally conﬁgured 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 conﬁgured 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 ﬁxed length, as it is easier to understand).

All systems enforce two types of password rules:

• Complexity requirements ensure that users do not select easily-guessed passwords. Example rules are: disallowing any permutation of the user’s login ID, password history, requiring mixed letters and digits, forbidding dictionary words, etc.

• Character set and length limits on what can be physically stored in the password ﬁeld on a given system.

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 deﬁning 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.

9.2 Suggested policy rules

The recommended global password policy depends on the system with the most limited password ﬁelds. 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 (@, #, $).

• For organizations with a mainframe

– Length: 7 or 8 characters. – Characters: at least 2 letters, at least 1 digit, specials must be @, # or $. – Special words: no dictionary word, login ID or permutation thereof.

– Repeats: no more than 1 pair of repeating 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.

• For organizations without a mainframe

– Length: 7 or more characters. – Characters: at least 2 letters, mixed case, at least 1 digit. – Special words: no dictionary word, login ID or permutation thereof. – Repeats: no more than 1 pair of repeating characters.

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.

9.3 Where to enforce password policy

Password policy is enforced on both the Hitachi ID 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 conﬂicts 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.

10 Equivalent credentials

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 proﬁles 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 ﬁrst PIN – incredibly weak.

To ensure that user proﬁles are secure, follow these guidelines:

• Password synchronization should go hand in hand with a requirement to use strong, frequently- changing passwords.

• Password synchronization should not include systems with very weak security infrastructure (e.g., systems that store password in plain-text, or that have no intruder lockout mechanism triggered by repeated failed logins).

• Self-service password reset should incorporate multi-factor authentication, such as sending a PIN to the user’s phone or e-mail as a ﬁrst authentication step and answering security questions as the second step.

• Where self-service password reset relies on security questions, the number and complexity of questions should be maximized, within the bounds of usability.

• Security question enrollment can follow authentication with an existing, strong password.

• It is not acceptable to authenticate users with a static or short PIN, an employee number or a date of birth – not even to enroll security questions.

• IT support staff should authenticate callers with a process just as strong as is used for self-service. Where privacy legislation prohibits some security questions, use other questions at the help desk, but don’t use fewer or weaker ones.

11 Security questions

Most organizations use security questions as at least part of the process for authenticating users who forgot or locked out their password.

11.1 Security equivalence

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.

11.2 Memorable questions

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:

1. It is not reasonable to use yet another password to authenticate users to a password reset system: if they forget the password they use daily, they won’t remember a password that was assigned to them months or years in the past.

2. Security questions should have static, factual and memorable answers. Avoid questions whose answers may change over time, such as “what is your favorite movie?”

11.3 Other best practices

Some additional recommendations for authentication with security questions:

1. Combine free-form and pre-defined 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.

2. Avoid personally identifying information Ask legal counsel to review the offered, standard security questions. Avoid questions which may have legal consequences, such as social security numbers.

3. Random sample 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.

4. Intruder lockout 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.

11.4 Sample questions

Sample security questions, which may have alpha-numeric questions and so are suitable for a text user interface, include:

• Which bank branch do you live closest too? • What was the make of your first car? • What was the model of your first car? • What is your favorite food? • Who is your favorite book character? • What is your favorite game or sport? • What is your favorite movie? • What is your favorite pizza topping? • What is your favorite season of the year? • What is your favorite sports team? • In which department in the company did you first work? • What was your first position in the company? • Who is the person you admire the most? • What was the most memorable day in your life? • Who was your childhood hero? • What is the nickname of your youngest sibling? • What is the nickname of your oldest sibling? • Who was your first boss? • What award are you proudest of? • What city were you born in? • What is the farthest from home you have traveled? • What is the name of the first school you attended? • What is the name of the first person you were romantically interested in? • What is your astrological sign? • What is your father’s middle name?

• What is your mother’s’ middle name? • Who is your favorite actor or actress? • What is your favorite musical band? • What is your favorite beverage? • What is your favorite board game? • Who is your favorite book character? • Who is your favorite author? • What is your favorite dessert? • What is your favorite hobby or pastime? • What is your favorite ice cream topping? • What is your favorite song? • What is your favorite television show? • What is your favorite vacation spot? • What is your mother’s maiden name? • What is your place of birth? • What is your school team’s mascot name? • What was the breed of your first pet? • What was the color of your first automobile? • What was the name of your first childhood pet? • What was the name of your last childhood pet? • What is the name of your first girlfriend/boyfriend? • What was the street name of your childhood home? • What was your favorite toy when you were a child? • What did you do on your first job? • What was your first phone number as a child? • On what year did you purchase your first car? • Who is your favorite politician? • Who is your most disliked politician? • Who is a famous, living person you would most like to meet? • Who was a famous, now deceased person you would have liked to meet? • Who is your favorite artist? • With whom did you share your first romantic kiss? • Who was your favorite elementary school teacher?

Sample security questions, that have numeric answers and so are suitable for authentication using a touch- tone phone, include:

• What is your favorite radio station (number on the dial - NNNN)? • In what year did you start with your company (CCYY)? • On what date were you hired? • What is your parents’ wedding anniversary date (MMDD)? • What are the last 4 digits of your SSN or SIN? • What are the last 4 digits of your childhood home phone number? • What is a birth date of your youngest child (CCYYMMDD)? • What is a birth day of your oldest parent (MMDD)? • What is a birth day of your youngest parent (MMDD)? • On what date were you married (CCYYMMDD)? • On what date were you divorced (CCYYMMDD)? • What is your employee number? • What is your employee number?

• What is your date of birth (MM/DD/YYYY)? • The last 4 digits of your passport number: • The last 4 digits of your driver’s license number:

12 Augmenting security questions with a second factor

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:

1. Send a random PIN to the user’s mobile phone or personal e-mail address.

2. Use a one time password device, such as an RSA SecurID token.

3. Use a smart phone app, such as DuoSecurity.

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?

13 Infrastructure integrations

A credential management system must ﬁrst integrate with the systems on which it sets passwords, PINs, certiﬁcates, 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:

System Purpose of the integration When to activate E-mail Invite users to enroll; remind Initially. Every Hitachi ID Password users to change their Manager system should be able to send passwords; notify users of e-mails. events relating to their profile, such as queued password changes or intruder lockouts. Incident management Create, update and/or close Useful in every deployment, but many (ticketing) tickets to reflect events. Support defer this beyond the initial deployment. centralized metrics of IT support activity, including self-service. Raise incidents to resolve technical problems, such as faults reported by connectors. Full disk encryption Enable users to unlock their PC Essential in every organization that has system if they forgot their pre-boot (a) full disk encryption and (b) password password. authentication pre-boot. Should be deployed early if possible. VPN Enable users to reset forgotten, In organizations where many users work locally cached Windows off-site, or even where fewer but passwords while off-site. 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 PIN reset, clock synchronization, Enable users who forgot their token at tokens issuing emergency pass codes. home or forgot their PIN to regain access. Usually deployed in the first phase where required at all. Telephony Offer self-service password or Filesystem unlock and PIN resets for infrastructure, IVR PIN reset, filesystem unlock via tokens used to sign into the VPN cannot phone call. 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 Offer self-service via smart Deploy smart phone apps to enable management (smart phone apps. users to manage credentials from BYOD. phones)

System Purpose of the integration When to activate Smart cards, card PIN reset, emergency pass Enable users who forgot their smart card management system codes. Requires client-side code at home or forgot their PIN to regain to integrate with card readers access. Usually deployed in the first and integration with the CMS to phase where required at all. retrieve card unblock codes. IAM system Where users have different login The first scenario applies where IDs are IDs on different systems, any inconsistent across systems. The pre-existing mapping data second applies where new users are should be leveraged. Accelerate onboarded and need to use the creation of credential credential management system management system user immediately. profiles (do not wait for auto-discovery to run). HR Leverage pre-existing security Either an initial bulk load or real-time question data. lookup/validation. Proxy system in DMZ or Mediate communication Phones and tablets are usually not "cloud" between on-premises systems attached to the corporate network. Allow and BYOD. 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-premises credential management system.

14 Password Manager: technical architecture

14.1 Number and location of servers

Most deployments call for two or three Hitachi ID 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:

1. No single point of failure.

2. Natural fault tolerance. Loss of a server or even a building only reduces capacity, but does not interrupt service.

3. Excellent scalability.

4. Ability to place Password Manager servers near target systems, to improve performance.

Too many servers can create high network trafﬁc for replication. Too few mean inadequate redundancy in the event of a disaster.

14.2 Conﬁguration of individual servers

A Hitachi ID Password Manager server is typically conﬁgured based on standards set out in the data center where it will be installed.

Production Password Manager application servers are normally conﬁgured as follows:

• Hardware requirements or equivalent VM capacity:

– Intel Xeon or similar CPU. Multi-core CPUs are supported and leveraged. Dual core is a minimum. – At least 16GB RAM – 32GB or more is leveraged and is typical for a server. – At least 600GB of HD storage, preferably in an enterprise RAID conﬁguration for reliability and preferably larger for retention of more historical and log data. More space is always better, to increase log retention. – At least one Gigabit Ethernet NIC.

• Operating system:

– Windows Server 2016 (recommended) or 2012 (still supported, but not in the next release). – All available service packs and hotﬁxes should be applied (automatically). – It is recommended that the server is not a domain controller. – Core mode on Windows Server is supported.

• Installed and tested software on the server:

– TCP/IP networking, with a static IP address and DNS name. – IIS web server with a valid SSL certiﬁcate and the following conﬁgured: CGI, HTTP redirect, URL Rewrite, and Dynamic Compression. – At least one web browser (i.e. Chrome) and PDF viewer. – Python 3.5.3 (64-bit). – A Git client (for revision control).

• A Microsoft SQL Server 2016 (recommended), 2014 or 2012 instance is required to host the Password Manager schema:

– Normally one database instance per application server. – The SQL Server database software can be deployed on the same server as the Password Manager application, as this reduces hardware cost and allows application administrators full DBA access for troubleshooting and performance tuning purposes. – SQL Server 2016, 2014 or 2012 Standard is recommended in almost all cases – SQL Express is acceptable for small deployments and evaluations.

The ﬁle-system of the servers may be segmented as follows:

Password Manager Server Conﬁguration:

Drive Size (GB) Contents C: 100 The operating system and downloaded patches. The MSSQL database server software. D: 100 The Password Manager application and any third party software. E: 100 Log ﬁles. Note, any third party software that logs should log here as well. F: 300 or more Database contents (MSSQL)

14.3 Development, test and production environments

Three working environments are normally deployed when Hitachi ID Password Manager is installed on- premises:

1. A development environment, where system administrators implement new versions of Password Manager, test out conﬁgurations, etc. This is where Hitachi ID Systems services staff do most of their work.

2. An integration testing environment, where new versions of Password Manager are validated before being migrated to production.

3. The production environment, which is subject to strict change controls.

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 customers tests previously released versions.

Separating integration testing from production environments enables customers to apply strict quality and change controls over its production environment, to avoid outages, misconﬁgurations and ultimately any adverse user or systems impact.

These three environments should have the following characteristics:

1. Development

(a) May use virtual machines for Password Manager servers. (b) There should be representative instances of each target type, but not necessarily as many of each type as there are in the other environments. (c) There should be representative instances of non-target systems with which Password Manager will be integrated (e.g., help desk, e-mail, etc.). (d) There should be a small number of users on each target, representing all user types. The number should be kept relatively small in order to expedite testing of code changes. (e) No change control is applied to this environment. (f) Hitachi ID Systems professional services staff should have continuously available remote control access to the Password Manager servers in this environment, to assist in conﬁguring new features and integrations.

2. Integration testing

(a) Should be a close mirror of the production environment. (b) May use virtual machines for Password Manager servers. (c) Should have as many Password Manager servers as production, to validate the setup of replication and load balancing. (d) Target systems should mirror production systems, as much as possible, in terms of number and type. (e) Each target system should have a recent snapshot of the user population from its corresponding production target system. (f) Hitachi ID Systems consulting staff may request remote control access to the Password Manager servers in environment, during integration testing. (g) Change control should be used to document changes to this environment. No special schedules or approvals are normally required for changes here.

3. Production

(a) Typically two or more load balanced servers. (b) Should be stable and closely monitored. (c) Storage should be reasonably performant, on the assumption that the database server instance runs on the same OS instance as the application. This means SAN or NAS storage when servers are virtualized. (d) Hitachi ID Systems normally requests remote control access to the Password Manager servers in this environment during production migration and subsequently only on an as-needed basis to help customers with any troubleshooting that comes up. (e) Change control should be used to review, approve and schedule changes in this environment, so as to minimize disruption to users and to other production systems.

14.4 Proxy servers for hard-to-reach target systems

In some cases, the connection to a target system may be slow, insecure or blocked. This may be because the connection spans multiple data centers or uses an insecure network protocol.

To address such connectivity problems, Password Manager includes a connector proxy server. When a proxy server is deployed, the main Password Manager server ceases to make direct connections to some target systems and instead forwards all communication to those systems through one or more connector proxies, which are co-located with the target systems in question.

Communication from the main Password Manager server to the connector proxy is encrypted and works well even when there is low bandwidth or high packet latency. It uses a single, arbitrarily-numbered TCP port number. Connections are established from the main Password Manager application server to the proxy server. A single TCP port supports an arbitrarily large number of target systems at the connector proxy’s location.

It is simple for ﬁrewall administrators to open a single TCP port per proxy server. Since connections are efﬁcient and encrypted, there are usually no objections to doing so.

Communication between the proxy server and target systems continues to use whatever protocol each system supports natively. This communication is conﬁned to a physically secure data center with a high- bandwidth, low-latency local network.

Deployment of the secure Password Manager proxy server is illustrated in Figure 1.

Figure 1: Target systems connected through a proxy server

Local network

Managed endpoints

Firewall

Hitachi ID Native protocol: Suite Fast, secure Slow? Plaintext? protocol Blocked by firewall? x Remote network

Firewall Possible TCP/IP + AES intruder Hitachi ID Proxy Server Various protocols

15 Password Manager: server hardening

15.1 Overview

Hitachi ID Systems makes available detailed instructions for hardening Hitachi ID Password Manager servers. These instructions are available on-line here:

Locking Down a Hitachi ID Identity and Access Management Suite Server

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, signiﬁcantly reducing the attack surface.

Server hardening typically involves the following:

1. Physically securing the Password Manager server.

2. Ensuring that the server has the latest service packs and hot ﬁxes from Microsoft and that new patches are applied automatically.

3. Removing all unneeded login IDs and renaming the Administrator account.

4. Uninstalling every unused service.

5. Minimize the number of system administrators who can sign into the server.

6. Detaching the server from the domain, to block domain administrators from signing in.

7. Enabling inbound packet ﬁltering to only allow deﬁned TCP ports.

8. Removing or disabling any unneeded features of the IIS web server.

9. Locking down ﬁlesystem access.

10. Enabling security audit logs, at least of all logins to the server.

11. Port scanning the server to check results.

Some of the most effective security measures are common sense:

• Use a single-purpose server for Password Manager. Sharing this server with other applications intro- duces more complexity and more administrators, each of which carries its own incremental risk.

• Use strong passwords for every administrative account on the server.

• Maintain a current, well-patched operating system on the Password Manager server. This eliminates well-known bugs that have already been addressed by the vendor (Microsoft).

• Automatically apply patches, especially security patches, to the OS, database server and any third party software.

• Keep the Password Manager server in a physically secure location.

• Provide security awareness training to all employees.

• Install and keep up to date anti-virus software.

• Do not leave a login session open and unattended on the Password Manager server’s console.

• Attach the Password Manager server to a secure, internal network rather than the public Internet. If access from the Internet is required, mediate it via a reverse web proxy running a different OS an web server platform than Password Manager – platform diversity reduces the risk of zero-day exploits.

• Regularly review Password Manager, OS and network logs.

• Use the Microsoft Security Compliance Manager to learn more about server hardening.

15.2 Physical security

Hitachi ID Password Manager servers should be physically protected, since logical security measures can often be bypassed by an intruder with physical access to the console:

• Restrict physical access Put Password Manager server(s) in a locked and secured room. Restrict access to authorized per- sonnel only. Product administrators should install and conﬁgure the server(s) and then only access it remotely via HTTPS to its web portal or RDP to the OS.

• Connect a UPS 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.

• Prevent boot from removable media Conﬁgure the server to boot from an internal drive and not from removable media.

Where the Password Manager server is virtualized, apply the above controls to the hypervisor.

15.3 Operating system access

Hitachi ID Systems recommends that Hitachi ID Password Manager servers are always conﬁgured to automatically and promptly download and install all vendor-supplied patches for the OS, DB and web server, as these often address security problems. There has never been, in Hitachi ID Systems experience, a compatibility problem with Password Manager caused by such automated patching.

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.

• Remove unused accounts, leaving just psadmin – the Password Manager service account.

• Create one administrator account to be used by the Password Manager OS administrator to manage the server and set a strong password on this account.

• Disable the default administrator account.

• Remove any Guest or unused service accounts.

• Remove the terminal services user account TsInternetUser. This account is used by the Terminal Service Internet Connector License.

For any accounts that must remain, limit their access. At a minimum, block access by members of ’Every- one’ to ﬁles 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:

• Check that "Enable remote management of this server from other computers" is disabled.

• Turn off "Remote Desktop Administration".

If remote administration of the OS is required:

• Edit the local security policy and remove Administrators from the Allow log on through Remote Desktop Services policy.

• Add an alternate account with lower privileges to the Remote Desktop Users group.

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 ﬁltering to block all inbound connections other than the following default ports required by Password Manager:

Default TCP Service port 443/TCP IIS / HTTPS web service. 5555/TCP Password Manager database service default port number (iddb). 2380/TCP Password Manager ﬁle 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. 2540/TCP Discovery service (iddiscover).

On Windows Server 2012, packet ﬁltering is accessed by running the wf.msc control.

15.4 IIS conﬁguration

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 Hitachi ID 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 certiﬁcate to Password Manager servers and disable plaintext HTTP access. Never use a self-signed certiﬁcate in a user-facing system, as this may condition users to ignore SSL validity warnings.

Assign the IIS user the right to read from but not write to static HTML, image ﬁle and Javascript ﬁles used by Password Manager.

Assign the IIS user the right to execute CGI programs but not other executables on the Password Manager ﬁlesystem.

Disable directory browsing – there is no reason why a user connecting to the Password Manager web portal should be able to list ﬁles in any folder.

15.5 SQL Server conﬁguration

Don’t install anything beyond the core SQL server software. Speciﬁcally, leave out or disable:

• SQL Server Analysis Services (SSAS). • SQL Server Integration Services (SSIS). • Full-Text Engine. • The Filter Daemon Launcher. • SQL Server Reporting Services (SSRS). • Active Directory Helper. • SQL Server VSS Writer service. • SQL Server Browser.

Hitachi ID Password Manager will connect to the database locally, so network access can and should be disabled. Use SQL Conﬁguration 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 Ad- ministrators group to the database and change the password for the sa account.

Conﬁgure a dedicated, local-admin account for use by The SQL Server Agent service, so that it runs in a different security context than the database itself.

16 Password Manager: BYOD access to on-premises credential management

Since Hitachi ID Password Manager is a sensitive security application, with privileged access to other systems in an organization and/or and with access to sensitive personal data, most organizations are unwilling to expose Password Manager directly to the public Internet (regardless of where it is hosted). This creates a problem for mobile device access to self-service, as illustrated in Figure 2.

Figure 2: Outbound connections are routine, inbound connections are risky and rarely permitted Risky, controversial, likely not allowed

Simple, uncontroversial firewall configuration

IAM server Personal Firewall Firewall device

Internet DMZ Private corporate network

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 3.

Using this architecture:

1. An app is installed on user devices.

2. Users sign into Password Manager with their PC and ask to activate their device.

3. The PC-based web UI displays an activation QR ode.

4. The user runs the app on their device, which scans this QR code.

5. The QR code includes encryption key material and a URL for a proxy service, in the cloud (i.e., on the public Internet).

6. Users use the app to (indirectly) access the on-premises Password Manager web portal.

7. The app connects to the cloud proxy, requesting content from the on-premises portal.

8. The proxy checks key material provided by the app and may discard connection attempts. In this way, connections from regular browsers or devices which have not been correctly activated for a particular Password Manager instance are easily discarded.

9. Simultaneously, a service on the Password Manager server connects to the proxy server, asking for page requests to fulﬁll.

10. The proxy passes requests from mobile devices to connections from the Password Manager server.

11. All connections that cross the corporate perimeter ﬁrewall in this architecture are outbound – from the Password Manager server to the cloud proxy.

12. All connections are encrypted.

Figure 3: Cloud proxy architecture

Internet

Personal Firewall Firewall IAM server device (2) HTTPS request: DMZ Private corporate “Includes userID, network Outbound connections only (1) deviceID” Worker thread: “Give me an HTTP request”

Cloud (3) proxy Message passing system

17 Auto-discovery of user proﬁles and accounts

In most deployments, Hitachi ID 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.

17.1 Selecting sources of proﬁles

In most installations, Hitachi ID Password Manager is conﬁgured to “trust” one or more systems to be an authoritative source of Password Manager user proﬁles. 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.

17.2 Mapping login IDs to user proﬁles

Every enterprise IAM 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.

Hitachi ID Password Manager supports multiple options for login ID reconciliation, as follows:

• Automatically, typically by matching consistent login IDs.

• By matching other attributes such as an SSN or employee ID, where they are available.

• By drawing on an external source of data – for example, some organizations maintain a mapping table or spreadsheet.

• Using a self-service reconciliation process.

When self-service login ID reconciliation is required, it works as follows:

• Users are automatically invited to complete their proﬁles – for example via an e-mail with an embedded URL.

• Users sign into the registration system, using a primary login ID and password or other types of credentials.

• Users are asked to type their additional ID/password pairs. Each provided ID/password pair is compared against an automatically maintained inventory of login IDs drawn from target systems, to find instances where the user-entered login ID appears on a system and does not yet belong to a known user profile. Password Manager then attempts to sign into that system with the user-entered password. If the login attempt succeeded, the user’s profile is updated with the system ID and the user-entered login ID.

Self-service reconciliation is inexpensive (about 5 minutes per user), reliable, fully automated (users are reminded to enroll 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 conﬁgured with logging if required.

Note that attempts to reconcile login IDs by matching on attributes of user proﬁles on target systems are often costly and/or insecure, especially when combined with a password management system:

• The only attribute that is commonly available on every system is a user’s full name. This may be inconsistent across systems and in many large organizations multiple users share the same full name and sometimes the same location.

• Failure to automatically correlate an account leads to manual, administrative reconciliation, which is expensive.

• Incorrect ID mapping allows one user to set another user’s password, which is a serious breach of security.

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.

18 User enrollment

In many organizations, deployment of a credential management system requires a user enrollment process. Enrollment may be to get users to:

1. Answer security questions; 2. Install and activate an app on their smart phone; 3. Provide their mobile phone number or personal e-mail address; 4. Attach accounts with non-standard IDs to their proﬁle; 5. Provide biometric samples, such as a voiceprint; 6. Review and accept corporate policy documents.

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.

Hitachi ID Password Manager includes built-in infrastructure to securely and automatically manage the user enrollment process:

• By monitoring one or more systems of record, Password Manager automatically creates new and removes old proﬁle IDs.

• New users and existing users with incomplete proﬁles are automatically invited to complete their proﬁles:

1. Answer security questions. 2. Install and activate Hitachi ID Mobile Access on their smart phones. 3. Provide contact information, such as mobile phone number or personal e-mail address, to which a PIN can be sent.

• Invitations to enroll may be e-mailed to users.

• Users may be more forcefully reminded to enroll by having a web browser automatically open to the enrollment page when they log into the network.

• Users may be forced to enroll, by opening a kiosk-mode web browser to the enrollment page when they sign into the network, and blocking access to the Windows desktop until users complete their proﬁle. This process is typically controlled by placing users into a “mandatory enrollment” AD group and attaching a suitable GPO to that group.

• To enroll, users must ﬁrst authenticate. This is normally done by leveraging an existing strong authen- ticator – such as a network password or a token.

• A single, integrated enrollment system supports collecting answers to security questions, mapping different login IDs, on different systems back to their owners, activating a smart-phone app, collecting mobile phone numbers or personal e-mail addresses and collecting biometric voice print samples.

The enrollment system in Password Manager includes schedule controls. For example, the maximum number of invitations to send daily can be limited, as can the frequency of invitations per user. Days-of- week during which to send invitations are identiﬁed as are holidays during which no invitations should be sent.

Figure 4 shows a dashboard that tracks enrollment progress.

Figure 4: Screen shot: Enrollment Statistics

Following is a sample invitation e-mail sent to users:

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.

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 protected].

Thank you!

-- The IT department.

19 Maximizing user adoption and ROI

Hitachi ID 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.

19.1 Minimize password problems

Help users help themselves:

1. Synchronize passwords, triggered by native password changes on Windows/AD.

2. Send users advance warning that their password will expire soon. This is especially helpful for users who frequently work off-site, and may not receive reminders from Windows.

3. Send password change reminders on Monday thru Thursday in the morning. This way, after users change their password, they will use the new password a few times before going home for the evening or weekend, and are more likely to remember it.

19.2 User awareness

Send mass e-mails introducing the system and explaining (a) why it is being deployed and (b) how to use it.

19.3 Incentives for enrollment

Offer incentives to users who complete their proﬁles 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 certiﬁcates, physical prizes (often electronic gadgets), etc.

19.4 Automated reminders

Users should get automated reminders to complete enrollment:

1. Reminders should be personalized, not mass mail.

2. Message severity should increase gradually. Start with a gentle e-mail, then a more stern e-mail, then one with the user’s manager copied.

3. The media used to send messages can also increase in severity. Start with e-mails, then automatically launch a web browser to the enrollment page at user login time and ﬁnally consider launching a full- screen, kiosk-mode browser that the user cannot close.

4. Throttle the total number of e-mails sent per day, so as not to overload the help desk with calls from users who are not sure how to comply.

5. Throttle the invitation frequency per user, so users don’t become accustomed to the e-mails and immediately delete them.

6. Schedule invitations for work days, not weekends or holidays.

Failure to send automated, personalized, persistent invitations to users leads to low adoption rates. This feature is really not optional.

19.5 A call to IT support is not the right time to enroll

Some organizations opt to enroll callers to the help desk who have not already completed their proﬁles. This can be effective but is a very expensive strategy, effectively negating any ROI from the system. Not recommended.

19.6 Charge-backs and manager feedback

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.

19.7 Reduce SLA for help desk calls

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.

19.8 Plan for user adoption

The key point regarding user adoption is to plan for a user engagement program. Failure to plan is really planning for failure.

20 Ongoing administration and support

The following sections describe the routine ongoing administration of Hitachi ID Password Manager:

20.1 Functional test

Periodically test the functionality of the Hitachi ID Password Manager server. If any component should fail, it is better to discover it pro-actively than wait for users to notice and complain.

20.1.1 Password changes

Create a test user that has at least one login ID on every system where Hitachi ID Password Manager man- ages 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.

20.1.2 Enrollment

If you implemented web-based registration, verify that a test user can update his own security questions, phone number and e-mail address.

20.1.3 Transparent password synchronization

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.

20.1.4 Help desk logins

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.

20.1.5 Sending e-mails

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.

20.1.6 Creating call tracking system ticket

If you implemented ticket system integration, trigger relevant events, such as intruder lockouts, and verify that tickets are generated and populated appropriately.

20.1.7 IVR (phone call) integration

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.

20.1.8 Mobile access

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.

20.1.9 Off-site, Windows login screen access

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.

20.1.10 Filesystem unlock

If you enabled access to self-service ﬁlesystem 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 Hitachi ID Password Manager.

20.2 Changes to target system conﬁguration

Changes made to the conﬁguration on some targets can have an impact on Hitachi ID Password Manager. Be sure to include testing of password changes in the change control process for every integrated system and application.

20.3 Monitor service health

Verify that all Hitachi ID Password Manager services, including the database service (IDDB), the password management service (IDPM), log service, etc. are running at all times.

20.4 Monitor utilization

Use the Hitachi ID 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 ﬁnd error messages and e-mail those to the Password Manager administrator, to investigate and follow up on.

21 Summary

Hitachi ID 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 ﬁlesystem 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-premises AD password reset, but then grow over time, to include access from mobile phones, pre-boot unlock for users with encrypted ﬁlesystems, password synchronization across legacy and SaaS applications and password reset for off-site laptops. To achieve this, long-term stafﬁng 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 speciﬁc organizational requirements to produce an implementation design and project plan.

500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 E-Mail: [email protected] hitachi-id.com Date: 2016-01-26 | 2020-07-23 File: /pub/wp/documents/deployment-bp/hipm/hipm-deployment-bp-13.tex