There are some good howtos around, so that you may already have secured your SSH login to your single server using Google Authenticator as described here. Or did you set up a Yubico validation server and configured Yubikey authentication for a bunch of hostsvia RADIUS?
Today I will show you, how you can setup a scenario, where users can authenticate with Yubikey and/or Google Authenticator and you can define centrally, for which server the users need a Yubikey to authenticate and for which other server a Google Authenticator would be sufficient. Thus you can enforce security levels, meaning servers carrying more sensitive data can only be accessed with a hardware device like the Yubikey while others are ok to be accessed with a software token like the Google Authenticator.
Unique user, two tokens, many machines
You should already have read about enrolling yubikeys and how to use privacyIDEA for two factor authentication to your server farm. So I assume, that you have a running installation.
You should have enrolled two tokens to the user root as depicted below:
One user with two tokens of different type
The user root has a Google Authenticator (serial OATH…, OTP PIN “google”) and a Yubikey (serial UBOM…, OTP PIN “yubi”) token.
Both tokens can be used to authenticate from all configured clients. From localhost (172.16.200.41):
[root@centos6 ~]# echo "User-Name=root, Password=google977398" | radclient -sx localhost auth testing123
Sending Access-Request of id 167 to 127.0.0.1 port 1812
User-Name = "root"
Password = "google977398"
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=167, length=48
Reply-Message = "privacyIDEA access granted"
Total approved auths: 1
Total denied auths: 0
Total lost auths: 0
[root@centos6 ~]# echo "User-Name=root, Password=yubi899739" | radclient -sx localhost auth testing123 Sending Access-Request of id 100 to 127.0.0.1 port 1812 User-Name = "root" Password = "yubi899739" rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=100, length=48 Reply-Message = "privacyIDEA access granted" Total approved auths: 1 Total denied auths: 0 Total lost auths: 0
Or from a remote host (172.16.200.106):
cornelius@puckel ~ % echo "User-Name=root, Password=google308786" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 11 to 172.16.200.41 port 1812
User-Name = "root"
Password = "google308786"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=11, length=48
Reply-Message = "privacyIDEA access granted"
Total approved auths: 1
Total denied auths: 0
Total lost auths: 0
cornelius@puckel ~ % echo "User-Name=root, Password=yubi867011" | radclient -sx 172.16.200.41 auth testing123 Sending Access-Request of id 47 to 172.16.200.41 port 1812 User-Name = "root" Password = "yubi867011" rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=47, length=48 Reply-Message = "privacyIDEA access granted" Total approved auths: 1 Total denied auths: 0 Total lost auths: 0
The idea
The idea is to allow access on the machine 172.16.200.106 only with yubikeys. This is the machine that carries tons of sensitive data and we do not want users to authenticate with their Google Authenticator.
The host with the higher security level
To accomplish this privacyIDEA provides a special authorization policy that will only grant access, if the the authentication was performed with the correct token.
So lets configure a policy:
A policy restricting the access to the system to Yubikey token types.
Override the client interformation
This policy tells the system, that if the client 172.16.200.106 issues an authentication request, it should only be approved, if the serial number of the authenticating token contains the string “UBOM”.
Note: As we are using RADIUS the client 172.16.200.106 issues a radius request to the RADIUS server 172.16.200.41 and the RADIUS server issues the request to the privacyIDEA server 172.16.200.41/127.0.01. Thus the request that arrives at the privacyIDEA server will always be issued by the RADIUS server. So we need to allow the RADIUS server to overwrite the client information – thus the RADIUS server will tell the privacyIDEA server, what the calling RADIUS client was.
We can set this in the system config.
We set the localhost and the eth0 IP of the RADIUS server in a comma seperated list: 127.0.0.1, 172.16.200.41.
The yubikey now can successfully authenticate at the sensitive host:
cornelius@puckel ~ % echo "User-Name=root, Password=yubi773998" | radclient -sx 172.16.200.41 auth testing123 Sending Access-Request of id 88 to 172.16.200.41 port 1812 User-Name = "root" Password = "yubi773998" rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=88, length=48 Reply-Message = "privacyIDEA access granted" Total approved auths: 1 Total denied auths: 0 Total lost auths: 0
while the Google Authenticator fails to do so:
cornelius@puckel ~ % echo "User-Name=root, Password=google850707" | radclient -sx 172.16.200.41 auth testing123 Sending Access-Request of id 24 to 172.16.200.41 port 1812 User-Name = "root" Password = "google850707" rad_recv: Access-Reject packet from host 172.16.200.41 port 1812, id=24, length=55 Reply-Message = "privacyIDEA server denied access!" Total approved auths: 0 Total denied auths: 1 Total lost auths: 0
We can see this in the privacyIDEA audit log:
Google Authenticator fails to authenticate on the server 172.16.200.106 with the sensitive data.
Google Authenticator is still good for default servers
But we can still use the Google Authenticator for the default server with lower security level:
[root@centos6 ~]# echo "User-Name=root, Password=google069728" | radclient -sx 172.16.200.41 auth testing123 Sending Access-Request of id 162 to 172.16.200.41 port 1812 User-Name = "root" Password = "google069728" rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=162, length=48 Reply-Message = "privacyIDEA access granted" Total approved auths: 1 Total denied auths: 0 Total lost auths: 0
We can check this in the audit log, again:
Successfull authenticate on low security server 172.16.200.41
Conclusion
privacyIDEA can be used to enroll many different authenticators to your users and mange these devices centrally.
In a second step you can decide who authenticates where with which device without bothering to reenroll any device.
Thus you can enforce your security policies easily. Additionally the audit log keeps track of all events that do not comply to your security policy。
from https://www.privacyidea.org/enforcing-security-policies-security-levels-with-different-otp-token-types/，
https://github.com/privacyidea/privacyidea
相关帖子：http://briteming.blogspot.com/2016/02/yubikey-otp-validation-server.html
