Touristd and paresecd want to use your confidential information....

[roiegat]

So recently with 10.13.4 rolling out we've noticed more users getting the error,
"touristd wants to use your confidential information stored in "http-proxy(ID)" in your keychain"

and

"parsecd wants to use your confidential information stored in "http-proxy(ID)" in your keychain"

Even though they put their info in and click on "always allow" it keeps popping up. I've been trying to figure out what these actually do. Seems like one is used for notification when a new OS is installed. Any way to stop these from popping up and annoying my users? Anyone else seeing this in High Sierra?

[L-plateAdmin]

Yes we have, goole search says its spotlight related so it might calm down with use but its always going into the login keychain to get proxy info....

[L-plateAdmin]

yep after some research its all over the webs about the always allow setting not working, so how to do it via script...

So basically, the only think I can think of doing is allowing parsecd as one of the allowed apps that does have to ask, as its a internal apple framework binary. I don't think it causes much of a security issue

security add-internet-password -a '$3' -s "$proxy" -P 80 -r htps -T "/System/Library/PrivateFrameworks/CoreParsec.framework/parsecd" -U /Users/$3/Library/Keychains/login.keychain

problem its the -U is supposed to modify if it can find it but it just keeps on adding, this is the the only way I can think it can work as I doubt you can pipe find-internet-password.

anyone better at this then me????

[franton]

touristd is related to the "Would you like to take a tour of macOS?" so I'm not surprised it's trying to phone Apple.
parsecd is indeed related to Spotlight. Specifically suggestions whenever you are typing.

Neither are anything to worry about.

[roiegat]

Yeah still having the issues. Will try the script and see if it helps.

UPDATE: script didn't seem to fix the issue. Will keep looking.

[ekrasotkin]

Проблема решается путем настройки в программе "Связка ключей" в объекте "Вход" в списке связок ключей слева. Здесь нужно выбрать запись настройки прокси-сервера для протокола HTTP или HTTPS, которые формируются в вашей учетной записи при настройке сетевого интерфейса Ethernet и сохраняются здесь, в Связке ключей.
Открыть свойства записи и перейти на страницу "Доступ" со страницы "Атрибуты". Здесь выбрать один из вариантов предоставления доступа. Можно выбрать "Разрешить всем программам получать доступ к этом объекту", если нет необходимости ограничивать какие либо приложения.

Так была решена проблема для процессов parsecd, touristd, Kaspersky Anti-Virus Agent и AuthBrokerAgent в ОС "macOS High Sierra"

[ekrasotkin]

1. Open the "Keychain Access" program, select the entry "Login" in the list of keychains.
2. Select your proxy server record for the appropriate HTTP or HTTPS protocol. These two records are generated in your account when setting up the Ethernet network interface.
3. Open the properties of the entry and go to the "Access" page from the "Attributes" page. Here, choose one of the options for granting access. You can select "Allow all programs to access this object", if there is no need to restrict any applications. This solved the problem for processes such as parsecd, touristd, Kaspersky Anti-Virus Agent and AuthBrokerAgent in the OS "macOS High Sierra"

[L-plateAdmin]

@ekrasotkin Agreed, this is how to achive it manually, however a lot of our mac users are not experienced with advance keychain workings so that is why I am trying to script it. going to give it another bash later on.

[L-plateAdmin]

Well i have just upraded to 10.13.6 and after this update it seems to be behaving itself now. can anyone else verify??

[pberndt]

Has anyone found a fix to this? We are getting these password/Keycahin requests in MacOS versions 10.13.4, 10.13.5 and 10.13.6

[EUC600]

We are seeing the parsecd problem as well. Haven't been able to find a solution yet. It seems like it's a lot less frequent when Safari and other Apple applications are closed and other browsers are used instead.

But that isn't a solution. I'd hate to have to tell our users to stop using Safari when they may prefer it.

[roiegat]

We're seeing both issues here. I have two separate cases with Apple about it. The touristd one got escalated since other companies are seeing it. The Parsecd one we're collecting more info on. Will see if Apple comes back with something.

[d_mccullough]

@roiegat , please do!

[roiegat]

@d.mccullough Still waiting to hear back from Apple. I sent them about 6 gigs of Wireshark data so they have plenty to sift through. I'm going to set up bi-weekly meetings with our Apple rep to check in on cases so I'll see if I can get an update soon.

[d_mccullough]

Roie, I can confirm that upgrading my own work machine to Mojave has resolved the issue. Might be more trouble than it's worth, but let's see what Apple says.

[LaMantia]

Any updates? I am on 10.14.2 and still have issues with with touristd asking for creds and forcing proxy prompts. Using the manual approach from ekrasotkin has not worked for me. It will still prompt even if I grant access in the keychain.

[roiegat]

Nothing new from Apple. They are still analyzing all the data we gave them.

[digitc6mdm]

Hi. Does anyone have any updates regarding this issue?

[roiegat]

So no new news in Mojave but Apple said the issue should be fixed in Catalina. They are having me test that now. But they did have me try the following command to see if it'll work:

defaults write com.apple.touristd allowQAPaths -bool no

[d_mccullough]

I suppose "fixed in Catalina" will be the best we're going to get... at least it's a resolution.