Kerberos and Admin Elevation

[aatkinson]

Has anyone else experienced an issue with a kerberos ticket being granted to a user when they complete the admin elevation dialog?

In our school environment sometimes a student needs to complete an action that requires admin rights. Normally the teacher or support tech will enter their credentials in the prompt, without having to perform a full log-on to complete the action.

Turns out that at this point a ticket is granted for their credentials, which might be allowing the install of an app, or opening up a pref pane.

The problem with this is that we use single sign-on for O365, and the granting of the ticket means that the student then receives the email of the teacher or tech support.

Apple seem to think this is 'by design' and our problem because we use directory and not local accounts. Am I mad in thinking that granting a kerberos ticket for the admin elevation prompt is massive security risk? Managing 3500 macs and having to implement local accounts is going to be a massive nightmare.

[jamesdurler]

I agree @aatkinson, this is obviously a massive security risk.

In my opinion a kerberos ticket should not be generated for the purposes of account elevation. Apple can say thats normal behaviour but I'd like an explanation on why this is the case.

Is it simply because they have just re-used the login process at this elevation screen which has unknowingly created this issue. We cannot be the only ones using Active Directory administrative accounts.

[bentoms]

@aatkinson If local accounts are out, I'd look into adding scripts within Self Service that accomplish the same tasks that the technicians are having to authenticate on the Macs to do.

[davidacland]

Local accounts would be the simplest option, although you'd lose the accountability element.

I would do some analysis of the system log to see in what cases the users need to elevate, then target those situations specifically with SS as Ben said, or by group membership / editing of the authorization.db etc.

[franton]

A kerberos ticket is generated per user login, whether it's at the login window or via security agent for temporary privilege escalation. That's it's designed behaviour, so Apple is correct here. You should be using Self Service more to get around this as @macmule said. OS X does not behave like Windows.

[jamesdurler]

I understand this is 'normal' behaviour and where this behaviour may be useful for a user logging in as having a kerberos ticket for a user is beneficial.

What I am getting at is it seems apple are just leveraging the same process at login window whilst at the security agent. This is obviously why a kerberos ticket is being generated. The point I'm making is that these 2 types of logins are different and need to be treated differently.

I have asked apple if this is by design at the security agent then what is the need for the ticket in this instance. I am awaiting their response at the moment.

Also, it would be lovely to have every function available in self service and up to date but in reality thats not feasible. Thats why we give admin rights to technical teams; so if there is something they need to accomplish they can do so without impacting teaching and learning.

Peace out

[aatkinson]

Thanks for all the responses!

We do try to put as much into SS as possible, but sometimes there is something urgent that needs to happen.

So to conclude this thread, nobody feels that this is an unsatisfactory design?

[CypherCookie]

Hi all,

I understand where aatkinson is coming from, the fact that office365 is changing kerberos tickets for the user is an understandable action, however I think that there is a point to be made here, that the ticket shouldn't jump user accounts for a single action, especially for a temporary permission hike to install something.

You can make arguments that Office365 shouldn't be changing kerberos tickets for the user ergo a Microsoft issue, and likewise you can argue that the way OS X handles the permission change shouldn't mean that the Office365 account should change either.

Ultimately I think both parties need to be notified about this issue and hope someone internal to those companies fix this problem.

Alternatively, create a new admin account which doesn't exist anywhere but the local Mac's and then enable something via self service for people to run, that way when a Kerberos ticket is issued Office365 can't jump users as that user doesn't exist in the AD.

[jontowles]

The problem you have is that even the local account somehow creates a kerberos ticket.

I have a local account that doesn't even have an admin account yet it can somehow still create a kerberos ticket.

I've done a number of things trying to automate kerberos better:

1. Renew tickets when you unlock
2. KDestroy on reboot

It continues to be a constant challenge. I would say that people just need to be trained that after granting elevated credentials to kill their ticket.

[chris_fast]

I think I just ran into this same issue. Our users have non-admin AD mobile accounts and then use a separate AD account for admin elevation prompts. We just started using an app that uses the non-admin account's kerberos ticket for authentication to a DB. I noticed that any time I used my admin account to make a change to a System Preferences setting my app would lose connection to the DB with an authentication failure. Sure enough
"klist" revealed that after I enter my AD Admin creds my non-admin kerberos tickets are gone and replaced with one from my admin account. A quick 

kdestroy && kinit

 (assuming you've previously ran "kinit --keychain" to cache your password) seems to restore the DB connection, but it's such a pain! Anyone find a good work around for this?