Skip to main content

Edited 4SEPT2024: Updated information with the release of Jamf Pro 11.9 for PSSO and Device Compliance.  Also added link to Jamf Pro documentation.


Jamf Learning Hub Instructions:


https://learn.jamf.com/en-US/bundle/technical-articles/page/Platform_SSO_for_Microsoft_Entra_ID.html


Current Public Preview Limitations




What is Public Preview



As of 15 JUL 2024, Microsoft Entra ID support for Platform Single Sign-On extension (PSSOe) is currently in Public Preview. As such, supported features and deployment information is subject to change without notice.  For more information, visit https://learn.microsoft.com/en-us/entra/fundamentals/licensing-preview-info. 

 


Jamf Pro and Microsoft Entra Conditional Access



Jamf Pro 11.9 and greater now includes logic to detects changes to PSSO registration.  When a new device ID is created in Entra ID as part of the registration, the gatherAADInfo command will report device compliance state to the new object.

 

For versions prior to Jamf Pro 11.9, visit the Troubleshooting Steps for commands to restore device compliance data being sent to the new device ID created in Entra ID manually.

 

Administrators are recommended to:


  1. Configure Jamf Pro for Device Compliance - https://learn.jamf.com/en-US/bundle/technical-paper-microsoft-intune-current/page/Device_Compliance_with_Microsoft_Intune_and_Jamf_Pro.html

  2. Configure Jamf Pro to deploy a Platform Single Sign-On configuration profile


With this method, when a user registers a device with the Platform Single Sign-On flow, the device compliance will automatically be sent to Entra.


In the event that an organization deploys PSSO first and then later configures and deploys Device Compliance, the user must run the "Register Device with Microsoft" policy from Jamf Self Service or the administrator must deploy a policy to run the gatherAADInfo command at least once before device compliance will be reported.



Prepare a non-production test machine



Any experimentation with the login window has the potential to lock a user out of their machine.  Therefore, use only non-production test equipment when testing and evaluating PSSOe.


Support



PSSOe is a framework built into macOS and the core functionality is designed by Apple.  It is supported by a companion application built by an identity provider.  It is enabled by deploying a configuration profile via an MDM.

 




Deployment




Determine authentication method




 

Microsoft Entra ID supports three methods of authentication with PSSOe:

 


  1. Secure Enclave (Recommended) - This method creates hardware bound cryptographic keys entangled with the Secure Enclave (link:https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/protecting_keys_with_the_secure_enclave) of the Mac hardware.  Keys are not directly accessible by the user, do not store keys in the user’s Keychain, and are non-exportable.  This method is recommended as it is treated by Microsoft Entra ID as a non-phishable authentication method, the strongest authentication factor type for accessing resources.  The local UNIX user name and password are unchanged with this method.

  2. Password - This method will synchronize the local macOS UNIX user account password with the Microsoft Entra ID password.  The user FileVault decryption password and Keychain password are updated to match the local UNIX account password.


    1. This is not considered a phishing resistant authentication factor.  Setup does not require the use of a strong authentication method like multifactor authentication, and the method does not allow for use of the device as a Passkey for WebAuthN authentication.  

    2. Administrators are strongly recommended to check all password complexity requirements in Microsoft Entra ID and password complexity configuration profile payloads passed via MDM.  Conflicting complexity requirements or policies like preventing the use of previously used passwords will result in user lockout of the device.  

    3. Legacy per-user multifactor authentication is not supported with this method and will result in the user being unable to register their account for use with PSSOe.  Refer to https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage for deprecation dates and how to migrate to Microsoft Entra Conditional Access policies for MFA enforcement.


  3. SmartCard - Associates a user’s SmartCard (also known as PIV or CAC card) and PIN with Microsoft Entra ID authentication methods.  The local UNIX user name and password are unchanged with this method.  Because this method requires additional hardware for both the credential storage and readers for the credentials, administrators are not advised to use this method unless SmartCards are already in use at the organization.



Install the Company Portal app



