User Info Fetcher: Retrieve user info by sAMAccountName

[siegfriedweber]

Description

Allow the retrieval of user info by giving a sAMAccountName.

A customer handles technical and non-technical users differently in Active Directory. Technical users are e.g. created by the secret operator and have a meaningful User Principal Name, but their sAMAccountNames just consist of a prefix and a random hash. These technical users can be retrieved by userInfoByUsername. The non-technical users have a meaningful sAMAccountName and the UPN contains some e-mail addresses. In this case, the customer wants to retrieve the user info by sAMAccountName or preferably by a custom filter query.

Proposed change

A field customUserQueryFilter is added to the CRD for the backend experimentalActiveDirectory. If this field is set, then the given query is used when userInfoByUsername is called.

${USERNAME} will be replaced by the requested username.

spec:
  clusterConfig:
    userInfo:
      backend:
        experimentalActiveDirectory:
          ldapServer: ...
          baseDistinguishedName: ...
          kerberosSecretClassName: ...
          customUserQueryFilter: "(&(objectClass=person)(|(sAMAccountName=${USERNAME})(userPrincipalName=${USERNAME}))"

Edits:

• ${USER} renamed to ${USERNAME} and description added.

[NickLarsenNZ]

Do I understand it correctly that ${USER} will be interpolated (if so, can we make it USERNAME)? Will there be any other variables that can be interpolated?

[siegfriedweber]

Do I understand it correctly that ${USER} will be interpolated (if so, can we make it USERNAME)? Will there be any other variables that can be interpolated?

${USER} is the parameter of the userInfoByUsername function (https://github.com/stackabletech/opa-operator/blob/main/rust/user-info-fetcher/src/main.rs#L181). There are no other parameters to interpolate.

I will rename it to USERNAME in my proposal.

[nightkr]

1. The issue name is wildly different from the actual proposal (the proposal is much broader - which is fine in itself, but brings me to the second problem..)
2. The username of the retrieved UserInfo will still be the UPN, so this breaks the expectation of userInfoByUsername(x) == userInfoByUsername(userInfoByUsername(x).username) (as well as userInfoByUsername(x).username == x, though that one is arguably less severe) unless you take special care to still allow matching against UPN too (and since you have a generic mechanism you now also need to answer how you're going to handle conflicts, even though I agree that that shouldn't be a problem for specifically combining UPN and sAN).

[siegfriedweber]

The issue name is wildly different from the actual proposal

I did not adapt the issue name to my proposal because I did not want to rule out other more targeted proposals. Counter proposals are welcome!

The username of the retrieved UserInfo will still be the UPN, so this breaks the expectation of userInfoByUsername(x) == userInfoByUsername(userInfoByUsername(x).username)

A custom query filter is a powerful tool. If users want this power and have expectations of invariants like the mentioned one, then they are also responsible not to break them.

I assume that the common use case of the User Info Fetcher is to retrieve the group membership of users, and not to rely on fixed points.

and since you have a generic mechanism you now also need to answer how you're going to handle conflicts

I would change the current implementation (https://github.com/stackabletech/opa-operator/blob/25.3.0/rust/user-info-fetcher/src/backend/active_directory.rs#L168) to throw an error if multiple results are returned. It should then be documented, that the query must contain an identifier.

[nightkr]

Counter proposals are welcome!

I would suggest focusing for now on "just" making the attribute association configurable (which should then affect both querying and the returned data). We could still also allow customizing the whole filter in some way, but that should be a break-glass last resort, not the primary API we direct users towards.

If users want this power and have expectations of invariants like the mentioned one, then they are also responsible not to break them.

I think it's largely on us to decide which invariants we expect to provide.

I would change the current implementation (https://github.com/stackabletech/opa-operator/blob/25.3.0/rust/user-info-fetcher/src/backend/active_directory.rs#L168) to throw an error if multiple results are returned.

Yeah that probably makes sense, independently of everything else.

[siegfriedweber]

Here are more details to the problem:

The Rego rule receives the username xyz.

If this is a technical user, then Active Directory contains the following entry:

sAMAccountName: <some hash like `DEV-qChc8S598ejYsbOy`>
User Principal Name: xyz@REALM

If this is a non-technical user, then Active Directory contains the following entry:

sAMAccountName: xyz
User Principal Name: <e-mail address like `name@company.org`>

That means that making the attribute configurable, does not help because both attributes must be checked.

Would it be acceptable to add another function to the UserInfoFetcher for custom queries, like userInfoByQuery?
For the Active Directory backend, it is the user query filter. For the Keycloak backend, it is either the URL parameters or just not implemented.

[nightkr]

Wouldn't the email address be fine to match on in that case?

[siegfriedweber]

Wouldn't the email address be fine to match on in that case?

The Rego rule receives only the username, but not the e-mail address, and can therefore only query for the username. The e-mail address cannot be derived from the username in case of a non-technical user.

[nightkr]

Okay, so. After some more research and discussion with @siegfriedweber and @lfrancke...

Users can request Kerberos tickets for the following Kerberos principals:

1. ${samaccountname}@${realm} (sometimes referred as "implicit UPN", though this doesn't seem to be used actively on the "current" MSDN)
2. ${userprincipalname}@${realm} (with @ in the UPN escaped as \@, at least as rendered by MIT krb5, "explicit UPN" with the same outdatedness caveat). MSDN suggests that UPNs should contain a @, but this doesn't seem to be enforced by AD.
3. ${userprincipalname} / ${upnprefix}@${realm} if the UPN "suffix" (everything in the UPN after the @) matches the Kerberos realm name

We're not sure yet about how service principal names play into this, if at all.

If the user requests canonicalization when requesting their ticket (kinit -C) then it will be normalized by the AD KDC into the "implicit UPN" form, otherwise whatever form was requested by the user will be used.

The Windows session ticket seems to depend on how you logged in.. ssh ${sam}@${host} seems to produce the "explicit UPN", but a local desktop login seems to produce the "implicit UPN". This can be observed by running %WINDIR%\System32\klist (should be on your path, but is overridden by at least Temurin's OpenJDK 21 so it's safer to use the absolute path..).

Our secret operator (in AD mode) currently provisions principals of form 3.

It seems like the answer is that we just have to accept all forms; SAM and UPN should both be tolerated and we should probably pick one to canonicalize into. One caveat here is that forms 1 and 3 are ambiguous, which could give rise to confusion attacks. (Then again, UPNs aren't guaranteed to be unique in the first place either).

@lfrancke dug up https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/929272 which covers (as an aside) part of the lookup used by Windows Server 2003's KDC.. but not in enough details to add much further.

---

There's also the separate question of objectClass. I can see an argument for replacing the current hard-coded (objectClass=user) filter with a custom one (also for perf/scoping, like #691), but I think that is a separate feature that deserves a separate issue.

[nightkr]

Another problem is, well, the question of what clients send us. @siegfriedweber took at look at Kafka's name shortening, and it seems like it filters out anything after a single @ in the principal, failing if there is more than one. That would lead us to queries for:

• Form 1: ${samaccountname}
• Form 2: Shortening fails, rejected by Kafka
• Form 3: ${upnprefix}

Errors and rejected cases aside, I would expect to see a similar logic in other products.

For bonus fun, it looks like we can't really distinguish between all these cases.. samaccountname and UPN are both allowed to contain any number of @ (though I haven't tested how the KDC handles these).

Hence, the least worst query I could see would be samaccountname == ${username} /* form 1 */ || userprincipalname == ${username} /* form 2 */ || userprincipalname == ${username}@${realm} /* form 3 */.