-
Notifications
You must be signed in to change notification settings - Fork 3
Home
- Setting up FreeIPA, KDC and LDAP
- IPA operations
- Account management operations
- Directory and quota management
- note on password changes
- Setting up new server (replica) in an existing system
- Setting up proxy for home use
- Setting up a Kerberos client, Centos 7
- Setting up a file server
- Attributes in LDAP
- Kerberized NFS on Mac
- Windows NFS
- Account management web site
- Using Rutgers passwords (also, radius as front end for IPA)
- Hadoop setup
1. Secure NFS. Make sure users can't install systems at an IP where we've exported a file system and then access all files.
Also, because Kerberized NFS checks on a per-user basis, even if someone becomes root on a machine they can't compromise user files. A user should only be exposed on a system where they are actually logged in, or on which they run cron jobs. There's not much better I can do.
This should make it safe to allow faculty to mount our file systems on machines they run.
2. Secure ssh. We allow ssh without passage based on IP address. This has obvious problems if users fake an IP address or become root. A user must now have an actual ticket. We can still restrict which groups of systems can access others, probably used netgroup-based configuration in sshd_config.
1. Make Kerberos transparent. I'm dealing with this by supporting all ways into a machine through pam, and by having a daemon (credserv) that will keep their credentials renewed as long as they have processes.
2. Cron jobs. Uses a pam module talking to credserv. This lets users authorize root to get credentials for them.
3. Support of different machine types: Mac works, but for 2FA you need to install Macports Kerberos. Windows seems to work with a special GINA that has been licensed by Rutgers. Solaris 2.8 Kerberos libraries are too old, but login with nslcd works. Obviously we can't do Kerberized NFS without Kerberos tickets.
Suggested Linux configuration:
sssd on machines that have it, otherwise nscd.
Policies need to be chosen carefully to support our goals. In particular, Kerberos policies need to be adjusted. I'm using a nearly infinite renew time, to support very long sessions. We continue to use the default credential expiration of a day.
However we run rpc.gssd with an option that causes it to recheck credentials every 10 min. What happens is when someone logs out, renewd kills their credentials. The next 10 min activation of rpc.gssd will then kill their NFS session.