Posts Tagged ‘Identity Management’

Using (Free)IPA ID-Views with LDAP for your legacy servers

Friday, April 15th, 2016

Having pain with user authentication on your old legacy Unix servers? Here comes the solution: ID-Views via LDAP.

If you need to preserve UID/GID or other stuff like shell on some legacy servers but want to have the benefits of a centrally managed identity management, then ID-Views is the answer. Since legacy servers usually do not have SSSD on board, such as traditional Unix Systems, you can also use LDAP to authenticate such users.

Use casesBe aware

On the long term you should clean up messy old environments as ID-views adds some complexity to your identity management. As those old kind of servers tend to be replaced with newer Linux distributions, they will die over the next years. At the end, ID-views can greatly help you during a transition period.

Test lab setup

  • Your IPA server is called ipa1.example.com
  • The example client is called ldap-view.example.com
  • The ID-View is called oldstuff
  • Example is named jdoe

What are ID-Views

Basically ID-Views are mappings of user credentials stored in a different LDAP base DN. This is: cn=myview,cn=views,cn=compat,dc=example,dc=com
where myview is replaced by the particular ID-View in this example “oldstuff”.

Underneath there are users and groups, so a complete ID-View DN for users would be cn=users,cn=oldstuff,cn=views,cn=compat,dc=example,dc=com.

Creating an ID-View

Log in to you IPA server and ensure you have a valid Kerberos Ticket for the admin user.

[root@ipa1 ~]# ipa idview-add --desc="Our old Unix Servers" oldstuff
------------------------
Added ID View "oldstuff"
------------------------
  ID View Name: oldstuff
  Description: Our old Unix Servers
[root@ipa1 ~]#

Next lets map a user. Lets assume that user jdoe need to have a login name of joe, a Korn shell, must be in the group with GIG 1002, has the UID of 1001 and has a home directory of /export/home instead of the standard values.

[root@ipa1 ~]# ipa idoverrideuser-add --desc="Overrides for Joe Doe" --shell=/bin/ksh --homedir=/export/home --uid=1001 --gidnumber=1002 oldstuff jdoe
-----------------------------
Added User ID override "jdoe"
-----------------------------
  Anchor to override: jdoe
  Description: Overrides for Joe Doe
  UID: 1001
  GID: 1002
  Home directory: /export/home
  Login shell: /bin/ksh
[root@ipa1 ~]# 

If you want to use this ID-view with SSSD and ipa-client enabled machines, you can assign hosts and host groups to the ID-view. As this article is just taking care of legacy LDAP clients, this is out-of-scope.

Client Configuration

This varies from Linux distribution to another, traditional Unix servers are even more different. If in doubt, please consult your vendors manual.

For some Linux distributions, IPA can give you some hints how to configure your client.

[root@ipa1 ~]# ipa-advise 
----------------------------------------------------------------------
List of available advices
----------------------------------------------------------------------
    config-fedora-authconfig             : Authconfig instructions for
                                           configuring Fedora 18/19 client with
                                           IPA server without use of SSSD.
    config-freebsd-nss-pam-ldapd         : Instructions for configuring a
                                           FreeBSD system with nss-pam-ldapd.
    config-generic-linux-nss-pam-ldapd   : Instructions for configuring a system
                                           with nss-pam-ldapd. This set of
                                           instructions is targeted for linux
                                           systems that do not include the
                                           authconfig utility.

<More output omitted>

Select the systems that match best for your system to configure. In my example I’ll use config-redhat-nss-pam-ldapd

[root@ipa1 ~]# ipa-advise config-redhat-nss-pam-ldapd
#!/bin/sh
# ----------------------------------------------------------------------
# Instructions for configuring a system with nss-pam-ldapd as a IPA
# client. This set of instructions is targeted for platforms that
# include the authconfig utility, which are all Red Hat based platforms.
# ----------------------------------------------------------------------
# Schema Compatibility plugin has not been configured on this server. To
# configure it, run "ipa-adtrust-install --enable-compat"
# Install required packages via yum
yum install -y wget openssl nss-pam-ldapd pam_ldap authconfig

# NOTE: IPA certificate uses the SHA-256 hash function. SHA-256 was
# introduced in RHEL5.2. Therefore, clients older than RHEL5.2 will not
# be able to interoperate with IPA server 3.x.
# Please note that this script assumes /etc/openldap/cacerts as the
# default CA certificate location. If this value is different on your
# system the script needs to be modified accordingly.
# Download the CA certificate of the IPA server
mkdir -p -m 755 /etc/openldap/cacerts
wget http://ipa1.example.com/ipa/config/ca.crt -O /etc/openldap/cacerts/ipa.crt

