-
Notifications
You must be signed in to change notification settings - Fork 3
Using Rutgers passwords (also, radius as front end for IPA)
Treat the Rutgers password as 2FA, delegate it to RAD. The path is Kerberos calls otpd, which calls freeradius, which calls RAD via LDAP.
Disadvantage: IPA's LDAP server doesn't know about these passwords. If you're going to use Rutgers passwords, I'd probably use them for just about everyone. Exceptions would be:
- test users, which don't exist in Rutgers
- anyone that wants to use 2FA, probably sysadmins
- anyone that needs to use CS resources authenticated with LDAP, as the IPA ldap server doesn't handle these radius-based OTP schemes. If we go this direction, maybe use University LDAP for LDAP-based services.
- users who have concerned about the security of their netid password, or who want to be able to work if the system can't access University servers due to network issues, etc.
Note that credserv can be made to support users with 2FA for cron if that becomes important. I'll be working on the code. I have a way to do it now, but it's sort of inelegant.
This page actually documents two completely different uses of Radius. The original one was the Radius OTP proxy. But in production we're using Radius as a front end so that switches can authenticate. These instructions are for both. Obviously you need two different radius servers, listening on different ports.
on centos, install freeradius, freeradius-ldap, freeradius-krb5, freeradius-utils
set up ldap to ldap.rutgers.edu:
in /etc/raddb
mods-available/ldap
server = "raddc01.rad.rutgers.edu raddc02.rad.rutgers.edu raddc03.rad.rutgers.edu" identity, password come from OIT base_dn = "OU=People,DC=rad,DC=rutgers,DC=edu" uncomment scope = 'sub' If you want to use radius as a front end for IPA, almost the same configuration works, except server should point to one or more of the IPA servers, identity and password should be ldap.admin (see the 1password entry), and base_dn can be "cn=accounts,dc=cs,dc=rutgers,dc=edu" You probably also want to change the port number in sites-available/inner-tunnel, port= For IPA front end, in the update section, add reply:DellEMC-Group-Name := 'dellemcgroup' This adds the attribute used by the Dell switches. Make sure /usr/share/freeradius has dictionary.dellemc. If not, take it from the current radius source code and edit dictionary to include it. in tls section start_tls = yes ca_path = /etc/openldap/certs/ require_cert = "demand"
mods-available/eap
first two default_eap_type change to gtc
For the radius proxy, I used sites-available/inner-tunnel, but since we don't know the passwords in the clear, only PAP will work. That's supported by default. (inner-tunnel is only for EAP and friends, which we can't support). So the production server has only default in sites-available, with these edits. If we need to support Rutgers passwords and radius as a front end, you might use inner-tunnel for the rutgers passthrough, with a different port (I used 18120). That depends upon
sites-available/inner-tunnel or sites-available/default
at end of authorize section, right after "pap" add if (User-Password) { update control { Auth-Type := ldap } } at the beginning of authenticate section in Auth-Type PAP { change pap to ldap at the end of authentication, in # Auth-Type LDAP { uncomment ldap inside the section, but leave the Auth-Type LDAP and } commented
cd mods-enabled/ ln -s ../mods-available/ldap .-
to test, as root "radiusd -X"
from another terminal, radtest -x USER PASSWORD localhost 0 testing123
When it works, if you're using this to implement Rutgers passwords, proceed to ipa
ipa config-mod --user-auth-type=radius --user-auth-type=otp
if you want all three possible. If a user has neither radius nor otp, it will use password
find or create a test user
ipa radiusproxy-add ldap-proxy --server=127.0.0.1:18120 --secret and type testing123 two times
ipa user-mod otpuser --radius=ldap-proxy --radius-username=hedrick
This assumes the IPA user is otpuser and you want to authenticate as hedrick to Rutgers LDAP
Now
kinit -T ccache otpuser
This is 2FA, so you need an existing credential cache to "armor" the request. sssd handles this for you. I supply a script to call kinit that does it using credentials for anonymous.user.