Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-30491

LDAP authorisation tries to transform username when GSSAPI (Kerberos) is used as authentication twice

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 3.7.1
    • Affects Version/s: 3.4.4, 3.4.6
    • Component/s: Security
    • None
    • Minor Change
    • ALL
    • v3.6
    • Hide

      1. Kerberised mongod using LDAP authorisation
      2. kinit the user you want to authenticate with
      3. logon to the mongod and db.auth() the user on the $external database

      mongod config used attached

      Show
      1. Kerberised mongod using LDAP authorisation 2. kinit the user you want to authenticate with 3. logon to the mongod and db.auth() the user on the $external database mongod config used attached
    • Platforms 2017-12-18

      A kerberised mongod using LDAP authorisation is trying to transform and bind the kerberos user principal twice when a user logs on using GSSAPI. This results in the following messages in the mongod log file entries:

      2017-08-03T02:14:09.627+0000 E ACCESS   [conn18] LDAP authorization failed: FailedToParse: Failed to transform bind user name to LDAP DN: Failed to transform user 'mongomonitor'. No matching transformation out of 1 available transformations. Results: { rule: { match: "(.+)" ldapQuery: "CN=USERS,DC=BEAGLE,DC=MONGODB,DC=COM??sub?(userPrincipalName={0})" } error: "UserNotFound: LDAP query 'BaseDN: "CN=USERS,DC=BEAGLE,DC=MONGODB,DC=COM", Scope: "sub", Filter: "(userPrincipalName=mongomonitor)"' returned no results" }, 
      2017-08-03T02:14:09.627+0000 D ACCESS   [conn18] auxpropMongoDBInternal failed to find privilege document: OperationFailed: Failed to acquire LDAP group membership
      2017-08-03T02:14:11.161+0000 I ACCESS   [conn18] Successfully authenticated as principal mongomonitor@EXAMPLE.COM on $external
      2017-08-03T02:14:11.161+0000 I COMMAND  [conn18] command $external.$cmd command: saslContinue { saslContinue: 1, conversationId: 1, mechanism: "GSSAPI", payload: BinData(0, 050404FF000C0000000000002B6C707F010000006D6F6E676F6D6F6E69746F72404558414D504C452E434F4DB6CCC2E495461D03D086DB4A) } numYields:0 reslen:78 locks:{} protocol:op_query 2293ms
      

      The kerberos principal used here is mongomonitor@EXAMPLE.COM. First the mongod tries to transform using mongomonitor as userPrincipalName but fails. It then uses mongomonitor@EXAMPLE.COM and succeeds as this is correctly defined in LDAP.

      Is this intended or a bug?

      The error message gives the impression it fails but I can use the user to do tasks he is allowed to due to the later correct mapping:

      2017-08-03T02:14:11.161+0000 I COMMAND  [conn18] command $external.$cmd command: saslContinue { saslContinue: 1, conversationId: 1, mechanism: "GSSAPI", payload: BinData(0, 050404FF000C0000000000002B6C707F010000006D6F6E676F6D6F6E69746F72404558414D504C452E434F4DB6CCC2E495461D03D086DB4A) } numYields:0 reslen:78 locks:{} protocol:op_query 2293ms
      2017-08-03T02:14:11.161+0000 I COMMAND  [conn18] command admin.$cmd command: isMaster { isMaster: 1 } numYields:0 reslen:524 locks:{} protocol:op_query 0ms
      2017-08-03T02:14:11.162+0000 I COMMAND  [conn18] command admin.$cmd command: replSetGetStatus { replSetGetStatus: 1 } numYields:0 reslen:1288 locks:{} protocol:op_query 0ms
      2017-08-03T02:14:11.163+0000 I COMMAND  [conn18] command local.oplog.rs command: serverStatus { serverStatus: 1, oplog: 1, tcmalloc: 1 } numYields:0 reslen:23388 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, oplog: { acquireCount: { r: 1 } } } protocol:op_query 0ms
      2017-08-03T02:14:11.164+0000 I COMMAND  [conn18] command local.oplog.rs command: collStats { collstats: "oplog.rs" } numYields:0 reslen:5810 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, oplog: { acquireCount: { r: 1 } } } protocol:op_query 0ms
      

      mongod log file attached

        1. mongod.log
          22.70 MB
        2. mongodconfig
          0.9 kB

            Assignee:
            sara.golemon@mongodb.com Sara Golemon
            Reporter:
            markus.thielsch@mongodb.com Markus Thielsch
            Votes:
            1 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: