Jamf Nation Community

rabbitt · ‎12-12-2022

First, let me start off by saying you should never use basic auth for anything, anywhere, at any time.

Next, let me tell you why you need basic auth or “Resource Owner Password Grant” or “Resource Owner Password Claim” (if you speak Microsoft) or “Resource Owner Password” (if you speak Okta) or just plain old “password” (if you read the ancient runes of the .well-known/openid-configuration endpoints). I promise you it’s a good reason.

What is ROPG

The basic password flow used by Resource Owner Password Grant (ROPG) is literally an endpoint receiving a user name and a password and returning something to say the password is good, bad, or other.

curl 'https://login.microsoftonline.com/12345678-9abc-def1-0000-000000000000/oauth2/v2.0/token' \
-X POST \
-H 'Host: login.microsoftonline.com' \
-H 'Accept: */*' \
-H 'Connection: keep-alive' \
-H 'Accept-Language: en-US,en;q=0.9' \
-H 'Content-Length: 295' \
-H 'User-Agent: Jamf%20Connect%20Configuration/2606 CFNetwork/1399.4 Darwin/22.1.0' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'grant_type=password&username=edith%2Emackenzie%40example%2Ecom&password=MySuperSecretPassword&scope=openid%20profile%20email&client_id=12345678-9abc-def1-0000-000000000000&redirect_uri=https%3A%2F%2F127.0.0.1%2Fjamfconnect&code_verifier=A3B50EC0-1807-4B3D-834A-4794346DDED1A3B50EC0-1807-4B3D-834A-4794346DDED1'

In the example cURL request above, we can see what Jamf Connect sends as a validation of the user’s password. We can see some breakdowns of what’s inside…

curl 'https://login.microsoftonline.com/12345678-9abc-def1-0000-000000000000/oauth2/v2.0/token'

Here’s the website that we’re talking to. We’re sending the request (POST) the user name and password…

grant_type=password

We’re asking to do a non-interactive basic authentication…

username=edith%2Emackenzie%40example%2Ecom

The username is edith.mackenzie@example.com

password=MySuperSecretPassword

The password is…

scope=openid%20profile%20email

We want to use an Open ID Connect flow and would like you to send back to us the user’s info in their profile like their name and email address

client_id=12345678-9abc-def1-0000-000000000000

This is the application registration on the identity provider. Every identity provider’s format is slightly different.

When the endpoint responds, it sends back information and tells the requesting computer to hand the response over to the redirect_uri (in our case, https://127.0.0.1/jamfconnect, aka “localhost” or the machine that is running Jamf Connect). This response will be one of three things, and every IDP sends a slightly different format for the responses. These are what Microsoft does:

An error saying the password is wrong:

AADSTS50126: Error validating credentials due to invalid username or password.

An error, but we wouldn’t get it if the password wasn’t good:

AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access

A successful response will yield an Access token which looks something like:

{"token_type":"Bearer","scope":"profile openid email 00000003-0000-0000-c000-000000000000/User.Read","expires_in":4728,"ext_expires_in":4728,"access_token":"eyJ0eXAiOiJKV1QiLCJub25jZSI6IkJTeXBHYnVFLTNNUXVTN2Rfb0tUa1ZMOHpfR2ZLVG1raTlrZjRlQm5VR1kiLCJhbGciOiJSUzI1NiIsIng1dCI6IjJaUXBKM1VwYmpB...

Why is ROPG bad

The reason basic authentication is bad is because PEOPLE. As an IT professional, how many times have you seen a password written on a Post It note stuck to a monitor, the bottom of a keyboard, or just on the whiteboard on the wall? Passwords are bad because they’re a single point of failure. Get the password and you’re in.

Nightmares of a suitably paranoid IT admin

Nobody ever should rely on just a single factor to get into mission critical resources in the cloud. Multi-factor authentication validates that the person authenticating has at least two things, something they know (a password) and something they have (a code from an authenticator, a physical token, or an attribute like a managed device).

A successful two factor authentication block

But, you said that we need ROPG

Right, because unlike a cloud based service, Jamf Connect runs on a single client machine. We are simply validating that the password on my MacBook Pro happens to match the password of the modern cloud identity provider.

In this scenario, we’re in a little island off on our own. We know the password matches, but the password is not useful to us as a bad guy because it’s just one of two or more things I would still need to get into a service.

Remember the ultimate goal of Jamf Connect is to make a local user account on a local macOS device running a flavor of UNIX with its 1970s era local user name and password and keep that password in sync with modern 2020s era cloud identity provider password. If Jamf Connect receives an access token when it does an ROPG request, it’s an access token for a non-existent cloud service, and totally useless. This is why Jamf Connect tosses the access token when it gets it.

“But you said the options are yes, no, and… other?”

Yes, No, and “I’m gonna need you to start up an interactive login and prompt that user for MFA” are the actual three responses. But, with those three responses we know if the password was right or wrong.

Let’s say that a conditional access policy applies to the Jamf Connect app and to get in everyone must use a second factor authentication method. This is great security for the macOS login page - to get into your Mac, you’ll need to know your password and have some second factor like Microsoft Authenticator, Okta Verify, Google Authenticator, a one time password sent via SMS, a Yubikey in TOTP mode, etc. When Jamf Connect does that interactive OIDC login, the user is prompted for a second factor. Yay.

Now, Jamf Connect needs to make sure it has the current password and that the current password is what the user has set for the local account password. Boom, ROPG time.

Jamf Connect walks into a bar and asks for a drink…

When MFA is enabled, it’s just like ANY interactive login. We send a user name, we send a password, and if and ONLY if that password is right, we’re asked to show ID and cough up the second form of authentication.

Except we don’t need the second form of authentication. We just want to know if that 1970s UNIX password is the 2020s cloud identity password. That’s it. We abandon the login attempt because we got what we needed.

But I have all these failures in my IDP logs now…

And we have a plan for that. Failed MFA attempts may result in the identity provider locking out the user or marking the user as having “risky” logins. We mitigate that by only checking the password at login and by default every 60 minutes with the menu bar application.

And, if you’re using Microsoft Azure Active Directory as your source of cloud identity, we have more ways to eliminate the failures in your logs completely. Visit https://www.jamf.com/blog/how-to-azure-conditional-access-and-jamf-connect/ for more details.

I still can’t trust this ROPG thing

If you have MFA enabled, then ROPG will never result in anything that could access any service. Try it right now. Really. Stop reading this blog article, pop open a new web browser or tab. Go log into something that has mandatory multi-factor authentication - go to your bank website. Type in your user name. Type your password wrong. Did you get prompted for MFA? Nope. No access. Type your password right. Are you prompted for MFA? Now don’t do anything. Don’t do that MFA request. Let it sit there. Does the login timeout? Yep. No access.

In summary, a non-interactive ROPG password check is the same as anyone logging into any service on the web. If you have MFA enabled and you don’t have your second factor, you get nothing. And any good identity provider will lock a user account if someone is trying to use the ROPG endpoint to brute force a password - EXACTLY the same thing if you were to log into your bank website with a bunch of bad passwords.

Don’t use ROPG to access web resources.

Don’t worry about ROPG to keep a password in sync.

Oh, and PS. If you ever bound your Mac fleet to on-premises Active Directory, guess what the authentication method was for that login…. Yep, you guessed it. Simple, basic auth, also known as the Resource Owner Password flow. Sleep safe tonight knowing ROPG can’t hurt you here.