Identity Management and Two-Factor Authentication Using One-Time Passwords

Two-factor authentication, or 2FA, is not something new. It has existed for quite some time and in different forms. What is a ‘factor’? A factor is something you have, something you know, or something you are. For example, if we combine a PIN that you know, with your fingerprint, we get a 2FA based on biometrics. In practice, biometric solutions are not often used because it’s not especially difficult to steal someone’s fingerprint (…and it is quite hard to revoke or replace your finger). The more practical approach to two-factor authentication is to combine something you know, a PIN or password, with something you have.

Something you have often comes in form of a device. It can be a device that you already have, for example a phone or tablet, or a device that is given to you, for example a smart card or a token. The device-based 2FA comes in two main flavors, namely: certificate based or one-time-password (OTP) based. The certificate based authentication leverages a smart card as a device. A smart card is effectively a password protected memory card with a secret (or secrets) stored on the it. You insert the card into a card reader and use your PIN to unlock the card. The PIN is used to decrypt the card’s contents – allowing client side software (on the computer) to interact with the secret (or secrets) via a specific API.

An alternative to the smart card approach is OTP. This is a random password that is valid for a short period of time (usually 30 or 60 seconds). If you use a hardware token, a special device dedicated to generating the passwords (codes), the device will have a display that would show you a code. It is usually a numeric code of 6 or 8 digits (though different other devices exist). If you prefer to use an existing device (e.g. a phone) you can put an application on it that will generate a one time code for you to use for authentication. Such an application is called a “software token”. There are multiple vendors that build software token applications for mobile devices. The most well known one is Google Authenticator (GA). GA was built using open source and open source authentication standards – making it highly inter-operable and attractive to use. Unfortunately, Google made a decision to close source for Google Authenticator. Red Hat, being an open source company, decided to sponsor an alternative compatible open source implementation called FreeOTP. You can find this app in Apple App Store (here)  and in Google Play (here). What’s nice about FreeOTP being open source is that you have a direct contact to people behind the project. If you see an issue or a problem you can not only write a review but you can go one step further and interact with developers via a project list and provide feedback as well as propose improvements.

The passwords (codes) that are generated by these tokens are random. But to be able to authenticate – the server should be able to generate the same code and be able to match it. To be able to do so the server, and the token, need to share the following factors:

  • they need to support the same algorithm (i.e. the logic of how to generate the codes)
  • they need to share the secret that is used as a seed for the random number generation algorithm
  • they need to share some other factor that changes all the time… such a factor is usually either UTC time or a count of number of times the token has ever displayed a code

The tokens that use time are, unsurprisingly, called time-based tokens and the tokens that use count are called event-based tokens (because they display a code only when requested).

During the authentication the user combines their PIN (or password) with the code on the token and send it to the server. The server, knowing the PIN, seed, and time (or count) can generate the code it expects and will attempt to match this expected value to the data as entered by the user. As we don’t live in a perfect world… there are times where the count or time gets out of sync. To compensate for such ‘drift’ the server generates more then one code. The number of codes it tries is usually configurable. This is called a token window. The bigger the window – the more codes the server will generate and try. This reduces the security of the solution so defining a wide window is generally a bad security practice. Sometimes the token gets out of sync so much that no codes match. In this case the user needs to re-synchronize the token by providing first the PIN and a code and then another code generated by his or her token. The server, in this case, determines the drift, records it, and factors it in next time the token is used.

An important step in preparing a 2FA solution is the provisioning of the tokens to users. During provisioning, the token seed on both sides is ensured to be the same. Software tokens are provisioned by generating a random code and passing it to the device the token will reside on. The hardware tokens are usually arrive pre-seeded so the seeds come in a data file and need to be loaded into the server. Some hardware tokens can be connected to the server and exchanged with server to establish a shared secret seed.

Identity Management and OTP

Starting with Red Hat Enterprise Linux 7.1 the Identity Management server is capable of performing two-factor authentication. This is the first commercially available domain controller that implements integration of 2FA with Kerberos. What does this mean? Previously, any integration between two-factor authentication and a domain controller required two steps: first, a user authenticated using his or her 2FA and then the user supplied password was used to authenticate and get a Kerberos ticket so that the user could take advantage of SSO between different services in a domain. The weak point of this solution is that there is always a single factor used to get a Kerberos ticket. IdM eliminates this problem by integrating 2FA into its Kerberos and LDAP services. Users can authenticate with two factors and get a Kerberos ticket as a result of such authentication in one step. The same authentication policies apply whether a user authenticates using Kerberos or LDAP.

