Picking your Deployment Architecture

In the previous post I talked about Smart Card Support in Red Hat Enterprise Linux. In this article I will drill down into how to select the right deployment architecture depending on your constraints, requirements and availability of the smart card related functionality in different versions of Red Hat Enterprise Linux.

To select the right architecture for a deployment where users would authenticate using smart cards when logging into Linux systems you need to answer a couple of questions.

The main one is “where are my users” and thus “where my users authenticated”? Are your users going to be in Active Directory, in IdM or they are in some other solution? If they are somewhere else other than in AD or IdM the situation might require a deeper dive so please reach out to your technical account manager or sales representative. If you want to keep users in Active Directory and have AD as an authoritative source for the account information and authentication you can do it in two ways. The preferred way is to deploy IdM to manage your Linux environment and establish trust with AD. However this will work only with clients that run version 7.3 and later since they have SSSD capable of working with Active Directory and understand smart card authentication. For older i.e. 6.x clients in this case you might have to use pam_pkcs11 and manage mapping files.

The alternative, if for some valid reason you really can’t use trusts which are highly recommended, would be to deploy IdM and sync accounts from AD. In this case clients 6.8+ and 7.2+ can work against IdM and you will be synchronizing user accounts from Active Directory to IdM. This integration is less preferable since synchronization approach is much less robust than a trust approach and in this case AD becomes a source of accounts but real authentication happens against IdM so if you need authentication auditing you need to do it against IdM.

You can also deploy IdM without ongoing synchronization with AD and manage accounts for your Linux environment purely in IdM. This will work with 6.8+ and 7.2+ clients. And with 7.4 clients you will be able to get Kerberos tickets as a part of smart card authentication allowing Kerberos based SSO between servers and services.

A couple other questions need to be answered.

    • Can I avoid using IdM? Yes you can connect SSSD directly to AD and use smart card authentication since 7.3. With older clients you will have to do mapping via files as described above.
    • How can I handle a small set of Windows servers I have in those scenarios?
      • If you have Active Directory and your users are in Active directory you can connect your Windows systems to Active Directory.
      • If your users are in IdM and there is no AD in the picture there are some ways to configure Windows systems to work with IdM accounts. However this functionality is limited and not supported out of box. To see what can be done on this front contact your TAM or sales representative. In future it will be possible to have IdM be the authoritative source for users and expose those user to Windows systems. That would require a feature that is being worked on in IdM’s upstream project – FreeIPA. It is called a Global Catalog. With Global Catalog users managed by IdM can be exposed to a trusted AD domain and then Windows systems can be connected to such domain. If you are interested in testing such functionality please reach out to FreeIPA team using community mailing lists or by opening a case with Red Hat support.

Scenario 1:

So let us take a case when users will be in IdM, certificates are issued by an external CA and it is either a green field deployment or you can upgrade your clients to 7.4. Here is what it will entail:

  1. Install the latest IdM version (7.4 at the moment the article was written)
  2. Create or load users into IdM
  3. Map certificates to user entries in IdM
  4. Install your clients using 7.4 and ipa-client-install script
  5. Prepare for smart card authentication on clients and server
  6. Test your smart card authentication on those clients
    1. Console login
    2. SSH (locally)
    3. SSH (remotely)

Scenario 2:

If the environment has a mixture of clients with different versions before 7.4:

  1. Install the latest IdM version (7.4 at the moment the article was written)
  2. Create or load users into IdM
  3. Update clients to be at least 6.8 or 7.2
  4. Install your clients on client systems using ipa-client-install script
  5. Prepare for smart card authentication on clients
  6. Publish certificates into user entries
    1. Extract from the card
    2. Publish into IdM
  7. Test your smart card authentication on those clients

Scenario 3:

If you want to leverage trust then the sequence will be the following:

  1. Install the latest IdM version (7.4 at the moment the article was written)
  2. Establish trust with AD
  3. Update clients to be at least 7.3
  4. Install your clients on client systems using ipa-client-install script
  5. Prepare for smart card authentication on clients
  6. Link your AD users with the smart cards
  7. Test your smart card authentication on those clients
    1. Console login
    2. SSH (locally)
    3. SSH (remotely)

As you can see there is unfortunately no support of the trust-based smart card authentication for older 6.x clients. I was asked a question about this the other day at the Defense in Depth conference and gave an answer without checking my notes. The truth is that the smart card authentication with older clients is possible only if you use IdM as a source of your users. Support of the trusts would require back porting of the SSSD to 6.x which will be very hard to do at this stage of Red Hat Enterprise Linux 6 support.

For more information about smart card support in identity management see the following documentation.

For more details about lower level support of the smart cards please see the following knowledge base article.

 

  1. How about the scenario with no IDM and no AD – users are in an existing RHDS instance and an existing Kerberos realm (RHEL7) is present ?

    1. We have not tested this scenario but would be interested to hear your findings.
      Here is what I would suggest to try:
      – Publish certificate into the directory, the default attribute is “userCertificate”.
      – Configure SSSD to do certificate based authentication. You will need to read sssd man pages. In sssd.conf you will enable authentication with certificates and in the sssd-ldap there is a description of other parameters to set like ldap_user_certificate.
      So this will most likely work well with just LDAP lookup since this is the functionality that was there in 7.2 and there is not much difference between RHDS and IdM setup in this case. So effectively the documentation for scenario 2 will apply.
      On top of that you would need to enable PKINIT authentication in SSSD. Part of this will be configuring krb5.conf on the client to do PKINIT operation. I do not see any special configuration parameter that explicitly turns on and off the PKINIT in SSSD. AFAIU SSSD will automatically attempt to acquire a kerberos ticket based on the smart card authentication if Kerberos is already configured.
      I know I am not that specific here because I have not tried this scenario myself.
      So if you are for giving it a try please take a look at man pages I mentioned and reach out to the SSSD community via the sssd-users@lists.fedorahosted.org list.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s