Initial Password Management Discussion

Last modified 03 Jul 2024 15:32 +02:00
feature
This page describes configuration of midPoint feature. Please see the feature page for more details.

There are several problems in the identity management field that are quite difficult to grasp, problems that are counter-intuitive and that do not have any clear and elegant solution. Management of the initial password is one of those problems.

The problem is how to set initial password for a user. This may be the first password that the user gets when she or he is hired. This may be a new password set by the support staff as part of a password reset procedure. What is the real problem here is that the user cannot set the password without help of another person. New employee does not have any access to any information system to set up a password. The situation is quite similar in case that the password is lost. An employee that forgot his Active Directory password is usually completely locked outside. Such an employee cannot access his computer, cannot access self-service portal, cannot access any services - as the Active Directory password is usually the first line of defense to get any kind of service.

Acceptable Solutions

There are several way how to approach this issue. None of them is perfect. And most of them cannot be solved just by using midPoint. There needs to be support in business processes, help of other personnel, special communication channels and so on.

Those solutions are presented here just for inspiration. None of those solutions is a complete process to manage initial password. The specific solution has to be designed with a specific environment in mind. The solution depends on how big is the organization, how the people interact, what are the business processes, how strict the security requirements are and so on. The solution for your organization may be a variation of the solutions listed below or may be a completely different solution. This is one of the parts where IDM deployments significantly vary. One size does not fit all.

Most of those solutions have a common denominator. Those solutions are trying to guide the user to get to midPoint password management user interface and have the password set or changed there. This is usually the only way how to make sure that the password is distributed to all the target systems and that the password is properly managed.

Unified authentication

Having said all of the above, there is in fact one quite simple and elegant solution. But the drawback is that is not always feasible. In fact, only a very homogeneous or very simple deployments can use this approach. The idea is very simple: do not manage password in midPoint. Make all your applications authenticate to a unified authentication service. This unified authentication server is usually a centralized directory server (LDAP server, Active Directory) or a single sign-on (SSO) system.

In this case the password is managed entirely inside the authentication system. Therefore native password reset capabilities of the authentication system can be used. And even midPoint can help a bit. MidPoint can be used to set initial random password and deliver it in text (SMS) message, deliver it in mail to user’s manager and so on. MidPoint can be used as a unified interface for call center staff. As an additional measure midPoint can set "force change" flag in the authentication system to force password change on next login. But midPoint does not need to know the new password, it is up to the authentication system to force password change.

This is a very simple solution. But it assumes unified authentication. And that is quite a rare sight. Therefore applicability of this solution is quite limited in practice.

Out-of-band authentication by call center

Many organization have one service that is always available: call center. Therefore call center can be used to set and reset passwords. The big problem here is, obviously, authentication. How does call center authenticate the user? They cannot change password of any user. But, there may be a feasible way to authenticate user over telephone. The authentication may be weak, but a combination of several weak factors may provide a feasible solution - especially in low-risk environments. For example the call center may check that call is coming from a telephone number that the user has registered in his profile. The call center may ask for employee number (if that is not a public information). There may be security questions and so on. Maybe even an authentication by using security token (e.g. TOTP).

Even a combination of several weak factors may be good enough to request password reset - especially if random password is generated and delivered to a user using a trusted channel (see below). In that case attack on weak authentication may cause denial of service. But it may be unlikely to cause any serious breach. And even the effect of denial of service are usually limited to just a handful of users.

Trusted channel

There may be a trusted channel that can be used to deliver a new password to a user. This is often text message (SMS) - especially in cases that the employees are issued with a company phone devices. Such trusted channel may be an obvious choice to deliver an initial password. And in fact, initial password may be deliver to a user as part of a usual new employee enrollment process - the same process where the employee gets the badge. User’s manager may also act as such an trusted channel, especially if the new password is just a randomly-generated temporary password. Therefore such password may be sent to user’s manager as a form of password delivery.

Cooperative password reset

There are disadvantages to both methods specified above. There may be weaknesses, such as an attacker gaining access to user’s mobile device. There may be possible man-in-the-middle attacks, e.g. user’s manager may abuse user’s password. There may also be practical issues, such as manager not being available to distribute the password to the user and so on.