In fact, IdM implements two variants of 2FA. The first variant leverages both hardware and software tokens managed within the IdM server. A user in IdM, by default, can authenticate using a single factor – their password. Administrators can enable a subset of users for OTP authentication. This means that a user in addition to his or her password would need to enter a token code from a token. Until there are no tokens assigned to the user the user will continue authenticating with their password, but once the user enrolls a hardware token or provisions a software token he or she would be required to provide both a password and a code as displayed on the token. Provisioning of a software token is initiated by a user via a self-service page. There is no limit on how many tokens can be added to the user but users must have at least one token until an administrator flips the switch and disables the OTP authentication requirement for this user. Such an approach allows a simple and smooth transition from a single factor authentication environment to 2FA without any extra overhead for users. In many cases administrators elect to setup self-service portals to allow a simple way to deploy software tokens to mobile devices. The user clicks a button and a QR code with token information is generated and displayed on their screen. This QR code can be scanned by the FreeOTP or GA application on their mobile device. Once scanned, the token will appear on your device. It is not recommended to try to use the same token from different devices as the QR code will not be displayed again. It is easy to delete the token and deploy it again or to add another token for another device.

Rounding out this exploration of 2FA – it is expected that IdM will be deployed in the environments where a 2FA is already provided by other vendors. In this case IdM can take advantage of the existing 2FA solution. All 2FA servers provide a capability to authenticate using the RADIUS protocol. IdM administrators can configure IdM as a client to one or more RADIUS servers. An authentication policy for a user can be set to use a specific RADIUS server. Once the policy is set to use RADIUS for a user, IdM would ignore user passwords or tokens and proxy user credentials to a particular RADIUS server. Once it gets the response from the RADIUS server, if authentication was successful, it will reply to its client with a Kerberos ticket. Otherwise it will deny user access. This proxy approach allows a simple and gradual migration from the 3rd party solution to an IdM based solution. Such migration might be considered because of IdM’s unique Kerberos integration capability and the cost of the solution. 3Rd party solutions are traditionally quite expensive. In case of Red Hat, FreeOTP is a free application and IdM is available free of charge as a part of your Red Hat Enterprise Linux subscription.