# Generate hashes for the openldap library
command -v cacertdir_rehash
if [ $? -ne 0 ] ; then
 wget "https://fedorahosted.org/authconfig/browser/cacertdir_rehash?format=txt" -O cacertdir_rehash ;
 chmod 755 ./cacertdir_rehash ;
 ./cacertdir_rehash /etc/openldap/cacerts/ ;
else
 cacertdir_rehash /etc/openldap/cacerts/ ;
fi

# Use the authconfig to configure nsswitch.conf and the PAM stack
authconfig --updateall --enableldap --enableldapauth --ldapserver=ldap://ipa1.example.com --ldapbasedn=cn=compat,dc=example,dc=com

Since this ipa-advice command is normally used for “standard” LDAP authentication, not for ID-Views. So we need to adjust the base DN to match the DN for the ID-View in question. The correct base DN for the example created above is cn=oldstuff,cn=views,cn=compat,dc=example,dc=com.

[root@ldap-view ~]# authconfig --updateall --enableldap --enableldapauth --ldapserver=ldap://ipa1.example.com --ldapbasedn=cn=oldstuff,cn=views,cn=compat,dc=example,dc=com -disablesssd --disablesssdauth
[root@ldap-view ~]# 

Optionally, you can also enable Kerberos:

[root@ldap-view ~]# authconfig --updateall --enableldap --enableldapauth --ldapserver=ldap://ipa1.example.com --ldapbasedn=cn=oldstuff,cn=views,cn=compat,dc=example,dc=com --disablesssd --disablesssdauth --enablekrb5 --enablekrb5kdcdns --enablekrb5realmdns
[root@ldap-view ~]# 

The script configures /etc/openldap/ldap.conf and /etc/nslcd.conf (and optionally /etc/krb5.conf) with the correct LDAP URI and base DN. On other systems, please consult your vendors manual on how to set those parameters.

Check the result

There are basically two methods to look up the user credentials: id and getent.

[root@ldap-view ~]# getent passwd jdoe
jdoe:*:1001:1002:John Doe:/export/home:/bin/ksh
[root@ldap-view ~]# 

Lets switch to that user

[root@ldap-view ~]# su - jdoe
Last login: Mon Nov 16 19:47:04 CET 2015 on pts/0
-ksh-4.2$ id
uid=1001(jdoe) gid=1002 groups=1002 context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
-ksh-4.2$

Pitfalls

UID and GID Ranges

A decade ago it was the fashion that numeric UIDs begin with 500. Modern Linux systems start at 1000 and this is also a restriction in PAM. Check every file in /etc/pam.d/ for uid >= 1000 and uid < 1000. Change them to the value you need for your legacy system.

HBAC (Host Based Access Control)

There is one problematic issue with Non-SSSD authentication: There is no centrally managed HBAC possible. You can achieve this in two ways: LDAP filtering and sshd configuration.

If you are using PAM only fro ssh access, then configuring sshd is less complex. Just add AllowGroups oldstuff
to /etc/ssh/sshd_config and restart the daemon.

However, there is pam_hbac which is currently being developed. PLease have a look at https://github.com/jhrozek/pam_hbac for more information.

Have fun? No, definitively not with old stuff dinosaur style computing. But at least its less painful 😉

Integrate IPA in your Web application i.e. WordPress

Tuesday, April 12th, 2016

Tired of log in to your favorite Web application? Integrate it with IPA, kerberize it! This blog post will guide you trough the kerberization of WordPress running on RHEL7 or Fedora. The magic is done by mod_intercept_form_submit and mod_auth_gssapi