PSSOe requires the installation of Microsoft Intune Company Portal app (https://go.microsoft.com/fwlink/?linkid=853070) version 5.2404.0 or greater.

 

Install Company Portal via Policy

Open the Jamf Pro administrator portal.

Navigate to Settings, Computer Management, Packages.

Upload the latest version of Microsoft Intune Company Portal installer package file to your fileshare distribution point.

Navigate to Computers, Policies.

Create a new policy with an Execution Frequency set to Once Per Computer, a Packages payload to install the Microsoft Intune Company Portal package, and a Maintenance payload to Update Inventory.  Execution trigger can be set to Recurring Check-In or installed via Self Service by the user on the device.

 

Install Company Portal via Jamf App Catalog

Open the Jamf Pro administrator portal.

Navigate to Computers, Mac Apps.

Select the “+ New” option to create a new app installer.

Select App Source as the Jamf App Catalog.

Search for “Microsoft Intune Company Portal” and select the Add button to add the title.

Select a Target Group to deploy the application.

In the Configuration Settings option, select either to install automatically or via Self Service.  Select the Update method to Automatic if you wish to keep the Company Portal app up to date with the latest version automatically.

 

Once the installation method is configured, install the Company Portal application on your non-production test device.


Create a configuration profile



Open the Jamf Pro administrator portal.

Navigate to Computers, Configuration Profiles.

Select the “+ New” option to create a new Configuration Profile.

 

Select the payload for “Single Sign-On Extensions” and select the “+ New” option to add payload contents.


  • Payload Type: SSO

  • Extension Identifier: com.microsoft.CompanyPortalMac.ssoextension

  • Team Identifier: UBF8T346G9

  • Sign-on Type: Redirect

  • URLs:  URLs will be redirected to authenticate with the associated application (Intune Company Portal app).  For a full list of URLs, refer to https://learn.microsoft.com/en-us/entra/identity-platform/apple-sso-plugin and are subject to change.  At time of writing the minimum required URLs were:



  • Enable the option for “Use Platform SSO”

  • Select the Authentication Method your organization has selected

  • Use Shared Device Keys: Enable

  • (OPTIONAL) Create New User at Login


    • Selecting Enable will allow any user with valid credentials on your Entra ID domain to create a new user account on the Mac.  A local macOS UNIX user account will be created with the user’s Entra ID password.  Users with “passwordless” only authentication in Entra ID cannot use this method.


  • (OPTIONAL) Identity Provider Authorization


    • Selecting Enable will allow the use of Entra ID credentials for events that require authorization prompts like use of the sudo command, unlocking certain preferences in System Settings, and installation of software.  The user must have administrator rights in addition to complete authorization.


  • Display Account Name: Enter a value that will be clear to your end users what user name and password is required upon registration of the device with PSSOe.  These dialog boxes are displayed by macOS to prompt the user as part of the registration process.

  • User Mapping - name from the identity provider ID token claim that contains the information to create the user account


  • Account authorization type: Determines if entry of identity provider credentials during an authorization event will show the user is a member of the Admin or Standard users group.  Select either Standard or Admin.  (Groups is not supported by Microsoft Entra ID at this time).

  • New user account type: Determines if a user created at the macOS login window with identity provider credentials will be a local Admin or Standard account.  Select either Standard or Admin.  (Groups is not supported by Microsoft Entra ID at this time).

  • Authentication when screen is locked: Set to Do not handle

  • (OPTIONAL) Custom Configuration: Microsoft Entra ID supports several additional configuration settings.  Refer to https://learn.microsoft.com/en-us/entra/identity-platform/apple-sso-plugin#manual-configuration-for-other-mdm-services for a full list of settings.  


 

A standard Custom Configuration payload may look like the following:

<?xml version="1.0" encoding="UTF-8"?>

<plist version="1.0">

<dict>

    <key>AppPrefixAllowList</key>

    <string>com.microsoft.,com.apple.,com.jamf.trust,com.jamf.management.,com.jamf.protect,com.jamfsoftware.</string>

    <key>browser_sso_interaction_enabled</key>

    <integer>1</integer>

    <key>disable_explicit_app_prompt</key>

    <integer>1</integer>

</dict>

</plist>

 

Scope the Configuration Profile to your non-production test devices.

 



 



@rabbitt - I'm going to go ahead and get this out of the way - We still AD Bind.   (hangs head in shame).


But, I've been looking to convince management to get away from this for a while.  After JNUC and hearing your session (awesome session BTW), management decided to get some Jamf Connect licenses and start looking at PSSOe.  The problem I'm running into is that we seem dead set on not allowing just anyone the capability to register in Entra.  We have it restricted to a small group of employees.  That means I'll have to touch every single machine.
Do you have any advice on how I can accomplish this easily or how to convince management to open it up?  Their concern is that we've had a bunch of personal devices register in our tenant and this was presented as the way to stop that.

Thanks!

Has anyone ran into an issue with Microsoft apps constantly asking to be logged into again? It seems like everything is talking correctly, as logging into the Mac uses the Entra ID password credentials, but all the Microsoft applications (Teams, Edge, OneDrive, etc.) keep logging out and ask to be logged into again frequently throughout the day. I feel like I'm missing something, but can't figure it out.


Check your Entra Conditional Access policies around session duration.  Also this is one where getting MS support in is 1000% the right answer.  You're paying them for the service, so... :) 

only Question, once enabled PSSOe, why certificate removes from keychain, we know this specific certificate will help to access intranet site. we have compared 2 macs, one with PSSOe and another without PSSOe enabled. Once PSSOe registration completed, MS workplace join key (Private key) removes and not blocks the intranet access. 


With PSSO in Secure Enclave key authentication mode, the workspace join certificates are removed from the user's keychain and stored instead in the Secure Enclave of the device.  This effectively makes the key non-exportable and hardware bound.  The workspace join key should not be relied on for things like network access.

I have an issue where, after authenticating with the company portal, I see the "MS-Organization-Access" certificate in the user's keychain, but it is not trusted. Is it necessary to trust this certificate, and will it cause any issues if it remains untrusted? How can I trust that certificate, and is there a root CA required for it to be trusted?


If you're using PSSO with Microsoft in Secure Enclave key authentication mode, there should be no MS-Organization-Access certificate in the user keychain at all, so I'm confused by the question.

@rabbitt - I'm going to go ahead and get this out of the way - We still AD Bind.   (hangs head in shame).


But, I've been looking to convince management to get away from this for a while.  After JNUC and hearing your session (awesome session BTW), management decided to get some Jamf Connect licenses and start looking at PSSOe.  The problem I'm running into is that we seem dead set on not allowing just anyone the capability to register in Entra.  We have it restricted to a small group of employees.  That means I'll have to touch every single machine.
Do you have any advice on how I can accomplish this easily or how to convince management to open it up?  Their concern is that we've had a bunch of personal devices register in our tenant and this was presented as the way to stop that.

Thanks!


I think you less have an issue with registering devices in Entra as much as registering personal devices into Jamf Pro.  The PSSO payload needs to come down from an MDM here to work, so we know the device would be enrolled in Pro.  Perhaps limit registration of devices to only those coming through Apple Business Manager?  Perhaps add in the (in private beta preview, so talk to your Jamf AE) Network Relay with an ACME certificate new to Jamf Connect ZTNA.  That would give you a machine authenticity attestation from Apple with the ACME cert to prevent serial number spoofing.

I think you less have an issue with registering devices in Entra as much as registering personal devices into Jamf Pro.  The PSSO payload needs to come down from an MDM here to work, so we know the device would be enrolled in Pro.  Perhaps limit registration of devices to only those coming through Apple Business Manager?  Perhaps add in the (in private beta preview, so talk to your Jamf AE) Network Relay with an ACME certificate new to Jamf Connect ZTNA.  That would give you a machine authenticity attestation from Apple with the ACME cert to prevent serial number spoofing.


I'm not sure I exactly follow.  We have zero Jamf Cloud BYOD, so that's not an issue.  Everything is ASM and PreStage.  However, we have so many personal devices showing up in Entra that management is pulling everything back to try to stop devices from registering with our tenant.

I'm not sure I exactly follow.  We have zero Jamf Cloud BYOD, so that's not an issue.  Everything is ASM and PreStage.  However, we have so many personal devices showing up in Entra that management is pulling everything back to try to stop devices from registering with our tenant.


Running into the same limitation as you-- there doesn't seem to be a way to automate registering these devices using Jamf, so to register them, the user has to have permission to join devices to Entra-- which includes personal windows devices, which don't need anything pushed from an MDM to join. If you find a solution to this I'll be curious to know as our org is in the same boat right now. 

@rabbitt , thanks for posting this very helpful information.
We are facing some similar inconsistencies with our test deployment of PSSOe with password sync on Jamf Pro Cloud 11.10.1-t1728656858, using Company Portal Version: 5.2409.1 (53.2409926.002) and a signed config profile created in iMazing. We were experiencing some issues with the profile created in the Jamf UI, the session duration key value was being manipulated so, we went to a signed profile and didn't set that value, taking the default. We've still been experiencing what I would call a "drift" where, initially, things seem to work fine. After logging in, SSO works and the tokens are read, website and apps seamlessly connect as expected. Then after a few days or so, it may start with Teams displaying a banner that you need to sign in. Other sites that were previously, silently passing the SSO token, were prompting for login credentials and MFA. Our testing with SecureEnclave was must smoother but, due to our environment and culture at the time we have to start with password sync. I've tried to capture some logs using unified logging and some predicates but, I'm not sure what's "normal noise" or what's actually an error. Additionally, a line in the output of the app-sso platform -s command has been getting my attention but, I'm not sure if it's actually an error or if it's just describing what would be output in the event of that type of error. Under the "Login Configuration" section there is a key-value pair with the following:


"invalidCredentialPredicate" : "error = 'invalid_grant' AND suberror != 'device_authentication_failed'",


 


1. Any thoughts on the "drift" for Microsoft applications and sites that were previously taking SSO tokens prompting for credentials? (I saw your response to "wlumley" and we'll be checking with our Identity & Access folks regarding a conditional access policy if it exists or not.


2. Do you know of any good log predicates that may be of value to stream or look up when troubleshooting PSSOe w/ password sync?

3. Have you heard of or had any experiences with the Jamf UI when creating config profiles changing some values of the keys?


I think this particular one should have the wording changed and that might fix the issue since the key takes seconds but, the interface uses



resulted in:



So, the value entered in the UI was multiplied by 3600. The UI should say to enter the number of hours but, we got an error when entering "1". After this we didn't populate that key but, it still did not affect the issues we've been experiencing.


 

@rabbitt , thanks for posting this very helpful information.
We are facing some similar inconsistencies with our test deployment of PSSOe with password sync on Jamf Pro Cloud 11.10.1-t1728656858, using Company Portal Version: 5.2409.1 (53.2409926.002) and a signed config profile created in iMazing. We were experiencing some issues with the profile created in the Jamf UI, the session duration key value was being manipulated so, we went to a signed profile and didn't set that value, taking the default. We've still been experiencing what I would call a "drift" where, initially, things seem to work fine. After logging in, SSO works and the tokens are read, website and apps seamlessly connect as expected. Then after a few days or so, it may start with Teams displaying a banner that you need to sign in. Other sites that were previously, silently passing the SSO token, were prompting for login credentials and MFA. Our testing with SecureEnclave was must smoother but, due to our environment and culture at the time we have to start with password sync. I've tried to capture some logs using unified logging and some predicates but, I'm not sure what's "normal noise" or what's actually an error. Additionally, a line in the output of the app-sso platform -s command has been getting my attention but, I'm not sure if it's actually an error or if it's just describing what would be output in the event of that type of error. Under the "Login Configuration" section there is a key-value pair with the following:


"invalidCredentialPredicate" : "error = 'invalid_grant' AND suberror != 'device_authentication_failed'",


 


1. Any thoughts on the "drift" for Microsoft applications and sites that were previously taking SSO tokens prompting for credentials? (I saw your response to "wlumley" and we'll be checking with our Identity & Access folks regarding a conditional access policy if it exists or not.


2. Do you know of any good log predicates that may be of value to stream or look up when troubleshooting PSSOe w/ password sync?

3. Have you heard of or had any experiences with the Jamf UI when creating config profiles changing some values of the keys?


I think this particular one should have the wording changed and that might fix the issue since the key takes seconds but, the interface uses



resulted in:



So, the value entered in the UI was multiplied by 3600. The UI should say to enter the number of hours but, we got an error when entering "1". After this we didn't populate that key but, it still did not affect the issues we've been experiencing.


 


Forgot to post:
Here's what our current config looks like on the device:



 

Also, replace "session duration key" with "login frequency" woops.

@rabbitt , thanks for posting this very helpful information.
We are facing some similar inconsistencies with our test deployment of PSSOe with password sync on Jamf Pro Cloud 11.10.1-t1728656858, using Company Portal Version: 5.2409.1 (53.2409926.002) and a signed config profile created in iMazing. We were experiencing some issues with the profile created in the Jamf UI, the session duration key value was being manipulated so, we went to a signed profile and didn't set that value, taking the default. We've still been experiencing what I would call a "drift" where, initially, things seem to work fine. After logging in, SSO works and the tokens are read, website and apps seamlessly connect as expected. Then after a few days or so, it may start with Teams displaying a banner that you need to sign in. Other sites that were previously, silently passing the SSO token, were prompting for login credentials and MFA. Our testing with SecureEnclave was must smoother but, due to our environment and culture at the time we have to start with password sync. I've tried to capture some logs using unified logging and some predicates but, I'm not sure what's "normal noise" or what's actually an error. Additionally, a line in the output of the app-sso platform -s command has been getting my attention but, I'm not sure if it's actually an error or if it's just describing what would be output in the event of that type of error. Under the "Login Configuration" section there is a key-value pair with the following:


"invalidCredentialPredicate" : "error = 'invalid_grant' AND suberror != 'device_authentication_failed'",


 


1. Any thoughts on the "drift" for Microsoft applications and sites that were previously taking SSO tokens prompting for credentials? (I saw your response to "wlumley" and we'll be checking with our Identity & Access folks regarding a conditional access policy if it exists or not.


2. Do you know of any good log predicates that may be of value to stream or look up when troubleshooting PSSOe w/ password sync?

3. Have you heard of or had any experiences with the Jamf UI when creating config profiles changing some values of the keys?


I think this particular one should have the wording changed and that might fix the issue since the key takes seconds but, the interface uses



resulted in:



So, the value entered in the UI was multiplied by 3600. The UI should say to enter the number of hours but, we got an error when entering "1". After this we didn't populate that key but, it still did not affect the issues we've been experiencing.


 


Also observed the banner for Teams asking to sign in again. Saw earlier this week, but not today. Maybe an update or something came out for Teams.

Also observed the banner for Teams asking to sign in again. Saw earlier this week, but not today. Maybe an update or something came out for Teams.


¯\\_(ツ)_/¯ I had been trying to find a log from Teams that even displayed the banner's text with a timestamp, to attempt to correlate it with some other events but, I was unsuccessful.

We've decided to switch to SecureEnclave. During my journey down the rabbit hole of Platform SSO logs I came up with a few variations on a predicate that gave some insight into the problem.



Silent token refresh attempt results
log show --style compact --predicate '(subsystem contains [c] "AppSSO Extensi" or subsystem contains [c] "com.microsoft.ssoextension" or subsystem = "com.apple.AppSSO") and (eventMessage contains "_finishAuthorization:withCompletion:" or eventMessage contains "authorization:didCompleteWithError:")' --debug --info


You can play with variations on this predicate to see some interesting things. The subsystems listed were the ones I found mostly related to SSO. I also looked at keychain and device unlock logs with variations on this predicate. I was able to compare my experience on an Intune managed device running password sync vs our Jamf managed devices. The Jamf implementation at this time seems to have some bugs around the silent refresh. Not surprisingly, the Intune implementation for both password sync and SecureEnclave were both smooth.


The above predicate only showed successful results on my Intune managed device.

when we tried to use smart card method we are getting below error but we are trying to use Yubikey as smart card, why it is not detecting.


@rabbitt I followed the steps in this article to get PSSO working with the device compliance integration with Azure. Everything goes smoothly, but after registering the device with Azure I do not see the compliant attribute update in Azure.  When I run the gatherAADInfo command I receive a message that states No Azure tenant setup.  When I check the com.jamfsoftware.jamf.plist file I can see no Azure info is present.  At the recommendation of another user on JamfNation I ran sudo jamf manage.  Once I did this all the Azure info populated in the Jamf preference file. I then ran the gatherAADInfo command again and it ran properly and sent the compliance info to Azure. I thought this may have been a fluke so I setup another device and experienced the same results.  It appears I can only get device compliance to work by manually running sudo jamf manage and gatherAADInfo. My workflow to setup a test device is as follows:



  1. Install macOS and all applicable apps on a new device, including Company Portal v5.24.09.1

  2. The device is enrolled in Jamf using a Prestage (Jamf Pro v11.10.2)

  3. Once enrolled all profiles are installed including the PSSO profile, using Secure Enclave as the authentication  method

  4. I login to the device as the test user.  FileVault is enabled and proceeds to the Desktop where I receive a notification to register the device with Azure

  5. I complete the steps to register with Azure. Once complete I verify PSSO is enabled by checking System Settings > Users & Groups. Registration and Tokens are both good and the Mac SSO Extension reports as registered.

  6. After waiting a while to see if device compliance is reported to Azure I check the Jamf preference file and see no Azure Info.

  7. I manually run sudo jamf manage and gatherAADInfo

  8. Device compliance is reported


Am I missing a step in my workflow to make device compliance work on its own?

Has anyone come across the macOS notification ignoring the Display Account Name value?

I have PlatformSSO working and can register fine but only Teams, OneDrive and Edge seem to work with the SSO. Outlook, word etc all need manual log in still. Am I missing something in the setup?

I have PlatformSSO working and can register fine but only Teams, OneDrive and Edge seem to work with the SSO. Outlook, word etc all need manual log in still. Am I missing something in the setup?


Nope, you’re not missing anything. Not every application will work with single sign-on extensions. You should contact Microsoft for additional support. With the Outlook ant Word apps you mentioned, the user should still need to enter a user name, but the SSOe should handle the actual login process. Just an oddity of how they implemented their login.
Nope, you’re not missing anything. Not every application will work with single sign-on extensions. You should contact Microsoft for additional support. With the Outlook ant Word apps you mentioned, the user should still need to enter a user name, but the SSOe should handle the actual login process. Just an oddity of how they implemented their login.

Awesome! Thought I had missed something so glad to hear I wasn't going mad! Thanks!

PSSO configuration profile is working but I have not has sucess in using the 


Administrator Groups.  I have added my azure ID group for
Administrator Groups but when log in an create a group with an account in that group it  is creates as a standard user.

 

The same result using Additional Groups to allow users in the specified group to log in and create account as standard users, It seem as users can log in even if they are not in the group used in the Additional Groups.  Am I missing somthing? Should this work?


 

PSSO configuration profile is working but I have not has sucess in using the 


Administrator Groups.  I have added my azure ID group for
Administrator Groups but when log in an create a group with an account in that group it  is creates as a standard user.

 

The same result using Additional Groups to allow users in the specified group to log in and create account as standard users, It seem as users can log in even if they are not in the group used in the Additional Groups.  Am I missing somthing? Should this work?


 


At this time, keys that are not explicitly called out to be set in the configuration profile are not supported by Microsoft.  For privilege access management, I would highly recommend using a tool like Jamf Connect or the SAP-Enterprise-Privileges app.

At this time, keys that are not explicitly called out to be set in the configuration profile are not supported by Microsoft.  For privilege access management, I would highly recommend using a tool like Jamf Connect or the SAP-Enterprise-Privileges app.


Oh,  I'm not able to deploy this if I can not restrict workstation logins to departmantal group members.  Giving the entire University access to to our devises is not a risk we can accept.  I will re-address the posibility of Purchasing Jamf Connect but I'm guessing we will be stuck with binding to AD untill microsoft updates the Company portal to address these keys.

We are testing the PSSO with the Secure Enclave method.


When setting the Account Authorization Type as Standard in the PSSO configuration, we've observed that post-registration, Mac local user accounts with Admin access are downgraded to Standard user accounts.


Conversely, when utilizing Account Authorization Type as Admin in the PSSO configuration, we've noted that post-registration, Mac local user accounts with Standard access are elevated to Admin accounts.


wherein user accounts are not inadvertently changed from Admin to Standard or vice versa. any hints on this?

I'm still just testing for now, but so far, this seems to work well for us. We are using the password option. We want to synchronize the Mac local login password with Microsoft Entra ID. Does anyone know if users receive an alert when their password is nearing expiration? Our current in production SSO extension does this and there's an option from the menubar to change the password. For this solutiong using the Company Portal app, there is no menubar app.

I'm still just testing for now, but so far, this seems to work well for us. We are using the password option. We want to synchronize the Mac local login password with Microsoft Entra ID. Does anyone know if users receive an alert when their password is nearing expiration? Our current in production SSO extension does this and there's an option from the menubar to change the password. For this solutiong using the Company Portal app, there is no menubar app.


Do people receive an alert: Nope.  In fact, it is possible a user may need to change their password if expired on a second device before getting into the Mac.  If you're enforcing passwords and there's a network connection, you could lock users out of their Macs in all new and interesting ways.  (I'd recommend not deploying the password sync without a grace period config on Sequoia.)


Your prod option is grabbing the password expiration from the domain controller via a Kerberos ticket.  Depending on your IDPs configuration, it could be cloud based (IDP knows when the password would expire, but there's no part of the OIDC spec to pass that info to the client device), or it could be mastered by another IDP or an on-premises AD.  In that case, the cloud IDP has no idea when the password expires and can't pass the info along.


feedbackassistant.apple.com will be your friend here. :) 

Reply


Terms & ConditionsCookie settings