REMOTE_USER variable and interoperability with mod_authnz_ldap

[Vladimir-csp]

Hi.
I have a question regarding REMOTE_USER variable. It seems that mod_auth_gssapi always 'wins' in setting this var when used together with mod_authnz_ldap. Is it technically possible to somehow prevent it from having a final say?
So it would set REMOTE_USER at authentication phase, but allow mod_authnz_ldap to override it down the line?

Use case: clients come with ${sAMAccountName}@${domain} principals, but service behind apache expects ${userPrincipalName} in REMOTE_USER. For some users those values do not match (and case always does not match). I would like mod_auth_gssapi to do authentication, and allow mod_authnz_ldap to canonicalize REMOTE_USER later. But currently resulting value always comes from mod_auth_gssapi, I can not even override it with SetEnv.

[simo5]

Have you considered using the GssapiLocalName option ?

[simo5]

mod_auth_gssapi always return the full principal name (what you call ${sAMAccountName}@${domain} is actually principal@realm) unless you map this to something else in libkrb5 via the GssapiLocalName option. This is by design.

That said I do not know why one "wins" over the other, mod_auth_gssapi is not aware of other modules

[simo5]

Potentially look at these examples as well: https://stackoverflow.com/questions/33368653/how-do-i-set-remote-user-in-a-http-header

I think SetEnv happens too early, before authn modules are run.

[Vladimir-csp]

Yes, I plan to use GssapiLocalName because it would give proper ${sAMAccountName} for mod_authnz_ldap to query 1 to 1 removing any need for special treatment of users with long principals (whose ${sAMAccountName}s are abbreviated in the catalog in weird ways), but REMOTE_USER would also be set to ${sAMAccountName}.
The problem is: service application behind apache is hardcoded to look at the REMOTE_USER variable, not at any header, and I would like to find a way to allow mod_authnz_ldap to set it to canonical ${userPrincipalName} it got from LDAP.