RMS Enterprise & Active Directory authentication setup
Fraser
Posts: 2
I believe we have set up RMS to authenticate to our AD but keep receiving the message "No Role Membership for User XXXXX" when we attempt to login.
We are using:
User attribute name: sAMAccountName
Group attribute name: member
We have a role configured against LDAP using an appropriate distinguished name which tests ok.
According to the flow chart in the RMS System Admin Guide page 314 a matching account should be created in the RMS database before role membership is looked up, we do not see this happening.
Non AD accounts work fine.
We are using SQL Server Standard 2008 with Windows Server 2008 Standard 32bit and a Windows Server 2008 Domain Controller.
Are there any examples of configurations for LDAP / AD authentication available? Any other thoughts would be appreciated.
We are using:
User attribute name: sAMAccountName
Group attribute name: member
We have a role configured against LDAP using an appropriate distinguished name which tests ok.
According to the flow chart in the RMS System Admin Guide page 314 a matching account should be created in the RMS database before role membership is looked up, we do not see this happening.
Non AD accounts work fine.
We are using SQL Server Standard 2008 with Windows Server 2008 Standard 32bit and a Windows Server 2008 Domain Controller.
Are there any examples of configurations for LDAP / AD authentication available? Any other thoughts would be appreciated.
0
Comments
Assuming both of your base DNs are right, the settings do look right. Try using ldap://server:3268/ for your LDAP url, port 3268 is the global catalog port, which I believe is the same as the LDAP port, but it doesn't send any LDAP referrals, which were causing issues for me.
Any ideas?
Sent from my iPad using Tapatalk HD
We started with a functioning setup using accounts defined within RMS (directory services disabled), some of which matched accounts in our ADS and one of which didn't. I then activated directory service authentication using the port number suggested by mstocum, and set up a role with the distinguished name of a group in ADS, which tested OK. We still received the same error for all non-builtin accounts, 'no role membership for user'.
I accessed the ADS server using an LDAP browser and the same bind credentials entered into RMS, and confirmed that I could search for users by samaccountname, and for groups that had a member attribute matching a user's distinguished name.
I also confirmed that the accounts I'd defined in RMS that matched ADS accounts had their details (first and last name, email address) updated correctly in the RMS Enterprise SQL database. The account that didn't match an ADS account was automatically pruned.
Contrary to the documentation no new accounts were created in the RMS database, even though the user lookup in ADS appears to have worked.
I reconfigured access to the database to use an internal account flagged as DB owner, with no change in behaviour, so I don't believe DB access rights are the issue.
I don't know if the failure to create accounts is an issue. It's possible that, in practice, that step occurs at a later point than the documentation indicates (possibly after a successful role lookup), or they might be get deleted on failure to match a role. My best guess at this point is that it's the group lookup that's failing, or possibly returning data that doesn't quite match what's expected (I noted that some results included extra spaces - that doesn't matter in an LDAP search, but would affect a string comparison.) We also get multiple ADS groups returned, but I'd hope that has been accounted for.
In any case, we've finally got this working. It turns out that the 'Base' and 'Group Base' set in the RMS Configuration Utility needed to be the distinguished name of the same OU. Users and Groups can be in separate OUs below that, as the system clearly scans multiple levels of the LDAP hierarchy, but if we specify the user OU for 'Base' and the group OU for 'Group Base', it breaks.
One further catch is that the base DNs can't be the root DN of an AD domain (i.e. just the 'DC' components of the LDAP path), it has to be at least one OU deeper than that - which was OK for us as the AD we're connecting to has been customised, and all our users and groups are in a sub OU - but it looks to me like it will never work with a default AD, which places Domain Users and Domain Groups directly under the root DN.
Which port are you using in your LDAP url? This really sounds like what happens when you're using the LDAP port and it starts getting hung up on referrals. If you specify the Global Catalog port of 3268 instead, you should be able to use the root DN without any problems. I'm even using different DNs for users and groups (base DN for users, OU for groups) without any issues.
Tried the global catalog port early in the piece, it didn't help us. It may get around the root DN issue, though; we'd found a working solution by that point, so didn't investigate further.