Read Only LDAP in Keystone

Posted on by

Organizational data is held in publicly accessible directories accessed via the Lightweight Directory Access Protocol(LDAP).  In general, the end applications have the ability to query via  LDAP, but not update it.  Up until Grizzly the OpenStack Identity management Service, Keystone, has required write access to the backing store if you wanted to be able to manage authorization from within OpenStack.  This mismatch has been addressed in Havana

Getting to the point where we could vary LDAP data from the rest of the data that Keystone managed required a few new abstractions.  The most important one happened in the Grizzly release:  the ability to group users.  Once we had groups, we had a natural place to split between what Keystone should manage directly and what Keystone should only consume.

In Havana, several of the entities previously managed via the Identity backend have been split off into a new backend called Assignments.  The Assignments driver now manages:

  • Projects (also previously referred to as Tenants)
  • Roles
  • Role Assignments
  • Domains

The Identity driver still manages:

  • Users
  • Groups
  • Group Assignments

The default drivers for Identity and for Assignments  is SQL.  If you were using SQL in the past to manage Identity, you will see no difference.

Now, we didn’t want to go and break all of the existing LDAP deployments out there, so there is a little bit of configuration magic involved.  If the Identity driver is specified to be LDAP and no Assignments driver is specified, Keystone assume that the system was previously all in LDAP, and will use the LDAP driver for Assignments.

If you want to have Identity served out of LDAP but Assignments served out of SQL, you must have the following keystone.conf options set.

[identity]
driver = keystone.identity.backends.ldap.Identity

[assignment]
driver = keystone.assignment.backends.sql.Assignment

The existing LDAP configuration documentation is still valid when identity is in LDAP and assignments are in SQL. The LDAP config values for entities in the assignment backend such as projects, and roles will be ignored.

In Havana, Keystone only supports a single LDAP server. There is an effort underway to support multiple, but that will have to wait until Icehouse.

