Self Service failing on Network Accounts

Eigger
Contributor III

We are having trouble this year with our Self Service. We upgrade to JSS 9.92. When we log in as local admin user, we can install packages using self service. ut when we log in as a network user, Self Service opens, but is failing to install package. I receive Cannot Install Item, please contact your Administrator. Logs are not helpful, it just logs the exact error but no explanation. But I think it is failing to the point of Mounting the DP. I can access the DP using Command K and get to the Packages, copy it to the Desktop and install it no problem. But it wouldnt install on SS. Removed JamfFramework, no go, re image, still no good. We do not use JDS, just AFP DP. Please help.

Thanks,
Eigger

1 ACCEPTED SOLUTION

Eigger
Contributor III

The issue has been resolved after I unbind the server from the domain.

I do not know if the information sent to me by our TAM can fix our issue but I will share it anyways.
Please note I haven't tested this yet so I cannot confirm if this works.

She asked if we are using lower case in our AD. Yes we do use lower case.
So she advised to use "UPPER CASE" when logging in to Self Service as per Product Issue (PI-002648)

"Unfortunately, we don't have much additional information besides right now for other accounts also experiencing it. It is still in a testing phase to try and narrow down the exact cause or reason for the case sensitivity. Through testing, it has been confirmed on multiple occasions that by using capital letters, it allows policies to run successful.

I have linked our case to the open Product Issue (PI-002648), so the developers are aware. If you could also submit an updated JSS Summary, to attach to your account, which will list specifics about your environment. This should help narrow down if it is an environment issue."

View solution in original post

11 REPLIES 11

donmontalvo
Esteemed Contributor III

Can you post (a sanitized) /var/log/jamf.log so we can have an idea what's happening?

--
https://donmontalvo.com

donmontalvo
Esteemed Contributor III

Can you post a (sanitized) /var/log/jamf.log so we can see what's happening?

--
https://donmontalvo.com

ryanstayloradob
Contributor

Are your network users admins on the local machine, or standard accounts?

donmontalvo
Esteemed Contributor III

Hmmmm...check this out...

--
https://donmontalvo.com

Eigger
Contributor III

62bd1b8e98284543aab373084d8e88aa
cffbbb07089f4c2d86992b81f03b8562

I switch to SMB, and Self Service started working. I was happy for a moment there until I opened Casper Admin on my machine, now its my Casper Admin that couldn't mount the share.

Question: Do I need my machine running casper admin to join the domain to mount the share?

I revert back to afp, Casper Admin open, Self Service on the client breaks again.

Eigger
Contributor III

@ryanstayloradobe Our Teachers are Admins and Student are Standard account. It was working before, when we used to have 9.81

jonlju
Contributor

We have the share set up as smb as well, for me to be able to start Casper Admin and have the share mounted, I need to first mount the share (using CMD + K for example) and then start Casper Admin. It will however unmount it properly after exiting Casper Admin. Not sure why.

scottb
Honored Contributor

There was also something similar a while back where the JSS was trying to mount the SMB share using the TGT from the logged in user as opposed to the JSS SMB account(s).
I think that's why you can mount it manually @jonlju using Command-K.
When we use CasperAdmin now, we use a local admin account, and I don't see that issue or course.

You can try for fun to kill your TGT for the logged in network account first, then launch CasperAdmin. Does that work?

Eigger
Contributor III

What I am noticing in the logs is Self Service is logging in as the logged in user. Correct me if I'm wrong but doesnt it should use the credentials we put in the JSS?

Eigger
Contributor III

This is the logs from the DP. AFP Log below shows successful Self Service (When logged in as a Local Admin user)

cea4062ccc384a1fb5d3040785cc8336

This one below is Failed Self Service (When logged in as a Domain User)

bdcf5f03ccb84f59a7fad834d8f1b70b

Eigger
Contributor III

The issue has been resolved after I unbind the server from the domain.

I do not know if the information sent to me by our TAM can fix our issue but I will share it anyways.
Please note I haven't tested this yet so I cannot confirm if this works.

She asked if we are using lower case in our AD. Yes we do use lower case.
So she advised to use "UPPER CASE" when logging in to Self Service as per Product Issue (PI-002648)

"Unfortunately, we don't have much additional information besides right now for other accounts also experiencing it. It is still in a testing phase to try and narrow down the exact cause or reason for the case sensitivity. Through testing, it has been confirmed on multiple occasions that by using capital letters, it allows policies to run successful.

I have linked our case to the open Product Issue (PI-002648), so the developers are aware. If you could also submit an updated JSS Summary, to attach to your account, which will list specifics about your environment. This should help narrow down if it is an environment issue."