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
- causes
-
SERVER-36456 MongoD does not support kerberos on Windows
-
- Closed
-