Tuesday 31 July 2012

Limiting User Access with LDAP Authentication to Multiple Servers [part 4 of 4]

This technote is the last in a line of notes about using LDAP to provide a shared authentication facility, using the components of an Exalogic.

Introduction

In the earlier posts in the series
  1. Using LDAP for Shared Authentication.
  2. Securing OpenLDAP Communications
  3. Configuring OpenLDAP for High Availability. (Master/Slave or Provider/Consumer configuration)
we considered how to setup a directory server and configure the ZFS Storage Appliance and OEL instances to use this for authentication.  We then took the next step to secure the communications by encryption and finally changed the LDAP setup so that we can have multiple copies running to make the system tolerant to failures.

As described we have a mechanism of deploying  a shared authentication that can be used by the storage and multiple compute nodes.  This does not cover the use case of enabling a user to log onto some compute nodes but not others.  To achieve this we need to think about adding some selectivity to the authentication.  There are many ways to achieve this, one approach would be to use Access Control Lists and dynamically build up exactly what servers any particular user might have access to - this may be the subject of a future post.  The simplest way that may achieve what we are looking for is to simply use the LDAP tree structure to define what users can be authenticated to a particular host.

A default directory, for authentication purposes, consists of a tree structure something like:-
  • Base DN (dc=example,dc=com)
    • ou=Group
      • cn=adm
      • cn=audio
      • cn=...
      • cn=users
      • cn=<your group>
      • ...
    • ou=Hosts
    • ....
    • ou=People
      • uid=adm
      • uid=avahi
      • ...
      • uid=<your user>
    • ...
In this tree structure the key entries are under ou=Group and ou=People where the users of your system will reside.  The "People" entry holding the users password, home directory, group, user identifier etc.

Reconfiguring the Directory to introduce new branches.

By creating an additional tree structure it is possible to group users and groups together and then set different servers to perform their search under these different structures.

For example, we might have 8 servers in the lower half of an Exalogic half rack being used for one department (sales) and the upper 8 servers by another department (finance)  With this a structure might look like:-
  • Base DN (dc=example,dc=com)
    • ou=Group
      • cn=adm
      • cn=audio
      • ...
    • ou=Hosts
    • ....
    • ou=People
      • uid=adm
      • uid=avahi
      • ...
    • ...
    • ou=departments
      • ou=sales
        • ou=Group
          • cn=sales
        • ou=People
          • uid=salesman01
          • uid=salesman02
          • uid=salesmanager
      • ou=finance
        • ou=Group
          • cn=finance
        • ou=People 
          • uid=accountant01
          • uid=accountant02
          • uid=financedirector

Compute Node configuration

On the client machines the only change we need to make is in the /etc/ldap.conf file, changing the Base DN entry.  So for the lower 8 compute nodes we would have an ldap.conf file that looks like:-

...
host 192.168.23.105

# The distinguished name of the search base.
# base dc=vbel,dc=com
base ou=sales,ou=departments,dc=vbel,dc=com

# Another way to specify your LDAP server is to provide an
# uri with the server name. This allows to use
# Unix Domain Sockets to connect to a local LDAP Server.
#uri ldap://127.0.0.1/
...

where the example base DN for the directory is dc=vbel,dc=com.

For the upper 8 compute nodes make the same change to the ldap.conf file but set the organisational unit to be finance.

...
base ou=finance,ou=departments,dc=vbel,dc=com
...


ZFS Storage Appliance Configuration

Things are slightly more complex on the ZFS storage.  Because this is a shared resource it has to be able to see all the users for all the departments.  In order to configure this there are a couple of settings required on the LDAP service configuration. 



In the example above we need to ensure that the "Base search DN" is set to the base DN of our directory server and that the "Search Scope" is set to subtree (recursive).  This means that the storage will search for users down all the branches from the Base Search DN.

By default the storage appliance will start the search from "ou=People, <Base DN>" in our example we have our departmental users under "ou=departments,<Base DN>" which does not match the default appliance search path.  To fix this we need to "Edit" the "Schema Definition".  Clicking the Edit... link brings up an additon options box to fill in.


In this simple window add the Base DN as the Search Descriptor for both Users and Groups, press save and apply the changes to the LDAP service.


Now check that you can log onto the lower 8 compute nodes as one of the sales users but not as a finance user and vice versa for the upper 8 compute nodes.

Gotcha's and Limitations

This approach is great because it is simple but it is important to understand some of the limitations.  Firstly, make sure that the same user does not exist under different branches this could lead to confusion as the storage might recognise the user under one branch while the compute node picks the user from the other branch.



7 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. Wow what a nice post and thanks to sharing this post.
    iphone games

    ReplyDelete
  3. Great info in this 4-part series. I'm trying the same setup on our Exalogics. My question is why not use Oracle Unified Directory? Is OUD not supported for authenticating Linux accounts? I built a prototype using non-Exa Linux and OUD seems to do the job. I even have OUD controlling sudo access. So I was just wondering if I should continue with OUD or switch to openldap. Thanks

    ReplyDelete
    Replies
    1. Hi Mike,

      No reason not to use OUD as the underpinning directory, I doubt if there will be any issues with it, indeed it may introduce quite a few other options in a design that OpenLDAP cannot support. For example, I think OUD has some abilities to integrate with active directory more or less "out the box" so if your customer is using AD for their user authentication then running OUD on the Exalogic rack will allow compute nodes (& vServers) and the storage to authenticate against AD for NFSv4 purposes. Not to mention the fact that OUD can massively scale as needed.

      I only chose to look at OpenLDAP because it practically ships with Oracle Linux, is fairly simple to configure and works for all that I needed from it. Obviously in a large enterprise there may be other requirements that drive the selection of another LDAP server.

      Regards



      Don

      Delete
  4. So luck to come across your excellent blog. Your blog brings me a great deal of fun.. Good luck with the site. Personal Cloud

    ReplyDelete
  5. LDAP Online Training, ONLINE TRAINING – IT SUPPORT – CORPORATE TRAINING http://www.21cssindia.com/courses/ldap-online-training-103.html The 21st Century Software Solutions of India offers one of the Largest conglomerations of Software Training, IT Support, Corporate Training institute in India - +919000444287 - +917386622889 - Visakhapatnam,Hyderabad LDAP Online Training, LDAP Training, LDAP, LDAP Online Training| LDAP Training| LDAP| "Courses at 21st Century Software Solutions
    Talend Online Training -Hyperion Online Training - IBM Unica Online Training - Siteminder Online Training - SharePoint Online Training - Informatica Online Training - SalesForce Online Training - Many more… | Call Us +917386622889 - +919000444287 - contact@21cssindia.com
    Visit: http://www.21cssindia.com/courses.html"

    ReplyDelete
  6. Maximum big residential complexes see numerous visitors every day. As a result, a strong visitor management system dealers in Pune is needed for the protection of the citizens.

    ReplyDelete