The reason for what you described is that when the admin types in their username/password, the OS stack is also obtaining a Kerberos TGT, that is reused by the browser and translated by your Fedederation SSO solution to give a WS-fed token for O365. This is by design and can be resolved by the admin user typing the corresponding kdestroy command (or using ticket viewer's remove identity function) before leaving the user's workstation after the setup program has ended.
Now to your questions:
a) Is there any way to not generate a kerberos ticket in this scenario?
Yes. You can either use a local account or deliver the program via a utility like our Identity Service or tools like Casper.
The reason why a Kerberos TGT is created is because the user providing the assistance (the admin) is an AD user and AD uses Kerberos for authentication.
b) If we used Centrify to bind to AD, would the same issue arise?
The way you described the scenario, this could likely happen, but with Identity Service Mac Edition you have the ability to deliver the app using Group Policy (e.g. granting the user temporary privileges to install the app) or using the OSX InHouse custom app to deliver the software.
c) If we used local admin user accounts, rather than AD accounts for administrative elevation, can we restrict these users from logging in, but still allow the account to be used when dialog boxes appear?
Yes. Using a local account can solve the situation, however it may introduce another potential (and often more challenging issue than the one you described): shared privileged accounts; this means that you have to control the password lifecycle (request/approve/check-out/use/check-in/rotate/periodically rotate).
An additional benefit for Centrify is that you can license Privilege Service for your IT staff and get unlimited Shared Account Password Management and Session Brokering. This allows the admin to check out the password the local privileged account for the Mac when he needs to perform admin duties, use it and when done the password gets rotated automatically. Ultimately nobody knows the password and this can be controlled via Centrify Workflow or ServiceNOW.
Here's an example of the sequence in action.
The flexibility with Centrify is that you can use us for the 4 use cases that you outlined:
- Advanced AD integration beyond what's provided by the Apple Plugin (e.g. dynamic DNS, auto-enrollment of PKI certs, complex AD support, Group Policy, etc)
- Integration, Federation, Provisioning for O365 and turnkey setup for more than 3500 other apps.
- Device and Application Management for OS X, Android and iOS
- PIM shared account password management
Most organizations need multiple solutions from different vendors to accomplish all that.
Bottomline - have your admins kill their tickets after setup is done. Otherwise if anything you see here is of your interest, let us know we are happy to help.
R.P