Feature: Change the attribute that the broker queries from EntraID to User Principal Name

carlesgs commented 1 month ago

Is there an existing request for this feature?

[X] I have searched the existing issues and found none that matched mine

Describe the feature

First of all, thank you for your great work. And now I will explain the problem we have at my university.

When a user logs in through the broker, the option to create a local password never appears. The initial GDM screen appears again.

Using the “login” command I have been able to see the following message:

“could not get user info: could not fetch user info: returned error “name.surname@enterprise.com” does not match the selected one “XXXXXX@enterprise.com” (where XXXXXX is a string of numbers identifying the user). XXXX@enterprise.com is the user/string used to login.

I understand that the necessary attribute that the broker checks for the user is the email, which in our case, does not match the string used to log in. The normal thing in a company is that the “User Principal Name” and the email match.

Is it possible to define in the installation which attribute to use? or is it possible for the broker to check the UPN (User Principal Name)?

Checking the UPN would be useful for the two situations I mentioned above.

Another option would be for the broker to look at several fields of the user information, until it checks the matching one.

Best regards,

Describe the ideal solution

To be able to define the attribute queried by the broker EntraID or change the query attribute to “User Principal Name” (I think it covers all possible scenarios).

Alternatives and current workarounds

No response

System information and logs

Environment

broker version: please run snap info authd-msentraid

channels edge and stable, version 0.1

authd version: please run /usr/libexec/authd version

0.3.1-ppa4

gnome shell version: please run apt policy gnome-shell

46.3.1-1ubuntu1~24.04.1

Distribution: (NAME in /etc/os-release)

Ubuntu

Distribution version: (VERSION_ID on /etc/os-release):

24.04

Log files

Please redact/remove sensitive information:

Authd entries:

journalctl -u authd.service

de jul. 18 21:30:45 Litux-HP-830-G8 systemd[1]: Stopping authd.service - Authd daemon service... de jul. 18 21:30:45 Litux-HP-830-G8 systemd[1]: authd.service: Deactivated successfully. de jul. 18 21:30:45 Litux-HP-830-G8 systemd[1]: Stopped authd.service - Authd daemon service. -- Boot 667d27e76a094d749ad2b80d4b01e9f6 -- de jul. 18 22:42:41 Litux-HP-830-G8 systemd[1]: Starting authd.service - Authd daemon service... de jul. 18 22:42:46 Litux-HP-830-G8 systemd[1]: Started authd.service - Authd daemon service. de jul. 18 22:44:17 Litux-HP-830-G8 systemd[1]: Stopping authd.service - Authd daemon service... de jul. 18 22:44:17 Litux-HP-830-G8 systemd[1]: authd.service: Deactivated successfully. de jul. 18 22:44:17 Litux-HP-830-G8 systemd[1]: Stopped authd.service - Authd daemon service. -- Boot b2c5ae436c1248a5b098e9b43c11f4aa -- de jul. 19 12:09:40 Litux-HP-830-G8 systemd[1]: Starting authd.service - Authd daemon service... de jul. 19 12:09:45 Litux-HP-830-G8 systemd[1]: Started authd.service - Authd daemon service.

MS Entra ID broker entries:

journalctl -u snap.authd-msentraid.authd-msentraid.service

de jul. 19 12:09:42 Litux-HP-830-G8 systemd[1]: Started snap.authd-msentraid.authd-msentraid.service - Service for snap application authd-msentraid.authd-msentraid. de jul. 19 12:09:42 Litux-HP-830-G8 authd-msentraid.authd-msentraid[2086]: time=2024-07-19T12:09:42.791+02:00 level=ERROR msg="could not create broker with provided issuer and client > de jul. 19 12:09:42 Litux-HP-830-G8 systemd[1]: snap.authd-msentraid.authd-msentraid.service: Main process exited, code=exited, status=1/FAILURE de jul. 19 12:09:42 Litux-HP-830-G8 systemd[1]: snap.authd-msentraid.authd-msentraid.service: Failed with result 'exit-code'. de jul. 19 12:09:42 Litux-HP-830-G8 systemd[1]: snap.authd-msentraid.authd-msentraid.service: Scheduled restart job, restart counter is at 5. de jul. 19 12:09:42 Litux-HP-830-G8 systemd[1]: snap.authd-msentraid.authd-msentraid.service: Start request repeated too quickly. de jul. 19 12:09:42 Litux-HP-830-G8 systemd[1]: snap.authd-msentraid.authd-msentraid.service: Failed with result 'exit-code'. de jul. 19 12:09:42 Litux-HP-830-G8 systemd[1]: Failed to start snap.authd-msentraid.authd-msentraid.service - Service for snap application authd-msentraid.authd-msentraid. de jul. 19 12:19:43 Litux-HP-830-G8 systemd[1]: Started snap.authd-msentraid.authd-msentraid.service - Service for snap application authd-msentraid.authd-msentraid.

Application settings

Please redact/remove sensitive information:

Broker configuration:

cat /var/snap/authd-msentraid/current/broker.conf

[oidc] issuer = https://login.microsoftonline.com/myDirectoryTenantID/v2.0 client_id = myApplicationClientID

Broker authd configuration:

cat /etc/authd/brokers.d/msentraid.conf

[authd] name = Microsoft Entra ID brand_icon = /snap/authd-msentraid/current/broker_icon.png dbus_name = com.ubuntu.authd.MSEntraID dbus_object = /com/ubuntu/authd/MSEntraID

Relevant information

No response

Double check your logs

[X] I have redacted any sensitive information from the logs

denisonbarbosa commented 1 month ago

Hey @carlesgs, thanks for reporting this! Indeed, we were already aware of this possible issue. We decided to enforce the email as the login to be compatible with other OIDC providers, but we have plans to turn this into a provider-specific behavior, thus making the msentraid broker use the username for authentication rather than the email.

carlesgs commented 1 month ago

Great news. Again, thank you very much

didrocks commented 1 month ago

Ok, I have investigated a little bit with potential future brokers too, like the google one.

We are getting the following claims with login, profile and email scope on Entra ID:

{'aud': 'SOME_UUID",
 'iss': 'https://login.microsoftonline.com/TENANT-UUID/v2.0',
 'iat': 1721999999,
 'nbf': 1721999999, 
 exp': 1721999999,
 'email': '', # or any email that could be set (but by default, none)
 'name': 'Test Foo',
 'oid': 'some-UUID',
 'preferred_username': 'test-foo@tenantname.onmicrosoft.com',
  'rh': '0.SOMEVERYLONGREFERENCE.',
  'sub': 'SomeID',
  'tid': 'ANOTHER-UUID',
  'uti': 'SOME ID',
  'ver': '2.0'}

