[GH-ISSUE #1306] [Feature] PAC file proxy auth (inc Jamf support) #1300

New issue

Open

opened 2026-03-03 19:50:13 +03:00 by kerem · 2 comments

kerem commented

2026-03-03 19:50:13 +03:00

Owner

Originally created by @rtfmoz2 on GitHub (Jul 24, 2022).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/1306

Originally assigned to: @NghiaTranUIT on GitHub.

Summary
PAC file proxy auth capability using provided credentials (typically AD) with option for using keychain for password (key icon next to pw field) so we can use credentials stored by Jamf Connect (Formerly NoMAD).

Implementation
One set of credentials (typically AD) can be specified for the PAC file as a username and password field. Next to the password field is a key icon. Clicking this brings up the dialogue to specify a keychain entry which the user selects and proxyman then tries to read the value and store a hash. Doing this triggers one-off MacOS keychain access prompts which the user should select always allow.

The PAC file is not modified. When proxyman encounters a 401 on the proxy connection it supplies the credentials stored locally or in the keychain case, the username locally and the password directly from the keychain value, updating its local hash as it does. If they fail, it marks the credentials as invalid so no other proxyman thread can use them. The main proxyman ui thread will updated the key icon when it sees this, such as overlaying a red circle with line through the key icon.

The user can unlock the failed password by changing it. In the case of the keychain the user can unlock by clicking the key icon (with a warning) however... the smart handling here is proxyman never stops reading the keychain value. Triggered by 401 authentication it reads the current value, computes the hash as normal but seeing it has been marked invalid will check if the hash value has changed before overwriting the old value. If changed it will attempt to use the new credentials once. If successful, mark it as valid and the processing is done. If not it will ignore the 401 response let go on it way back to the calling application.

Smart handling means proxyman can automatically detect and use any new user password as it is supplied directly from the keychain value. When it comes to invalid credential it wont cause user account lockouts because the first proxyman thread to encounter failed credentials will share that information so no other threads will attempt to authenticate using them. When the credentials are updated it will automatically detect, validate and use them without the need for any user intervention.

Benefits
Adding this feature allows proxyman to automatically pickup any password changes for the user via Jamf so they are never bothered again with proxy passwords. In a word, it's brilliant for Mac SOE enterprise deployments who want to utilise this product. Keep an eye out for other integration opportunities as well as there is more than one AD password management product for Mac environment.

Originally created by @rtfmoz2 on GitHub (Jul 24, 2022). Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/1306 Originally assigned to: @NghiaTranUIT on GitHub. **Summary** PAC file proxy auth capability using provided credentials (typically AD) with option for using keychain for password (key icon next to pw field) so we can use credentials stored by Jamf Connect (Formerly NoMAD). **Implementation** One set of credentials (typically AD) can be specified for the PAC file as a username and password field. Next to the password field is a key icon. Clicking this brings up the dialogue to specify a keychain entry which the user selects and proxyman then tries to read the value and store a hash. Doing this triggers one-off MacOS keychain access prompts which the user should select always allow. The PAC file is not modified. When proxyman encounters a 401 on the proxy connection it supplies the credentials stored locally or in the keychain case, the username locally and the password directly from the keychain value, updating its local hash as it does. If they fail, it marks the credentials as invalid so no other proxyman thread can use them. The main proxyman ui thread will updated the key icon when it sees this, such as overlaying a red circle with line through the key icon. The user can unlock the failed password by changing it. In the case of the keychain the user can unlock by clicking the key icon (with a warning) however... the smart handling here is proxyman _never stops_ reading the keychain value. Triggered by 401 authentication it reads the current value, computes the hash as normal but seeing it has been marked invalid will check if the hash value has changed before overwriting the old value. If changed it will attempt to use the new credentials once. If successful, mark it as valid and the processing is done. If not it will ignore the 401 response let go on it way back to the calling application. Smart handling means proxyman can automatically detect and use any new user password as it is supplied directly from the keychain value. When it comes to invalid credential it wont cause user account lockouts because the first proxyman thread to encounter failed credentials will share that information so no other threads will attempt to authenticate using them. When the credentials are updated it will automatically detect, validate and use them **_without the need for any user intervention._** **Benefits** Adding this feature allows proxyman to automatically pickup any password changes for the user via Jamf so they are never bothered again with proxy passwords. In a word, it's brilliant for Mac SOE enterprise deployments who want to utilise this product. Keep an eye out for other integration opportunities as well as there is more than one AD password management product for Mac environment.

kerem added the

Feature request

label

2026-03-03 19:50:13 +03:00

kerem commented

2026-03-03 19:50:14 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jul 24, 2022):

Thanks, for such a detailed feature request @rtfmoz2 🙇

As a previous conversation, I researched how to tackle this feature, but the effect is enormous and not suitable for the current milestone. I will add this feature to the backlog list and wait for my requests on this feature.

If it's good, our team would consider supporting it 👍

@NghiaTranUIT commented on GitHub (Jul 24, 2022): Thanks, for such a detailed feature request @rtfmoz2 🙇 As a previous conversation, I researched how to tackle this feature, but the effect is enormous and not suitable for the current milestone. I will add this feature to the backlog list and wait for my requests on this feature. If it's good, our team would consider supporting it 👍

kerem commented

2026-03-03 19:50:14 +03:00

Author

Owner

@rtfmoz2 commented on GitHub (Mar 3, 2023):

The password validation was just a concept. The above was an "ideal" scenario. You could do the check at the time of macOS proxy override instead. Then it can be far simpler to implement.

@rtfmoz2 commented on GitHub (Mar 3, 2023): The password validation was just a concept. The above was an "ideal" scenario. You could do the check at the time of macOS proxy override instead. Then it can be far simpler to implement.