Cheers if you’ve read all the way to here – today’s post was a long one.  That said, if there’s something additional you’d like to learn about 2FA, IdM, one-time passwords, or anything else that was covered in this post – as always, don’t hesitate to reach out.

  1. Hi Dmitri,

    Do you know if there is a way to have different authentication methods for different hosts with IDM? I would like to have some hosts use two factor authentication and others use single password.

    I have found how to change the authentication methods for each user but have not found how to do it based on host. Any help would be appreciated.


    1. For now you can configure SSSD with LDAP for password only cases and SSSD with Kerberos for 2FA. See documentation about the different of 1FA vs 2FA via LDAP vs. Kerberos.
      This is not best separation but it is what we have right now. We are looking at addressing this feature gap in the future releases.


  2. Hi Dmitri,

    Sorry to keep bothering you. When using a radius server, is it possible to have the primary password authenticated through IDM and the secondary processed by the radius server?

    As an example, if a users password is ‘password’ and their auto generated passcode is 123456, is it possible to have IDM authenticate ‘password’ and the radius server authenticate 123456?

    We are attempting to setup IDM and want to use two factor authentication with a Duo radius server.


    1. Hello,

      There are huge challenges with this approach in general. If the password and code concatenated on the client side into a single string there is no general algorithm to split them back on the server side. This is a general problem regardless of the protocol or server implementation. The client needs to be smart and prompt separately but send both portions together in one requests but as two separate strings. I do not think it is possible with any client software except SSSD in RHEL 7.2. It is always a single prompt for user to provide a single string.
      But I am not sure why would you want to do it this way. You need to take a deeper look ad DUO and how it works. Based on a very quick scan it seems that making IdM as back end to DUO in the same way as with AD might be the option to explore.


  3. I need to integrate IPA 7.2 server with Radius 2FA using Vasco hardware token. Please share the document or a link to do the same.

      1. Hi Dmitri,

        The link you provided is redirecting me on “Enabling Custom Home Directories ” link. Please share the correct link.

      2. It seems that there is some kind of bug in a documentation site. If you click the link it would open documentation in the wrong place but if you then go to the address line and hit enter again it will find the right anchor on the page. Anyway the section you need is 2.3.5.


  4. Hello,
    it’s possible to activate 2FA when the user is not on trusted network. Having only the use the single password on friends networks and use 2FA on networks with lower confidence.


    1. Hello,

      It is somewhat possible but probably not exactly the way you would want it to be possible. We are looking to correct this limitation soon.
      Right now when you configure different methods at the same time for the same account i.e. single factor and two factor you get different behaviour over Kerberos and LDAP protocols. Kerberos will require 2FA in this case while LDAP would allow just password so you can configure trusted networks to use LDAP and untrusted use Kerberos. Getting back to the point at the beginning you would probably prefer the reverse i.e. to allow SSO with Kerberos on the trusted network using single factor and require 2FA on untrusted network probably without SSO using LDAP. This is not possible yet.

      See for more details.


    1. The solution allows you to proxy authentication via RADIUS to RSA Authentication Manager.
      So yes it supports it. User enters RSA PIN+token code, it does to IdM server, IdM server talks RADIUS to RSA, RSA authenticates and replies, user is issued a Kerberos ticket.
      Please check documentation for more details about capabilities and limitations of this solution.

    2. As Dmitri states, the IDM solution allows RADIUS authentication which will help a lot if you have unsupported second-factor needs or if you already have a two-factor solution in place. One thing to be aware of if implementing IDM with RADIUS, it will only work on RHEL 7.* clients and newer (as far as we have experienced) due to missing sssd functionality. One way around this issue is to install pam_radius to go directly to your RADIUS server during authentication ( Note that this method will not be supported by Red Hat. Kerberos tickets will not be issued on clients that authenticate using pam_radius but so far it is the best approach I have found around this issue.

  5. Dear Dmitri,

    I agree with the poster who said that IdM has matured nicely. I am amazed at what RH has accomplished in just few years. I would not be surprised if RHEL IdM would become wildly popular. Especially since the old sssd and AD interoperability in 5 and 6 (no realmd) are going away over time.

    I will probably design our IDM overhaul to use IdM for our RHEL servers with a trust to an AD domain for Windows servers. With AD containing nothing except service and machine accounts. But I do not see any easy way for SSO across the servers when using 2FA, especially the enhanced 7.2 flavor. Our admin stations would be Windows on a third domain that is separate from production.

    Do you have any plans to work with third party Kerberos client/identity managers (e.g. Network Identity Manager) to get such improved 2FA/SSO support for Windows?

    1. We have different plans to address the use case when admin is a Windows user and has his password in AD but needs to have a 2FA authentication against a Linux box connecting from a Windows machine. This is in fact an important use case that we are tracking. In the next upstream release, that hopefully will land in RHEL 7.3, we are laying down the foundation for this capability to happen in the follow up release. So far we have some ideas how to solve the problem without pushing all Kerberos vendors to adopt something new.

    1. Is there a specific information you are looking for?
      Please see a later article about RHEL 7.3 features. It consists of two parts.
      In 7.3 you now can centrally enforce which systems and service require 2FA.

      1. Hi!

        Which 2FA open source providers would you recommend me to check out? We would love to see a RH solution in this regard so we wouldn’t have to go look anywhere else, with the risk of that project being discontinued, etc.


      2. For software tokens on the phone iOS/Android we recommend FreeOTP which is free and supported by Red Hat. For hardware tokens we recommend Yubikeys or any other vendor that supports TOTP and HOTP tokens.


  6. Curious – is there now a solution to applying 2FA requirements for users coming from an Active Directory Trusted domain?

    We are open to either using some kind of OTP solution or using existing smartcards that are used to authenticate against windows device.

    1. In general it is a more complex problem than seems on a surface. But let us start with your specific workflow. If you can describe the setup and the user actions we would be able to assess what is possible and what not.
      For example:
      – I have a user in AD
      – User has a smart card
      – User logs into his Windows system with smart card
      – User wants to access a Linux box via SSH
      – I plan to use (or not use) IdM to manage such Linux systems
      – I want to enforce 2FA into such box

      Something along these lines.

      1. Hi Dmitri,

        You pretty much nailed it on the first try, but to re-iterate:

        – I have a user in AD
        – User has a smart card
        – User logs in to his windows system with smart card
        – User wants to access a Linux box via SSH
        – I use IdM to manage these Linux Systems via Active Directory Cross Forest Trust implementation
        – I want to enforce (some form of) 2FA into said Linux boxes
        – The chosen 2FA solution does not necessarily have to be the same smartcards as the ones they use for Windows.

        Thank you!

      2. OK, does the user also have an option to authenticate with password? If not and he has to always use his SC to log to Windows you sort of have the solution right away. When user authenticates into Windows box he is 2FA authenticated and gets a Kerberos TGT. If he can get Kerberos TGT only using smart card then any SSO based on Kerberos automatically 2FA enforced. So if you say that you Linux system can be accessed only with GSSAPI authentication you force all users to authenticate first and if they do not have passwords enabled SC would be the only option.
        But it is a bit more complex than that. You most likely would have to open a fall back door for cases when the user is not in AD. For example it is some special system account that needs to use password auth. There is always some outlier like that. Also practice shows that some users have access to passwords and can use both.
        In this case I would try a more complex approach. I am not sure it will work since I have not tried it.
        – On the target Linux machine machine configure SSH authentication to use SSH keys.
        – On the Windows machine you would need to have a client that supports smart card authentication like putty-cac or similar.
        – Effectively implement scenario 3 from here:
        – You would need to allow PAM authentication for the accounts that do not have smart cards but I would recommend not storing them in IdM and not being able to have Kerberos authentication for them. Make them local for example.
        – To prevent users from logging with password if they know it I suggest that you require any kerberos ticket for user logging into the system to have a special authentication indicator. In can be a random string. This will prevent any user who authentucted with Kerberos via SSSD in PAM stack to access the system because there will be no indicator in the ticket.
        So in this case:
        – Kerberos login via SSH -> PAM-> SSSD will be prohibited
        – Login will be allowed only with SSH keys that are based on Smart cards
        – Special accounts will be handled like local accounts, they will be done via PAM but not via Kerberos authentication against AD/IdM so Kerberos authentication indicator enforcement would not apply to them.

        I hope I gives you enough ideas to experiment. Please let me know how it goes.


      3. Another option might be to sync users into IdM, do not give them passwords but associate the smart cards they already have in AD to them. This way you have duplicate account for AD user in IdM but without password. There is a way to create authentication indicators to force pkinit authentication for IdM users. It is a bit incomplete but I was assured that it is possible to enforce. AFAIU as of 7.4 and upcoming 7.5 it would have to be done via CLI as UI might not have some smarts. This part is vague so opening a support case to figure that part is probably the best approach. This way you can force users to use PKINIT i.e. smart card auth into your Linux boxes.
        Also you might want to explore a jump host approach. In this case you would only allow your users logins on that jump host. You can control it with HBAC. This is another way to separate system accounts that need back doors and user authentication.
        Hope this helps.


      4. “To prevent users from logging with password if they know it I suggest that you require any kerberos ticket for user logging into the system to have a special authentication indicator. In can be a random string. This will prevent any user who authentucted with Kerberos via SSSD in PAM stack to access the system because there will be no indicator in the ticket.”

        This idea is very enticing and I would love to try it. The documentation on how to do this for MIT/FreeIPA based Kerberos was rather straightforward (, but i seem to be unable to find any documentation on how to accomplish this with Active Directory. It seems based on this documentation that is theoretically possible, but I can’t actually find any documentation on how to configure the the indicator.

        I will update you if I try any of the other solutions or figure this one out.

        Thanks a lot for the help!

  7. Hi – do you have a link and/or procedure for setting up 2FA on RHEL6 with SSSD and Kerberos for local logins?

    Thanks in advance.

    1. Just to be clear:
      – The feature is supported for central accounts only not for the local accounts
      – To be able to do it with Kerberos you need RHEL 7.1 client or later
      – If you want it from a RHEL 6 client you need to configure RHEL 6 client to use LDAP authentication instead of Kerberos. This will loose some SSO capabilities but should allow 2FA using LDAP. This will only work for accounts managed by IdM since for proxied authentication you need Kerberos. Also if you enable 2FA or Password for an account the LDAP client will always choose 2FA.
      Here is a pointer for the LDAP configuration of the older clients: , one of the options for the utility is to configure SSSD with LDAP against compat tree which is used in trust setups. You do not need the compat DN but should use the standard LDAP DN instead. So it will not be a cut and paste config, but rather a sample to take an inspiration from.


  8. Hi,

    Is there a way to integrate keycloak with RSA SecurId instead of FreeOTP. RSA SecurId is the only allowed OTP partner at my org and bringing in FreeOTP is not an option. Is there a way to integrate custom OTP solutions with KeyCloak?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s