Where User Principal Name is of a form of an email address (on the domain tenantname.onmicrosoft.com, and is set to preferred_username.

With google, the token id has the following claims, with the same set of scopes:

{
    "iss": "https://accounts.google.com",
    "azp": "SOMEID.apps.googleusercontent.com",
    "aud": "SOMEID.apps.googleusercontent.com",
    "sub": "SOMEID",
    "email": "myemail@gmail.com",
    "email_verified": true,
    "at_hash": "somehash",
    "name": "First LastName",
    "picture": "https://lh3.googleusercontent.com/a/uri-to-picture",
    "given_name": "My First Name",
    "family_name": "My Family Name",
    "iat": 1721999999,
    "exp": 1721999999
}

As we can see here, there is no preferred_username, only an email would makes sense here.

So, it means that depending on the provider, we should probably follow the following logic, keeping the logic factored out for now (we can split later on).

To be able to be more versatile, while still ensuring we are doing consistency checking between the value entered by the user and what identity was really used to login to the provider, I proposed we do consecutive consistency checks in the following order:

Check against preferred_username,if it exists and not empty.
Then, check against emails,if it exists and not empty.

Of course, we will stop at the first match as this is only a check and no value is derived from that (we keep the name used to login with).

It would means in practice for MS Entra ID, that we first check against the User Principle Name and fallback to emails if this doesn’t match. On google, we would only match against the user email.

One caveat with that approach. Let’s say an user has a User Principle Name "Foo@domain.com" and an email "Bar@domain.com", it will mean that with MS Entra ID, they can login with any of those names, BUT those will be different local accounts, as we respect the value that was entered by the user. I think this is an acceptable tradeoff but will be interested into feedbacks here. Another approach will be to have an order and stop and enforcing the first non empty value, but it sounds less versatile in the long term and the order could then change based on the organization. Maybe some will want to match against emails and not User Principle Name for MS Entra ID.

carlesgs commented 1 month ago

Hi @didrocks @denisonbarbosa ,

I confirm that the assumption about food@domain.com and bar@domain.com is true. I have been able to log in with name.surname@domain.com (e-mail), as this is the value expected by the broker, and the home that is created is of this type /home/name.surname@domain.com .

The second approach seems correct to me, but it is true that it limits the changes that a company can make in the future.

By the way, when setting the local password, the new sessions do not appear in the Entra ID tenant, so you cannot monitor the access to a Linux desktop (this is normal, since the user access locally). I don't know if it is possible to achieve the same behavior as in a Windows login, which does log all access, is it ok if I open another ticket?

Thanks,

didrocks commented 1 month ago

Thanks for the quick feedback!

The second approach seems correct to me, but it is true that it limits the changes that a company can make in the future.

If we go with the first solution, do you forsee problems with people using both login "Foo@domain.com" and "Bar@domain.com"?

By the way, when setting the local password, the new sessions do not appear in the Entra ID tenant, so you cannot monitor the access to a Linux desktop (this is normal, since the user access locally). I don't know if it is possible to achieve the same behavior as in a Windows login, which does log all access, is it ok if I open another ticket?

Please open a bug for ensuring the issue is logged. I’m unsure however if this is something that is easily doable on our side. Keep in mind that the Windows login integration is probably an particular application that has additional integration to populate those logs. I think you will have more leverage by opening a ticket against MS Entra ID portal itself asking to have those monitoring logs for regular applications. Another way would be for our app to push its own logs, but it can be blocked on the client side or with firewall and will require some Azure AD subcription.

carlesgs commented 1 month ago

I certainly don't know, sorry. I just think that if I myself have deduced that the broker checks the email instead of the UPN (in our university name.surname@domain.com is the alias of the email account), another user could do the same. As for the ‘home directory' being different, I don't foresee any problems.

I am more concerned about session monitoring, as this is the first principle of security when there is an incident from a computer. Who has logged on to the computer? If a computer receives an intrusion, the intruder will most likely delete or empty logs, etc. If logins are logged in Entra ID, we gain in security. I will open a new ticket as this is a new topic.

Thanks and have a nice weekend.

namato1 commented 1 month ago

Im seeing a similar issue where the username@enterprise.com does not match username@ENTERPRISE.com. its failing to login because the domain name is in all caps for this user. If the user types in all caps for domain, it still does not work, but the error does is no longer there.

didrocks commented 1 month ago

This is now available in the edge channel of the snap. We will promote this to stable with a new authd by end of next week! Keep us posted if that fixes your request :)

carlesgs commented 1 month ago

Thank you very much for your work. In my tests, the validation worked with XXXX@enterprise.com (our UPN). Previously, it worked with name.surname@enterprise.com (in our case the e-mail field), but with the last update it didn't. I understand that if the UPN value is met, no more fields are checked. I understand that if the UPN value is met, no more fields are checked. For my company this is the perfect situation. I understand that if the UPN is not met, then the e-mail value is checked. Is this the case?

Regards,

didrocks commented 1 month ago

We decided to have a per provider approach and not letting 2 ways of connecting for the same provider.

Meaning, it makes sense for MSEntraID to prefer UPN, as you said. The issue is then, if we allow email if UPN is not met, then, people can indifferentliy use one of the other authentication login. This creates challenges as those are 2 different users on the system, what about the home directory and so on? There is no notion of aliases. And if we allow to resolve then to the UPN, there are some issues with SSH (first login), as the user id is derived from the user name and can’t be changed afterwards.

So, we are starting with the close/open principles while we are at this early stage: let’s close it down as much as possible, with stricter rules, which are easier to relax in the future, than allowing scenarios with possible side-effects. We can re-evaluate and see how we are going to counter the previously described challenges once the demand is here.

Happy that fixes it for you! I’m closing the issue then! :)

didrocks commented 1 day ago

as you probably noticed this is now fixed in the stable channel, please switch back to it so that you are not hit by a less tested version as edge is automatically updated on each commit :)

ubuntu / authd