Skip to main content
Solved

jamf connect - wrong password window


BookMac
Forum|alt.badge.img+9

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

Best answer by junjishimazaki

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

View original
Did this topic help you find an answer to your question?

10 replies

mickl089
Forum|alt.badge.img+11
  • Valued Contributor
  • 147 replies
  • November 16, 2021

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
Forum|alt.badge.img+9
  • Author
  • Jamf Heroes
  • 72 replies
  • November 16, 2021
mickl089 wrote:

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.


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


junjishimazaki
Forum|alt.badge.img+10
  • New Contributor
  • 423 replies
  • Answer
  • November 16, 2021

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


Forum|alt.badge.img+7
  • Contributor
  • 31 replies
  • November 16, 2021

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.


Forum|alt.badge.img+19
  • Honored Contributor
  • 582 replies
  • November 16, 2021

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
Forum|alt.badge.img+9
  • Author
  • Jamf Heroes
  • 72 replies
  • November 17, 2021
junjishimazaki wrote:

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


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.


BookMac
Forum|alt.badge.img+9
  • Author
  • Jamf Heroes
  • 72 replies
  • November 17, 2021
fdeltesta wrote:

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.


thanks a lot. that was also really helpfull!


BookMac
Forum|alt.badge.img+9
  • Author
  • Jamf Heroes
  • 72 replies
  • November 17, 2021
Tribruin wrote:

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. 


also thank you for the detailed explanation. 

we ❤️ jamf and the community!


ptrondsen-mgni
Forum|alt.badge.img+1
Tribruin wrote:

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. 


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?


Forum|alt.badge.img+19
  • Honored Contributor
  • 582 replies
  • February 9, 2022
ptrondsen-mgni wrote:

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?


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. 


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings