I've gone through azure a few times since making this and I think all of these options have been moved. I'm sure this plugin would still work, but I don't know the exact process for setting it up.
I urge you to try this instead:
https://github.com/alan-turing-institute/pam-aad-oidc
Then use the pammavis backend to connect tac_plus to PAM.
This provides an Azure AD oauth backend for the MAVIS tacacs+ daemon. You might be familiar with traditional active directory, and the way you connect with it for remote authentication. Most people either use RADIUS or LDAP to talk to backend AD servers. The cloud "Azure" product is different. Even though it is a directory and it's referred to as "Active Directory", it doesn't have an LDAP interface. The only way to talk with it is to use OAUTH.
You can find the TACACS+ project at TAC_PLUS
To get this working you will need an Azure Active Directory setup. You can get started by registering and then logging into https://portal.azure.com Once you are logged in you will see the following options. Click on "Azure Active Directory"
Click "App registrations"
Click "New registration"
Give it a name, then select the supported account types. If you're unsure, then the first option (organizational directory only) is probably the one you want.
You can leave Redirect URI blank, then hit "Register"
Make a note of the Application (client) ID and the Directory (tenant) ID. You will need them both when setting up your client. You will also need a "secret" so hit "Certificates & secrets" on the left menu.
Then hit "New client secret"
Then you can specify a description or leave it blank. You can also set an expiration date or select "Never". Unless you actively plan to regenerate this and fix your tacacs server every few years, "Never" is probably the best bet.
At this point the secret value will be displayed. Make a note of this because it will be needed when configuring the tacacs server.
At this point you will need to set the permissions to allow "openid". Click "API permissions"
Click "Add a permission"
Click "Microsoft Graph"
Click "Delegated permissions", then select "openid", then hit "Add permissions"
The permissions take a moment before you can authorize them. Once you get a button that says "Grant admin consent for..." click it.
Select which account you will use to authorize the OAuth request. Usually this is the same account you logged into portal.azure.com with.
Click "Accept"
In order to use groups you will need to make a couple of additional changes. If you just plan to use a hardcoded group id, then you will only need to make the manifest change. If you want to use named groups you will need to add extra API permissions.
Open the manifest
Find the entry that says "groupMembershipClaims" and set it to "All". If you know what you're doing, you can try using "SecurityGroup" which may limit the list to non-email groups. I've had better results just setting it to "All".
Finally, you need to add an "Application permission" in the API permissions which allows tacacs to Read all groups. Click "API Permissions" again, then "Microsoft Graph"
This time you need to select "Application permissions". In the search blank type "Group", then select "Group.Read.All" and hit "Add permissions".
Follow the same steps as before to grant consent to the application, then confirm the OAuth request.
Your final settings will look like this:
setenv OAUTH_ENDPOINT = "https://login.microsoftonline.com/<YOUR DIRECTORY ID>/oauth2/v2.0/token"
setenv OAUTH_CLIENT_ID = "<YOUR CLIENT ID>"
setenv OAUTH_CLIENT_SECRET = "<YOUR SECRET KEY>"
setenv OAUTH_DOMAIN = "<YOUR DOMAIN NAME>"
# for static groups
setenv OAUTH_GROUP_ID = "<GROUP ID OF ALLOWED USERS>"
# for named groups
setenv FLAG_USE_MEMBEROF = 1
setenv REQUIRE_TACACS_GROUP_PREFIX = 1
setenv AD_GROUP_PREFIX = "tacacs"
exec = /usr/local/lib/mavis/mavis_tacplus_aad.pl
The Mavis engine can cache data so there won't be as many lookups. I believe the default is to cache tacplus lookups for 120 seconds. You can experiment with this.
- All the error messages/codes that we check for might be unique to azure AD. I'm not sure if there are oauth standards for them. We might need to make a specific version of this for each OAuth source, or make the error checking more modular so that we can handle different environments.
https://stackoverflow.com/questions/36780567/azure-ad-how-to-get-group-information-in-token
The problem with putting the groups in a JWT token is that if a user is a member of > xx groups they will break. The workaround is that they include a pointer to download the group list. The limit is around 200 groups. I don't have someone in >200 groups so I don't know how to code the workaround yet.
This means if you change the name of a group from "tacacsAdmins" to "normalUsers" you will need to reload the tacacs daemon for it to see the change. It also means in the event of the signing key expiring the tacacs server will probably break. I'm not sure how often this happens. The key cache is nullified on error, so hopefully this would get taken care of by that, but you might see interim login failures.
I think it would be cleaner to use a PAM backend. This also allows you to use PAM to do direct server authentication. I suspect this would be a more supportable solution in the long run. I'm not positive this is do-able yet because my limited research didn't come across a pam_aad module that does this. I saw some evidence that Azure supports a PAM module for their Linux virtual machines, but I'm not sure if that is available to the general public to use on remote servers outside of the Azure cloud.