Initial Password Management Discussion

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.

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.

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.

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:

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.

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:

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.

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:

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:

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:

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:

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.