Assumptions

  • You have a running IPA or FreeIPA infrastructure
  • Your Kerberos REALM is EXAMPLE.COM
  • The hostname where your WordPress instance is running is wptest.example.com
  • WordPress is installed in /var/www/html and ready to run
  • You are using a Linux Workstation with Kerberos, other client OS may or may not work
    • Result


      You can log in to your WordPress instance with a Kerberos enabled Web Browser and username/password with Browser not enabled. The access is restricted by HBAC (Host Base Access Control)

      Install the required software

      root@wptest ~]# yum -y install ipa-client mod_intercept_form_submit mod_auth_gssapi
      root@wptest ~]# setsebool -P allow_httpd_mod_auth_pam 1
      root@wptest ~]# wget https://downloads.wordpress.org/plugin/http-authentication.4.5.zip
      

      Ensure the modules are loaded by Apache, please check the files in /etc/httpd/conf.modules.d/. The WordPress plugin is needed to enable WordPress to make use of the REMOTE_USER server environment. Unzip and place it in /var/www/html/wp-content/plugins/ and run restorecon to relabel the content to be able to use SELinux in enforcing mode.

      root@wptest ~]# unzip http-authentication.4.5.zip
      root@wptest ~]# mv http-authentication /var/www/html/wp-content/plugins/
      root@wptest ~]# restorecon -v -R /var/www/html/
      

      Enroll your Linux server

      Of course your server must be enrolled with IPA.

      root@wptest ~]# ipa-client-install
      

      Get your Kerberos Keytab

      First the Kerberos service principal must be created. Go to one of your IPA servers and add the principal.

      root@ipa1 ~]# kinit admin
      root@ipa1 ~]# ipa service-add HTTP/wptest.example.com
      

      Go to the client, fetch the Kerberos Keytab and make it available for Apache

      root@wptest ~]# kinit admin
      root@wptest ~]# ipa-getkeytab -s ipa1.example.com -p HTTP/wptest.example.com -k /etc/httpd/conf/http.keytab
      root@wptest ~]# chown apache /etc/httpd/conf/http.keytab
      root@wptest ~]# chmod 600 /etc/httpd/conf/http.keytab
      

      Configure PAM

      We are going to create a PAM config file called “wordpress” as a requirement for the authentication method used. Remember, you need to use SSSD because want to make use of HBAC.

      cat << EOF >> /etc/pam.d/wordpress
      auth    required   pam_sss.so
      account required   pam_sss.so
      EOF
      

      Hacking WordPress

      After the configuration of Apache, non-kerberized logins would not work anymore. This is probably not a scenario you want. You will still be able to log in with your IPA credentials, HBAC still works.

      The trick is that if Kerberos authentication fails, you will be redirected to a non-kerberized login page.

      [root@wptest ~]# cp /var/www/html/wp-login.php /var/www/html/wp-login2.php
      [root@wptest ~]# sed -i s/wp-login.php/wp-login.php /var/www/html/wp-login2.php
      [root@wptest ~]# restorecon -v /var/www/html/wp-login2.php
      

      Configure Apache

      The two different modules must be configured to get ready to use.

      Important to know: the parameters InterceptFormLogin and InterceptFormPassword are containing the name of the user and password input field name of the form, as defined in the HTML code. I.e. <input type=”text” name=”log” id=”user_login” …

      cat << EOF >> /etc/httpd/conf.d/intercept_form_submit.conf
      <LocationMatch ^/wp-login.php>
        InterceptFormPAMService wordpress
        InterceptFormLogin log
        InterceptFormPassword pwd
      </LocationMatch>
      
      <LocationMatch ^/wp-login2.php>
        InterceptFormPAMService wordpress
        InterceptFormLogin log
        InterceptFormPassword pwd
      </LocationMatch>
      EOF
      

      The next configuration files is for the mod_auth_gssapi

      The interesting part is the ErrorDocument where you tell the browser to redirect to the previously created wp-login2.php form. Since that form is only protected by mod_intercept_form_submit there will be no Kerbros authentification and prompting the user for the username and password.

      cat << EOF >> /etc/httpd/conf.d/auth_gssapi.conf
      <Location "/wp-login.php">
        AuthType GSSAPI
        AuthName "Kerberos Login"
        GssapiCredStore keytab:/etc/httpd/conf/http.keytab
        GssapiCredStore client_keytab:/etc/httpd/conf/http.keytab
        GssapiDelegCcacheDir /var/run/httpd/clientcaches
        GssapiUseS4U2Proxy on
        Require pam-account wordpress
        ErrorDocument 401 '<html><meta http-equiv="refresh" content="5; URL=/wp-login2.php"><body><h1>Kerberos authentication did not pass</h1><h2>Make sure your browser is configured correctly and you got a Kerberos Ticket.</h2></body></html>'
      </Location>
      EOF
      

      Configure the WordPress plugin

      Point your Browser to https://wptest.example.com/wp-admin/options-general.php?page=http-authentication%2Fhttp-authentication.php and set the following Parameters:

      • Allow WordPress authentication -> Enabled
      • Automatically create accounts -> Enabled
      • Email address domain -> Whatever the users domain is

      Now point your browser to http://wptest.example.com/wp-admin/options-general.php And select the default role of the users being created when logging in the first time.

      Create a HBAC rule

      Usually you want to create a HBAC rule to i.e. allow only certain users or group(s) of users to log in.
      Some time ago I wrote an article on how to do so.

      Restarting Apache

      Now it is time to restart your Apache Server to activate the settings.

      [root@wptest ~]# systemctl restart httpd.service
      

      Configure Firefox

      To be able to use Kerberos with Firefox, you need to set a few options. Please point your browser to one of your IPA repliacas, i.e. http://ipa1.example.com/ipa/config/browserconfig.html”

      Useful Links

      Have fun :-) Feedback welcome..

Setting up IPA with a specific CA cert subject

Sunday, November 29th, 2015

If you are doing experiments with IPA where you install and reinstall IPA servers, you may notice SSL certificate errors when connecting to an IPA server using Firefox. The reason is that always the same Organization and serial is used when the CA cert is created.

Normal users are usually only affected when using the same Realm and DNS subdomain for the test and production environment which is not recommended anyway.

Reproducing the issue
1. Set up IPA with ipa-server-install.
2. Connect to the WebUI using Firefox.
3. Unconfigure IPA with ipa-server-install –uninstall.
4. Configure IPA again with ipa-server-install.
5. Connect to the WebUI using Firefox again and figure out its not working and trows an error message like “An error occurred during a connection to ipa1.example.com. You have received an invalid certificate”.

See also FreeIPA Ticket #2016.

Unfortunately it is not trivial to fix this behavior as different components need to be changed.

Workaround
There is an easy workaround for this issue. Just provide the –subject when configuring IPA.

[root@ipa1 ~]# ipa-server-install --subject="O=EXAMPLE.COM 201511291216" --more-options-as-you-need

The O=EXAMPLE.COM should be replaced with the Realm you plan to set up, the number should be something like <year><month><day><hour><minute>

Unfortunately I dont know if there is an easy way to change already set up servers as the CA cert would need to be recreated.

Identity Management und 2FA mit (Free)IPA @Chemnitzer Linuxtage 2015

Thursday, April 9th, 2015

My first post in German, publishing the Slide Deck (in German) for my presentation about IPA and 2FA held at Chemnitzer Linux days 2015.

Mein erster Post in Deutsch. Hier die Slides von meinem Vortrag an den Chemnitzer Linux Tagen 2015.

Abstract:
IPA ist ein Identity Management System fĂŒr Linux und Unix, das stetig an Bedeutung gewinnt. Mittlerweile ist es des öfteren in Behörden, Banken, Versicherungen, aber auch in KMUs im Einsatz. IPA kann man sich als «Active Directory» fĂŒr Linux vorstellen. IPA verheiratet LDAP und Kerberos zu einem Opensource Produkt das leicht zu installieren und zu unterhalten ist. Mit IPA kann dank Kerberos Single-Sign-On realiert werden (Authentifizierung). RegelsĂ€tze legen fest, welche Benutzer von welchen Benutzergruppen auf welche Services und Hosts zugreifen dĂŒrfen.

Seit einiger Zeit lassen sich mit IPA auch sehr einfach 2FA-Lösungen (Zwei-Faktor-Autentifizierung) realisieren, um die Sicherheit weiter zu erhöhen.

Das Slide Deck gibt es hier:

Slides vom Vortrag

Die Slides habe ich ĂŒbringens bei einem Spontanvortrag bei der Berliner Linux User Group am 2015-04-08 wiederverwendet. Aufgrund des Feedbacks wird in den nĂ€chsten Wochen ein ca. 4h Workshop an einem Samstag organisiert.

Ich hoffe es hat allen anwesenden Spass gemacht und konnte Euch etwas Wissen vermitteln. Feedback zu beiden AnlÀssen willkommen.

2FA with (Free) IPA. The good, the bad and the ugly

Thursday, April 9th, 2015

Two factor authentication (2FA) is more and more emerging which is good to enhance security. Since the release of IPA4 it comes with 2FA included.

Over time I made a lot of experiments and experience I wanted to share with you. Its is easy to set up and maintain as long as you use it only for system authentication. If you are using such things as webmail, it fails. This post shows you the capabilities as they are of today. Almost all bad issues apply not only to Fee(IPA) but 2FA in general.

The good
All your systems are Fedora 21, RHEL 7.1 or Ubuntu 14.02 all is working fine as the included SSSD is new enough to handle 2FA. All kerberized services can be used with 2FA w/o logging in again during the validity of your Kerberos ticket. Very convenient, very secure.

3rd Party applications can use LDAP authentication (Depending on the usecase)

The bad
Systems with older distributions such as RHEL6.6 come with a SSSD version which is to outdated to handle kerberized 2FA at all. This will probably change soon.