But there is one interesting option that we like to call cooperative password reset procedure. The procedure goes roughly like this:

  1. Alice has forgotten the password. She ask her colleague Bob to request password reset for her.

  2. Bob works with Alice for quite a long time. She knows her. So obviously, Bob is quite confident that it is in fact Alice who asks for password reset.

  3. Bob navigates to midPoint self-service interface and selects cooperative credential reset. He asks password reset for Alice.

  4. MidPoint can check whether there is sufficiently close relation between Alice and Bob in the organizational structure. And therefore whether it is likely that Bob really knows Alice.

  5. MidPoint generates new random password for Alice.

  6. MidPoint has several options to deliver the password to Alice:

    1. Password can be displayed to Bob and Alice can read it from Bob’s screen. Not very secure, but fact and practical.

    2. Password can be delivered in text message (SMS) to Alice’s device. This is more secure than just relying on the text message, as Alice is unlikely to request such password reset from Bob if she is not in a control of her mobile device.

    3. Password can be divided in several parts and distributed to several close colleagues of Alice. In this case Carol and Dave. Carol and Dave both know Alice personally, so they can reveal the password parts to Alice. And they are unlikely to reveal these parts to anyone else. In addition to this, neither Carol nor Dave can abuse Alice’s password directly as each of them knows only a part of the password.

  7. Alice logs in with new password.

  8. Alice may be forced or motivated to change the password as soon as possible (see below).

Currently, midPoint implements only some part of this process. However, the design and the basic building stones are already in place (see Password Reset Configuration for details). All that is needed to complete the functionality is motivation from midPoint subscribers.

Forcing password change

Most methods for initial password management involve a second person that comes into possession of the password: call center agent, user’s manager or colleague. This opens a vulnerability and it may be used for an attack. Therefore it is usually desirable to control the risk by limiting lifetime of such password. In plain words: it may be acceptable that someone else knows user’s password as long as the password is quickly changed. Ideally password change should be forced on the next login.

However, forcing password change is much harder than it seems. Some bad examples of the procedure are described below. To cut the long story short: midPoint usually cannot force password change just by itself. And it fact it is very unlikely that any IDM system could do that unless it resorts to the methods described below. The reason is that it is not midPoint that the user will log into during his next login. The user will log in to his computer, which meas authentication driven by Active Directory. Or the user will log into a portal or web site, which may use SSO system for authentication. But midPoint is not kept in the loop in this case. MidPoint does not know that the authentication takes place.

All that midPoint can do is to set force password change flag in the authentication system (e.g. force password change in Active Directory). And in fact some midPoint deployments are using this approach. This will efficiently force password change on next login. However, the problem is how to distribute changed password. In vast majority of systems there is no way how to get to the cleartext password - the password is not readable and in almost all the cases the password is hashed. On the other hand, vast majority of system require cleartext password to set a new password. These may be purely technical obstacles, but there may also be a good reason for this (e.g. password policies cannot be evaluated when working with hashed password value).

Therefore forcing password change usually works only in two cases:

  1. There is unified authentication system and midPoint does not need to distribute passwords at all.

  2. The authentication system can notify midPoint about password changes.

Both cases are quite rare. Therefore it may be more practical to avoid forcing password changes after login. Alternative approach may be to limit the lifetime of a new password to several days. And maybe bombard the user with mail and text messages until the password is changed.

Bad Solutions

There are also solutions that are feasible, but they are not recommended due to they severe drawbacks.

Active Directory password synchronization

Users in homogeneous Windows environments are often used to change their password directly by using Windows password change tools. However, such password change is handled by Active Directory domain using proprietary Active Directory mechanisms. Simple speaking, there is no good way how to get a cleartext version of the password. However, there are several bad way:

  • Replacing windows GINA with a custom code that delivers the password to IDM system. This is very unstable and risky approach. See below.

  • Using password policy checking plug-ins: putting custom code into password policy validation process on domain controllers. The code pretends to check password policy, but instead it delivers the password to IDM system for distribution. This is not entirely explored method, but it is also risky as it involves custom code on Active Directory domain controllers.

  • Using various password synchronization tools and interfaces: as far as we know there is no general purpose password synchronization mechanism for Windows or Active Directory. There are (or were) various tools for password synchronization to UNIX systems and so on. However, it is not clear whether such tools can be (ab)used for general-purpose password synchronization, what are the licensing and support implications and so on.

Generally speaking, it looks like all password synchronization methods for Active Directory involve either custom code or obscure components. We consider custom code in security processes of Windows clients or servers not to be a good idea. The interfaces and limitations imposed by the Active Directory and Windows systems are not entirely clear as those systems are not sufficiently open. Therefore it is not easy to asses the effect of such components from an engineering perspective. It is also not clear whether such components will not void the warranties and/or support contract. Therefore we generally do not recommend this approach and this approach is not supported by Evolveum.

However, even though we do not recommend this solution, the solution may still be acceptable for some deployments. In such case there are two components that may be interesting:

  • midpoint-password-agent-ad in Evolveum github repository: Active Directory agent that can send password updates to midPoint. This is a community contribution from 2014. It is an unmaintaned and unsupported code. There are reports that this code no longer works.

  • midPointADPasswordAgent in Identicum github repository: This is prototype of usage of Active Directory password filter to capture password changes. This is not maintained or supported by Evolveum. However, some support may be available from the author (Identicum) or the community.

Instead of using Active Directory password synchronization we propose a change in business processes. Users should be lead to change their password by using midPoint user interface rather than relying on native Windows password management tools. This approach has several advantages:

  • Password can be synchronized to all the systems from one place.

  • Organization-wide password policies may be checked. E.g. midPoint can make sure that password for administrator persona is not the same as the password for ordinary employee persona.

  • Password change is properly audited in organization-wide audit logs.

Replacing Windows GINA

There are several methods that rely on replacement of Windows graphical identification and authentication component also known as GINA. GINA is a library (DLL) that controls user authentication (login) dialog in Windows-based systems. It may be very attractive approach to replace GINA with a custom code - and this approach was indeed used in the past, for example to enable multi-factor authentication in windows. This approach may even seem attractive now, e.g. to place a password reset link on the Windows login screen. However, we strongly discourage this approach as replacing GINA seems to have severe negative impact:

  • GINA is crucial part of Windows security and authentication process. Any issues with the custom code may stop authentication completely (serious denial of service), may open impersonation vulnerability, or it may have a broad range of other dangerous effects.

  • GINA is a dynamic library that is part of operating system distribution. Being part of operating system, GINA can be updated by the usual Windows update procedure. Therefore, any customization suddenly disappear without any warning.

  • GINA compatibility is questionable. It is questionable which Windows version will be supported and whether the custom code can run on any future versions of Windows.

  • Replacing or modifying GINA is very likely to void any warranties, support contracts, and it is likely to compromise any security guarantees.

Therefore, once again we strongly discourage this approach - whether it is used with midPoint or any other IDM system.

Unfortunately, it seems there is currently no practical solution for this issue. In case that there is any detail that we might have missed please contact us. We will gladly consider any practical solution for those use cases.

Putting It All Together

The password reset procedure in fact boils down to several steps. The practical solution is usually composed of those steps:

  1. How does user request password reset? Is it call to call center? Can a colleague or a manager request password reset?

  2. How is the request authenticated? Are there security questions? Additional authentication factor?

  3. How is new password created? Does the user enter a new password? Is a random password generated?

  4. How is the password delivered? Does call center agent read the password to a user? Is the password sent in test message (SMS) or mail message?

  5. What are other effects? Is the user forced to change the password on next login? How exactly is the changed password distributed? Is password lifetime shortened?

Currentl,y there are just few hardcoded password reset procedures, e.g. self-service password reset based on security questions. Generic password reset mechanisms are only partially implemented. However, the design and the basic building stones are already in place. See Password Reset Configuration page for details. All that is needed to complete the functionality is motivation from midPoint subscribers.

Was this page helpful?
YES NO
Thanks for your feedback