Role lookup fails for Active Directory

Bug #1210675 reported by Brant Knudson on 2013-08-09
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Brant Knudson

Bug Description

When using Keystone against an Active Directory server, assigned roles aren't found for users.

To recreate, set up Keystone to go against Active Directory, create users and roles, then try to get a token scoped to a project as a user. It will fail with

 User admin is unauthorized for tenant 3c1299e1042a40009691dfb3ad474180 (HTTP 401)

I looked into this a bit, and it looks like the problem is that DNs aren't being compared correctly.

With Active Directory, when you add a roleOccupant, the DN gets normalized. For exmample, here I add a "cn=..." dn to an entry, but when I search to get it back, it's now "CN=..." (the attribute name has been capitalized).

$ ldapmodify <<EOF
dn: CN=8bd9f13ac6cf43f7ac85fd95c66d0a4b,CN=3c1299e1042a40009691dfb3ad474180,ou=groups
add: roleOccupant
roleOccupant: cn=8bd9f13ac6cf43f7ac85fd95c66d0a4b,CN=3c1299e1042a40009691dfb3ad474180,ou=groups

modifying entry "CN=8bd9f13ac6cf43f7ac85fd95c66d0a4b,CN=3c1299e1042a40009691dfb3ad474180,ou=groups"

$ ldapsearch -LL -s base \
    -b "CN=8bd9f13ac6cf43f7ac85fd95c66d0a4b,CN=3c1299e1042a40009691dfb3ad474180,ou=groups" \
    "(objectclass=organizationalRole)" roleOccupant
version: 1

dn: CN=8bd9f13ac6cf43f7ac85fd95c66d0a4b,CN=3c1299e1042a40009691dfb3ad474180,ou=groups
roleOccupant: CN=8bd9f13ac6cf43f7ac85fd95c66d0a4b,CN=3c1299e1042a40009691dfb3a

There's suspect code in keystone/assignment/backends/

            return [self.role._dn_to_id(a.role_dn)
                    for a in role_assignments
                    if a.user_dn == user_dn]

here, user_dn is like 'cn=xxx' and the result user_dn is like 'CN=xxx'
so they don't match.

Keystone needs to do DN comparisons properly, for example by normalizing.

Brant Knudson (blk-u) on 2013-08-09
Changed in keystone:
assignee: nobody → Brant Knudson (blk-u)

Fix proposed to branch: master

Changed in keystone:
status: New → In Progress
Dolph Mathews (dolph) on 2013-08-23
tags: added: grizzly-backport-potential
Changed in keystone:
importance: Undecided → High
milestone: none → havana-3
Brant Knudson (blk-u) wrote :

Looks like Grizzly doesn't have this problem. I tried backporting the tests proposed for master to Grizzly and the tests passed.

In Grizzly, we compare user_ids:

Whereas in master, we compare DNs:

Maybe the fix in master should be to compare IDs rather than DNs?

tags: removed: grizzly-backport-potential
Brant Knudson (blk-u) wrote :

Changed the fix proposed for master to compare IDs rather than DNs. Should be a little more efficient, too.

Submitter: Jenkins
Branch: master

commit e4b1d228e6a3af05343672e824e7eeb5386f1a65
Author: Brant Knudson <email address hidden>
Date: Mon Aug 12 15:16:44 2013 -0500

    Fix role lookup for Active Directory

    When using Keystone against an Active Directory server, assigned
    roles weren't found for users.

    When roles are added as DNs in the roleOccupant attribute, an LDAP
    server can normalize the value so that when the entry is read later
    the roleOccupant isn't exactly the same as it was when added.
    Keystone should compare users by ID rather than by DN.
    (Note that this is how the comparison is done in Grizzly.)

    Keystone's fake LDAP is changed to muck with roleOccupant and
    member DNs by uppercasing attribute names (like Active Directory).
    The code is fixed to compare users by ID rather than DN.

    Change-Id: Iaa41c3ef9febcabef0662f38b13d319a5b5583bc
    Resolves-Bug: #1210675

Changed in keystone:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2013-09-05
Changed in keystone:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2013-10-17
Changed in keystone:
milestone: havana-3 → 2013.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers