jamf connect - wrong password window

[BookMac]

Hello folks,

We currently have the problem that when we change the password via jamf connect we do not always get the correct password change window. This is how it should look right:

and this is how it feels 50% of all cases.

We are currently using jamf connect 2.3.2

If I briefly disconnect and reconnect the active network connection in the settings, I get the correct window.

Does anyone have any suggestions?

Cheers

[junjishimazaki · Accepted solution]

Hi BookMac, NoMAD does have a similar password change window since they bought the NoMAD company. As for that window, I found the jamf admin guide about it so I hope this answers your question. https://docs.jamf.com/jamf-connect/2.6.0/documentation/Password_Changes.html#ID-00006b62

[fdeltesta · Accepted solution]

Hello,

I actually encountered the same behavior.
We're using Okta as IDP which as its users heritated from an Active Directory.
If you have setup the Jamf Connect Menu Bar app to connect to the AD domain, it tries to get a Kerberos ticket. (The "Kerberos Preferences" section)
If the mac manage to get one, then you will always have that unwanted window.
On the other hand if there's no kerberos tickets, you will get your IDP's window.
So if Kerberos is not needed, try removing these parameters and try again.

Here's some commands to help you troubleshoot this:
- klist Will list every Kerberos ticket your mac has.
- kdestroy -a will destroy every kerberos tickets your mac has.

This is only from my experience, but maybe this is caused by something else than Kerberos.
And I'm not an expert with Jamf Connect, and even less an expert in Kerberos.

Hope it helps.

[mickl089]

Sieht mir sehr nach NoMad aus, das ist die kostenlose Alternative, haben wir im Einsatz.

---
Looks a lot like NoMad to me, that's the free alternative, we use that.

[BookMac]

We are not using NoMad, we have AzureAD. How the hell is he thinking that we are using NoMad?

[junjishimazaki · Accepted solution]

Hi BookMac, NoMAD does have a similar password change window since they bought the NoMAD company. As for that window, I found the jamf admin guide about it so I hope this answers your question. https://docs.jamf.com/jamf-connect/2.6.0/documentation/Password_Changes.html#ID-00006b62

[BookMac]

thx. that was a good link. it seems that we have both options configured in the config profile. kerberos and iDP. thats why we got both windows. we are blocking that users are able to change their password in system preferences - user & groups. so if the kerberos window appears the change doesn't work. i deleted the kerberos part in the config profile and i'm getting the iDP window only, right now.

[fdeltesta · Accepted solution]

Hello,

I actually encountered the same behavior.
We're using Okta as IDP which as its users heritated from an Active Directory.
If you have setup the Jamf Connect Menu Bar app to connect to the AD domain, it tries to get a Kerberos ticket. (The "Kerberos Preferences" section)
If the mac manage to get one, then you will always have that unwanted window.
On the other hand if there's no kerberos tickets, you will get your IDP's window.
So if Kerberos is not needed, try removing these parameters and try again.

Here's some commands to help you troubleshoot this:
- klist Will list every Kerberos ticket your mac has.
- kdestroy -a will destroy every kerberos tickets your mac has.

This is only from my experience, but maybe this is caused by something else than Kerberos.
And I'm not an expert with Jamf Connect, and even less an expert in Kerberos.

Hope it helps.

[BookMac]

thanks a lot. that was also really helpfull!

[Tribruin · Accepted solution]

This is expected behavior. I can assume that you have Kerberos setup on your Jamf Connect. If JC sees a Kerberos ticket, it will present the basic password change dialog box instead of the iDP box. 

In someways this can be a good thing. Using Kerberos (and AD) to change the password is much simpler for the user as both the AD and local password get changed at the same time. When you use the iDP change, you are changing your password only in the iDP. The user then gets prompted to login again and change their local password. 

But, from a user experience, it can be disconcerting to have two different work flows. There is an open FR to force a password change only through the iDP even if there is a Kerberos ticket. 

[BookMac]

also thank you for the detailed explanation. 

we ❤️ jamf and the community!

[ptrondsen-mgni]

Hi Tribruin, do you know if the open feature request was ever added to Jamf Connect to force a password change only through the iDP even if there is a Kerberos ticket?

[Tribruin]

i have not seen any change in the recent versions, so I am assuming that it hasn't been implemented.  I actually can't find the feature request anymore. 

In our environment, we are moving from Enterprise Connect, so having a similar workflow to EC is advantageous.