19 thoughts on “Read Only LDAP in Keystone”

  1. If keystone support multiple LDAP servers, could you please explain how they work? Does each LDAP server work separately for different domain or group or others?

    Thank you.

  2. I would assume that each Tenant would need to be allowed to have a different authentication mechanism as part of it’s Keystone configuration. i.e. Active Directory for client 1, SAML for client 2, SQL for client 3, and LDAP for client 4.

    I dont think that running copies of these services should be running at all and Keystone would just cache the results of queries for a period of time.

  4. Hi Adam,
    We are experimenting with Openstack in our company and are trying to integrate Openstack with our company’s Active Directory, in order to be able to allow company users to login to Openstack dashboard using their company login credentials.

    Would you be able to help us with the steps to do? We are not finding any good documentation for this.

    1. It seems as though Keystone expects a specific AD structure, whereas our company’s AD structure is different and is read-only

    2. Do my company’s users need to be mapped somewhere in Openstack so that keystone could identify them?

    We need some guidance on how to go about with this. If you have any info, please do write to me at mahesh.narayan@siemens.com or narayanmahesh@gmail.com

    Thank you.
    Mahesh.

  6. HI Adam,
    Thanks for your reply. I will go through the links. It seems the presentations in the first link are not available. How do I access the actual presentations? The link is describing an event which I supposed already happened in the past?

    Thanks.
    Mahesh.

  7. Also, in this blog post, you have described how identity and assignment are managed separately. Assuming we get the user identity from our corporate LDAP, how does this mapping of that corporate user to the Keystone SQL backend assignment take place? Are there any steps? Most of our confusion is in this area as we do not understand this concept very well, being very new to it.

    A blog post on this might be the medicine we are looking for 😉

    Thanks a lot.

  8. The company’s AD is read only for us and we won’t be able to add organizationalRole or groupOfNames attributes to it, as recommended by keystone.

  9. There are two subsections in the keystone config file.

    [identity]
    driver = keystone.identity.backends.ldap.Identity

    [assignment]
    driver = keystone.assignment.backends.sql.Assignment

    You configure the LDAP section to pull only user and group information from AD. Ignore the other values.
    Now, using the ADMIN_TOKEN, create the admin role in the backend. You can see a sample script I wrote to do something like this here:

    https://review.openstack.org/#/c/82687/14/examples/scripts/initialize_keystone.py,cm

    Skip the parts that create users and groups, and just the part that creates the project, roles, and role assignments.

  10. Thanks Adam,
    That was great help. What I understand from the script is that a user logging in via the dashboard is essentially authenticated against LDAP and then the script goes ahead and creates a user account under the selected tenant with the admin role for that user.

    How does this script get invoked? This script reads environment variables. I am assuming that these are set by Openstack when the user logs in via the dashboard. So, when the user logs into the dashboard, I guess I would need to make a detour in the pipeline to somehow call this script?

    One the one hand, we have the ldap configuration in keystone.conf, and then we have this script. How do these fit together? Please give us some tips on when and from where we need to invoke this script.

    Sorry for being such a pain in the ass, but we are very new to this and are struggling real bad at the moment. Plus the Openstack documentation doesn’t help at all.

    I sincerely think a blog post from you would help many other like me 🙂

    Thanks a lot.
    Mahesh.

  11. Mahesh,
    No, there is no “created in” happening by default. The LDAP call is from Keystone, not from the Dashboard. The use needs a role in the tenant/project in order for them to get a token. That has to be set up ahead of time. Roles can be assigned to groups, though. So you could put everyone in one big group, and give them the Member role via that.

  12. Hi Adam,
    I think I wasn’t clear with my explanation. Apologize for that. I did understand that LDAP authentication is performed from Keystone. I also understood that the user and group information comes from LDAP and the user needs to be assigned a tenant and role in Keystone for him to be able to get a token.

    I still haven’t understood how your example script factors in, if we need to set up users and roles ahead of time. These users are Siemens employees who already have their domain login name and passwords already set up by Siemens and we wanted them to be able to login to Openstack with these same credentials, as we would be binding via LDAP to the Siemens Active Directory.

    In order to set up tenants and roles ahead of time, we would need to know the user’s credentials since we would need to add them to the tenant. This is impossible as we would not know any user’s credentials.

    I think we are having some disconnect in our understandings. Would it be possible for you to do some consultation for us? I could talk to my manager and make this a paid contract for say a month. Would it be possible for you to arrange for something like this through your company or individually?

    We would really like help from a consultant/expert as we are getting nowhere. Please let me know if such a thing could be arranged.

    Thanks and Regards,
    Mahesh.

  13. Hi Adam,
    Most of what we want to do seems to be talked about here:
    https://github.com/SUSE-Cloud/keystone-hybrid-backend

    We also want to do the same almost:
    – An LDAP (Siemens) user logs into the dashboard
    – We use keystone to authenticate the use
    – We see if the user is already added to a tenant with a default role
    – If not, we go ahead and add him [What about password? Use the same password with which he logged in?]
    – Then let the user login and do whatever he wants to do

    Would this be of more help to you in understanding what we are trying to do?

    Again, some consultation from you would really really help us.

    Thanks a lot.
    Mahesh.

  15. Mahesh,

    I work on Keystone full time for Red Hat. I am unable to do contracting work, as that would impact my ability to do my real job. Contract with Red Hat Global Support Services and you get my efforts thrown in at no extra cost, and the added benefit of working with professionals that are not me and won’t destroy you database and your systems. I am an Engineer. I break things. I lie. A make stuff up that you would never ever do in a production environment, to let me get my day-to-day job done. I don’t really lie, I just tell yoyu about how things should be working, get you excited, and then tell you “that is coming in the next release.”

    I don’t really think you want what you think you want. I think what you want is a bunch of precanned projects, one per group, that maps to a set of groups from LDAP. Do not assign roles to users, assign them to your pre-existing groups, and when a user comes in with one of those groups, they have access to the projects. If you need someting more than that, for a specific user, then you create the user-specific roles.

  16. Hi Adam,
    I have e-mailed the APAC RedHat Global Support Services team asking for available subscription options in India, where I work. Hopefully something can be arranged soon.

    I am finding it a little hard to follow what needs to be done. Sorry :).

    I understand what you mean to say. Yes, I would need Keystone projects mapped to LDAP groups, but from the dashboard I observed that role assignments were possible ony for users and not for projects. Did you mean to say that I need to assign roles to LDAP groups? This would not be possible as we won’t be able to make any changes to our corporate LDAP – we can only consume it and not edit it.

    “when a user comes in with one of those groups, they have access to the projects” – I did not understand this. Could you please elaborate a little? When a user logs in to dashboard, he is just presenting username/password credentials and no project information right (I mean no project\username – only username)? One user could be assigned to multiple projects and so OpenStack should be able to validate the user without the user having to specify the project in the login screen?

    So, the workflow looks like: User tries to login -> user is authenticated against LDAP by Keystone -> user has to be mapped to a tenant with some role (either beforehand or dynamically) -> user is granted access to dashboard and projects. This is the sequence I am trying to get working.

    The apriori/dynamic mapping is confusing me a lot. How would we add a user to a tenant apriori without knowing the user’s LDAP password? And how would we be able to predict which Siemens user might login to the dashboard?

    I thought your python script that adds the user to the tenant was the perfect solution to this, but I don’t know how to invoke this script and at what point in time during the workflow. So I guess I am missing pieces in the jigsaw.

    Also, we have an issue where we currently have the identity set to LDAP and assignment set to SQL as you recommended. But now when we do keystone user-list, it shows the LDAP users once and the same command shows the OpenStack service users next time. We don’t know why it shows 2 different sets of users for the same command.

    Thanks for your help so far Adam. I know you have been trying to help, but my absolute lack of knowledge in this area in spite of my several years of programming experience prevents me from fully comprehending what you are trying to say 🙂

    Regards,
    Mahesh.

  17. Hi Adam

    I’m configuring Keystone Icehouse with LDAP-read only(My company’s LDAP server).
    LDAP – Identity
    SQL – Assignment
    keystone user-list populates all user data when I By-pass authentication with OS_SERVICE_ENDPOINT and SERVICE_TOKEN(env), but when I try to login with my credentials in OS_USERNAME OS_PASSWORD OS_TENANT_NAME OS_AUTH_URL, I’m getting error : The request you have made requires authentication. (HTTP 401)
    And I’m also not sure which password it requires ??

    I’m a newbie, Please help me configure keystone with LDAP. Thanks 🙂

  18. @Mahesh

    I have configured keystone with LDAP.
    Identity(Users) LDAP
    Assignment(Tenants and Role mapping) SQL
    you simply need to give your user_tree_dn correctly to extract user-id, user-name, enabled=True.
    Tenants, Roles trees need not be configured .
    add keystone tenants and role with general keystone cmds
    And user-role-add to map you user to tenant and role.
    Mention your LDAP creds as (in openrc)
    export OS_USERNAME=ldap-name
    export OS_PASSWORD=ldap-password
    export OS_TENANT_NAME=tenant (from SQL)
    export OS_AUTH_URL=http://controller:5000/v2.0

    Regards,
    syed_hussain@persistent.co.in

  19. Hi Adam,
    Quick question. Is there any good documentation that explains the steps in moving from 2.0 to 3.0 API? I am currently struggling with this. It seems I need to get a new token and set new policies. Just changing the keystone endpoint isn’t enough I guess.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.