RMS Enterprise & Active Directory authentication setup

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.

Comments

  • mstocummstocum Junior Member Posts: 119
    Did you ever get this working?

    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.
  • Chuck CarpenterChuck Carpenter ACE Control Expert, ACE RMS Enterprise Expert Posts: 15
    I am having the same issue. I got this to work in my home lab, but when I tried it out at work, it failed with no role membership error.

    Any ideas?


    Sent from my iPad using Tapatalk HD
  • FraserFraser Junior Member Posts: 2
    No, not working yet. We've been under pressure with other projects but hope to investigate mstocum's suggestions over the rest of this week. Will post again with progress.
  • cache22cache22 Junior Member Posts: 3
    Further to Fraser's comments, I can expand on a few details.

    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.
  • badgerarcbadgerarc Junior Member Posts: 2
    It would appear that RMS uses First Name Last name in AD lookup so you need to use those (as my IT guys quite kindly told me in getting mine setup).
  • cache22cache22 Junior Member Posts: 3
    I'd guess that would be because your installation is configured to use the 'CN' attribute instead of 'sAMAccountName', if it's AD based. In our case, sAMAccountName was working (as shown by the logs after I set the 'com.amx.rms.service' log level to 'Debug', which verified most of my earlier guesses - the user lookup was succeeding, but the group lookup was failing.)

    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.
  • PhreaKPhreaK Senior Member Posts: 966
    You may want to check out the v4.1 server release. There's a few improvements in relation to LDAP support.
  • mstocummstocum Junior Member Posts: 119
    cache22 wrote: »
    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.
  • cache22cache22 Junior Member Posts: 3
    mstocum wrote: »
    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.
Sign In or Register to comment.