read access for everyone to Distribution Points

[marcusransom]

the Casper Administration Guide recommends that sharing permissions on Distribution Points be set for 'everyone' to 'read only'. Some of our more 'industrious' users appear to be mounting the distribution point and downloading DMGs to try and find serial numbers etc. and distribute them. Does anyone have any suggestions as to a way around this or the implications for setting the everyone permissions to 'none'?

regards

Marcus Ransom

[acdesigntech]

I would set everyone permissions to no access in addition to tracking access attempts and alerting your users that this information is being captured and reviewed, but thats just me. In short, setting everyone to no shouldnt negatively affect anything.

[CasperSally]

agreed with acdesign. As long as casperadmin acct is read/write and casperinstall is read only, you should be fine setting everyone to no access

[jarednichols]

From a security perspective, there's zero reason to have the CasperShare world-readable. I have two accounts on mine: one read-write and one read-only. In fact, if I were to have the 'everyone' group defined with any sort of read access, our security controls would shoot the file share in the head and disable it.

[nkalister]

if your servers and clients are all talking to the same KDC and clients are getting valid kerberos tickets, the kerberos credentials for their login will be used to mount the share instead of the casperinstall account. in that scenario removing read access for everyone will prevent your clients from accessing the share.

if anyone has found a way to force casper to use the accounts specified in the JSS while retaining kerberos functionality, I'd love to know how! the jamf KB article about mounting DP's just tells you to destroy your kerberos tickets:
https://jamfnation.jamfsoftware.com/article.html?id=48

[acdesigntech]

why are you kerberizing the server housing your jam distro? Part of the logic behind Casper is being able to manipulate client computers using network accounts, mounting shares, etc., that your standard user accounts do not have access to. Is there a reason to do this?

@jarednichols: LOL! In that order?

[jarednichols]

@andrew

haha after reading that after the weekend's respite it's rather funny. I appreciate a "belt and suspenders" approach :)

[nkalister]

my DP servers are shared with other groups that require kerberos, so I don't have the option of disabling kerberos on them, and I don't have the budget or pull with the infrastructure group to stand up new server VMs all over the world just for me.

[jarednichols]

You could flip your distribution to HTTP/S. That way there's nothing to mount.

[nkalister]

hmmm . . . that's a possibility. they're all windows 2008r2 Vm's, so I could use IIS. brings back unhappy memories of troubleshooting http dp's on os x server from the first days of my deployment, though!

[jarednichols]

I've been using IIS successfully. You get resumable downloads which is nice too if your workforce is mobile (like ours). There's a few MIME types you have to add, but search around JAMF Nation and you'll find that info too.

[BaddMann]

Has anyone come across a fix for the Kerberos authentication?
Yes I can go HTTP, but that's a work around and not a fix.
I'm currently finding out about this issue.
I also not sure deleting the ticket is an acceptable answer, as we will need that to mount other network space for the user, right?

Sorry if this sounds short, I'm being pestered by Admins about the verbose emails that Casper is causing in our Group email.

Thanks in advance.
Oliver

[bentoms]

Either don't kerberize the J"Server hosting the DP or move to http/s.

It's only a work around if you've kerberized your DP.

[BaddMann]

Either don't kerberize the J"Server hosting the DP or move to http/s. It's not the Server doing the Kerbize-ing. It's the Clients. As they login they are using the students/employees credentials instead of "casperinstall". As I've managed to use loginhooks successfully before deploying casper and had the exact opposite happen; where I was unable to login as the user and had to do everything as root. The mounting of the share must be using something specific to JAMF or is abstracted away enough from the Loginhook that it can use user credentials. It's just so random, as the login issues happens on most login attempts, but once in a while the correct user is used to execute the policy, just to throw in a little uncertainty into the situation!

Had a support call with JAMF, and the answer I received is acceptable, but disappointing. I've setup http Distribution again for now, and I prefer it, I'm just not happy I can't fall back to AFP and expect the exact same behavior.

There might be a solution in Policy chaining, but I've not started my testing yet. It basically comes down to having a policy Mount a space using the "jamf mount" command and then trigger my specific afp polices with triggers, "jamf policy -trigger blah", all of this done in the advanced tag of the Policy with the Run command.

I could see it working out, but not sure on the worthiness of the endever.

Ahh well at least I stopped the Screaming.
I'll Add more as testing starts.
Oliver