I think Entra ID requires the upn (user@domain) for authentication. I was considering mapping this to the cn though (so that you could leave off the @domain part). Is this what you're interested in?

That would work. I have also seen SAML registered apps allow for the UPN to be munged from the AAD side.

This shouldn't be too difficult to add. It would get tricky FYI if you have multiple configured domains, because then we'd pick the first matching user. For example, if you have 2 domains example.com and test.com configured, then a user with the UPN tux in each domain ([email protected] and [email protected]), then we'd have to just pick the first user in the domain list.

Now that I think of it, that won't work for our use case. I need to be able to distinguish the AAD users from the local users and prevent username collisions. What would probably be useful is a parser where I could use the cn + another string like ABCtom for example.

Himmelblau filters out local account names and ignores them. As long as the CNs don't collide with local account names, it would be fine.

They will collide. A lot of our usernames are not very unique

Are the users related? Can we map the local user to an Entra Id user?

no, not at all.

Hrm, maybe I could introduce a filter option, which matches ABCtom then translates it to [email protected], etc.

that would definitely work for us :)

I think I'm going to provide a script option, where you can provide a custom script that modifies the username as you wish.

let me know if you need someone to test

Ok, I'll probably have something for you to try today.

Hrm, I forgot that this could effect the user cache. This may take me a bit to sort out.

This is now partially implemented in #230 and #231. You now only need enter the CN name (the front part of the full UPN) to login.

@tastle73 I've added the script mapping feature to this branch: https://github.com/himmelblau-idm/himmelblau/tree/stable-0.6.x_map_logon_name

Would you try it out? I'll do some testing probably tomorrow.

@tastle73 there is no build output in your message. Did you forget to attach it?

I tried a screenshot and it was dropped. Here is the txt:

Compiling compact_jwt v0.4.2
error: failed to run custom build command for idmap v0.6.5 (/root/himmelblau/himmelblau-0.6.5/src/idmap)

Caused by:
process didn't exit successfully: /root/himmelblau/himmelblau-0.6.5/target/release/build/idmap-e1e88fe48764074e/build-script-build (exit status: 101)
--- stderr
aclocal: error: configure.ac:3: file 'sssd/version.m4' does not exist
autoreconf: aclocal failed with exit status: 1
thread 'main' panicked at src/idmap/build.rs:14:9:
Failed to configure sss_idmap
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
make: *** [Makefile:3: all] Error 101

It's because you didn't checkout the submodules. Run make, instead of cargo build. The make command will check out the submodules for you.
This requirement will be removed in 0.7.x.

What is your target distribution? Perhaps I could generate a package for you?

RHEL 8 and derivatives.
I git cloned the branch and that worked

Try setting using the new name mapping script option in the himmelblau.conf, and let me know if this works for you:

# In some cases, mapping the UPN to the CN may be impractical. The following
# option executes the specifed filename (any executable), which MUST accept
# a single argument (the user provided login username). The executable MUST
# print a single response to stdout, which will be the UPN that the provided
# login username maps to.
name_mapping_script =

Also set cn_name_mapping = false when you use name_mapping_script.

I am confused about how this will work. I thought the login one would enter is [email protected] and it would then be for example xxxfoo on the system they log into. I tried it the other way round and it didn't work either

I thought you wanted to be able to enter xxxfoo, and for the script to transform this into [email protected]? The code is expecting to end up with the upn output from the script.
I guess I don't understand what the purpose would be the other way around? I thought the purpose was to be able to enter a short username, which is transformed into the full upn?

I didn't explain my request very well. I am sorry.

I was hoping we could use the UPN as the authenticator/username and then transform that into a non-email formatted user on the system.

Oh, ok. I'll have to think about this some more.

Any ideas? I think if you just reverse the code it would work.

I suppose I could just change the nss output to map the username for that script. I'd need to match the same via input though, since services may send requests using that nss name.
Sorry, I haven't given this the attention it deserves. I'll take a look at it soon.

So the name mapping script is going to need to handle mapping both ways:
upn -> mapped name
mapped name -> upn

Otherwise this won't work.

Actually, maybe what it needs to do is this:
upn -> upn
mapped name -> upn
That way we consistently use the upn behind the scenes, but can receive the mapped name, and transcribe it.
Maybe I could just ignore the name mapping if I see a UPN, actually.

FYI, the way I have to implement this, you'll actually be able to login using the mapped name if you choose (or the full UPN).

Ok, going back to what I said before. I need the script to map both directions:
upn -> mapped name
mapped name -> upn

So your script should detect if the input is a UPN. If so, map it to the mapped name. If it detects a mapped name, it should convert it back to a UPN.