Scripting Outlook 2016 to use Kerberos authentication

@talkingmoose do you by any chance have some insight on this one?

Thanks!

@ocla&&09, if the full script works on multiple macOS versions but fails on one, then my assumption is the shell command is what you need to check. (You're using the same version of Microsoft Outlook across your Macs, yes?)

On your 10.11 system, open Terminal and test the shell command:

klist | grep "Principal:" | awk -F ": " '{ print $2 }'

Does that return the kerberos principal name you expect?

@talkingmoose I think you are correct. I get the following output on an affected machine:
klist | grep "Principal:" | awk -F ": " '{ print $2 }'

Looks like that is the source of the issue.

Are you aware of a more appropriate command? I will do some digging on a 10.11 vm I have.

Thanks!

@ocla&&09, unfortunately, I'm far far away from having a 10.11 system. Not even sure I still have the installer.

I believe klist is still the correct command. And grep and awk haven't changed since then.

So, start with that. What do you receive when you run klist in Terminal on your 10.11 Mac? Remember, you must run this on a Mac bound to Active Directory and you must be logged in to an Active Directory account for this to work.

If you can post the full resulting line (slightly scrubbed if needed), maybe we can figure out what's changed.

@talkingmoose I get the following output on affected machine:

klist: krb5_cc_get_principal: No credentials cache file found

I am in the process of transitioning machines from AD binding to non bound machines with Enterprise Connect and Local accounts
In doing some more digging I am wondering if it is that the machines in question have Enterprise Connect but are still bound to AD (of which there appears to be a few that will need to be mitigated). I ran klist on a 10.11 machine that was NOT bound and logged into Enterprise Connect, and it returned exactly what you would hope ie the users Kerberos ticket name.

I am also wondering if the extension attribute I am using to get the authentication method may be flawed as well. This is what I am using to get the auth method in Outlook:

## Get the logged in user's name
loggedInUser=$( ls -l /dev/console | awk '{print $3}' )
## Get the UID of the logged in user
loggedInUID=$(id -u "$loggedInUser")

kerberos=`/bin/launchctl asuser $loggedInUID sudo -iu "$loggedInUser" /usr/bin/osascript -e 'tell application "Microsoft Outlook" to get use kerberos authentication of exchange account 1'`

if [ "$kerberos" != "true" ]; then
    echo "<result>Username and Password</result>"
else
    echo "<result>Kerberos</result>"
fi

Can you see some issue in the way I am identifying the account to get info (ie "Exchange Account 1)? Is there a better way?
In running this command locally on a 10.11 machine I am also getting the following output:

Failed to get user context: 1: Operation not permitted

@ocla&&09, your script seems to be running fine on my macOS 10.13.6 machine.

I use a different method to run a command as the current user. Maybe this will be a little more backward compatible. Sorry, I don't have OS 10.11 to test.

#!/bin/bash

# Get the logged in user's name
loggedInUser=$( ls -l /dev/console | awk '{print $3}' )

# define the command
theCommand='osascript -e "tell application "Microsoft Outlook" to get use kerberos authentication of exchange account 1"'

# run the command
kerberos=$( su "$loggedInUser" -c "$theCommand" )

# return the results
if [ "$kerberos" != "true" ]; then
    echo "<result>Username and Password</result>"
else
    echo "<result>Kerberos</result>"
fi

exit 0

Great, thanks. Looks like the way I was calling the script as the user was having some issue on 10.11.
Instead of:

/bin/launchctl asuser $loggedInUID sudo -iu "$loggedInUser"

I simplified to:

/bin/launchctl asuser $loggedInUID

That seemed to help in the extension attribute, as well as in the actual script making the change.