Workaround:

  • Use LDAP authentication (See later on)
  • Use a Jump host with a recent Linux distribution

If you are logging in to your workstation with a local user, you can not grab a Kerberos ticket with kinit and use this ticket further on. (i.e for ssh logins on remote server, mail etc.)

Workaround:

  • Switch to a IPA managed user if your workstation is recent enough.
  • Use a Jump host with a recent Linux distribution
  • Wait until krb5-PAKE is in place, software is being developed, see http://k5wiki.kerberos.org/wiki/Projects/Improve_OTP_deployability and https://github.com/npmccallum/krb5-pake
    • The ugly

      Looks like most mobile applications such as the IMAP client in Android do not prompt for the password, they expect it configured. Needless to say that you can not reconfigure the password each time you want to check your emails with your phone.

      Workaround:

      • 3rd party email app? One that prompts for the password if needed
      • Configure IPA to accepts password and 2FA which lets the user choose to either use the password only or 2FA. Needless to say that this makes 2FA less useful as people tend to be lazy
      • Turn off 2FA in IPA and use a Yubikey with a static password (spit password). This is not a real 2FA it is a single password split in two. Password change is a horror.
      • Accessing Webmail clients (I tested roundcube mail) causes headaches as well. They authenticate the users with IMAP and use this credentials to access the mail storage. As the second factor is a one time password (OTP) this will result in failure to retrieve mails after logging in.

        Workaround: Same as for mobile applications. I would appreciate if someone can point me to a webmail software which can handle this.

        Offline usage

        One sentence: Offline usage does not work because it can not work.

        Workaround:

        • Create a local user and use a Yubikey and configure it with a static password (split password). This is not a real 2FA it is a single password split in two. Password change is a horror.
        • Install a IPA server on your Notebook 😉 This will scale up to 18 Notebooks (plus two replicas in the datacenter) but introduce a lot of other problems, so: Not seriously to be considered.

        LDAP Authentication as a Workaround
        Configure PAM/SSSD to use LDAP authentication for your users. IPA comes with a very nice feature called ipa-advise.

        [root@ipa1 ~]# ipa-advise config-redhat-nss-pam-ldapd
        #!/bin/sh
        # ----------------------------------------------------------------------
        # Instructions for configuring a system with nss-pam-ldapd as a IPA
        # client. This set of instructions is targeted for platforms that
        # include the authconfig utility, which are all Red Hat based platforms.
        # ----------------------------------------------------------------------
        # Schema Compatibility plugin has not been configured on this server. To
        # configure it, run "ipa-adtrust-install --enable-compat"
        # Install required packages via yum
        yum install -y wget openssl nss-pam-ldapd pam_ldap authconfig
        
        # NOTE: IPA certificate uses the SHA-256 hash function. SHA-256 was
        # introduced in RHEL5.2. Therefore, clients older than RHEL5.2 will not
        # be able to interoperate with IPA server 3.x.
        # Please note that this script assumes /etc/openldap/cacerts as the
        # default CA certificate location. If this value is different on your
        # system the script needs to be modified accordingly.
        # Download the CA certificate of the IPA server
        mkdir -p -m 755 /etc/openldap/cacerts
        wget http://ipa1.example.com/ipa/config/ca.crt -O /etc/openldap/cacerts/ipa.crt
        
        # Generate hashes for the openldap library
        command -v cacertdir_rehash
        if [ $? -ne 0 ] ; then
         wget "https://fedorahosted.org/authconfig/browser/cacertdir_rehash?format=txt" -O cacertdir_rehash ;
         chmod 755 ./cacertdir_rehash ;
         ./cacertdir_rehash /etc/openldap/cacerts/ ;
        else
         cacertdir_rehash /etc/openldap/cacerts/ ;
        fi
        
        # Use the authconfig to configure nsswitch.conf and the PAM stack
        authconfig --updateall --enableldap --enableldapauth --ldapserver=ldap://ipa1.example.com --ldapbasedn=cn=compat,dc=example,dc=com
        
        [root@ipa1 ~]#
        

        The output actually reflects your environment, example.com will be replaced with your domain, its copy-paste ready. I love this feature :-) For other Linux systems, run ipa-advise without parameters to see which advises are available.

        Conclusion
        2FA works well, convenient and secure in a datacenter and office environment. Notebooks are fine as well as long as there is a network connection available. The mobile world (Smartphones and Tablets) is not yet ready for 2FA. Some issues can be worked around (with some drawbacks) while others render 2FA not usable at all (offline usage).

        Hopefully there will be some smart solutions available for mobile usage soon, as mobile usage causes the most of the security headaches.