PARSEC Technical Information

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
== Getting Ready for Multi-Factor Authentication ==

In any case, probably before or concurrent with any 2FA effort, an account cleanup on Solaris should take place because that is also an audit-failure waiting to happen.  So, independently or concurrently with 2FA, the following cleanup tasks may need doing:

  * Fix /etc/passwd /etc/shadow mismatches.
  * Fix accounts with missing homedirs (security problem).
  * Fix accounts with invalid or unsafe shells for their purpose.
  * Remove direct access to anonymous accounts (backup/operator/etc).
  * Remove/turn-off any direct root access except on the console.
  * Absolutely positively force every login on a named account first.
  * Force any privilege escalation to go through sudo, except on console.
  * Gain and secure console access to the LOM, ALOM, ILOM, or XSCF interface.
  * Make sure pwck passes everywhere (global masters and zones).
  * Pick one master system and distribute the authentication files from there, if possible.

== Weighing In on Solutions ==

Overall, I'd say the Secure Shell PKI solution is the easiest and smartest way to get 2FA/MFA on Solaris. Security "pros" might disagree, but that's because they want you to use the most painful solution possible. Security is always at odds with usability and this will always be the case.  However, there are a few other options I can mention as well as some fairly radical ideas for building analogs. 

== Types of Multi-factor Authentication for Solaris ==

There are several systems for MFA/2FA which will work with Solaris. I'll try to present a description of each one along with the key pros and cons (+/-). 

== Multi Factor Authentication with Secure Shell ==

Secure Shell PKI might do what you want/need with very little effort. 2FA by definition is "something you know, plus something you have". In the case of PKI, there is no TOTP generated by a keyfob or app, but the user must have an SSH private key which matches the public key generated on the Solaris host (or optionally by the user themselves with their ssh application). So, it's your password (to unlock your private key) and your actual possession of the key (ie.. "two factors") keep the account secure. 

  * + The feature is built-in to Secure Shell. No software needed.
  * + You can slowly migrate users by giving them a drop-dead date to create their own keys.
  * + Users that need help or fail to generate a key can be helped easily.
  * + Mass enrollment is possible by generating keys for anyone who doesn't already have one setup.
  * + Keys can be emailed separately from passwords, or encrypted together, etc... 
  * + Can get support on it from Oracle, without going elsewhere to a 3rd party.
  * + Doesn't need internet access or use any cloud services.
  * - Allows automation integration for scripts/cron using 'ssh-agent' securely.
  * - Doesn't generate TOTP codes. Uses the PKI secret key as the "something you have"
  * - Won't always been seen by an auditor as a "true" 2FA/MFA system, even though it **definitely** is. They are simply //wrong// and are confusing 2FA with mandatory TOTP. 
  * - Will make setting up any new Solaris account a bit more complicated (ie.. have to gen keys)
  * - Users can strip their passwords off their keys (but you can ban this)

=== Google Authenticator for Solaris ===

Google Authenticator may be an option for Solaris. However, it needs to be compiled and tested.  It's not nicely packaged for Solaris.  Check this out for more detail on the procedure. [[https://solaristipsandtricks.blogspot.com/2012/10/google-2-factor-authentication-with.html|Solaris with Google Authenticator]]

  * + It supports a TOTP strategy (Google Authenticator app) users will probably already be familiar with.
  * + It's free (for now at least).
  * + Doesn't require any on-prem server like RSA SecureID ACE services. 
  * - It requires you *compile* the PAM module on your Solaris system or you're stuck.
  * - It doesn't come with any support for Solaris at all nor a vendor binary package.
  * - Super rare on Solaris, so nearly undocumented.
  * - It would burn some time and if it fails, you've got nothing.
  * - Needs Internet access to Google's cloud-based OTP systems.
  * - It doesn't offer any way to mass-enroll folks forcing all users through enrollment which is 10-20 minutes.
  * - One often has to debug PAM modules with a stack trace (truss) or logs only, not that easy.
  * - Personally, I don't trust Google to [[https://killedbygoogle.com|continue to operate]] or not to start charging a fee at some point.

=== RSA SecureID ===

RSA has Solaris support via their 3rd party PAM plugin. RSA SecureID works pretty well and has been supported in Solaris for over 25 years.  I did the integration for it at IBM in their Global Services hosted facilities many years ago.  Also, note you can enable RSA SecurID 2FA for Active Directory users by integrating RSA Authentication Manager (ACE) with Active Directory.  However, you cannot use Active Directory as a direct back-end authentication source for RSA SecurID ACE.

  * + Does not require cloud servers or services to function
  * + Great security record for 25+ years. 
  * + Hardware keyfobs are super convenient (but expensive). Has a mobile app to support it.
  * + Comes with a Solaris PAM module precompiled and has documentation for it.
  * + RSA Secure Authentication Manager (SecureID ACE) has a GUI
  * - It's expensive overall to acquire and maintain. RSA is very proud of it.
  * - Everyone has to enroll separately and mass enrollment isn't possible.
  * - You need an SecureID ACE server setup and operating at additional cost.
  * - Your ACE server has to have all the accounts setup 

=== Duo Authentication with Solaris ===

Duo is a TOTP 2FA scheme with a commercial server product at it's core which is very much like RSA SecureID. Duo was an independent company which was acquired by Cisco. 

  * + Has a [[https://duo.com/docs/duounix|native Solaris PAM module]] already available and precompiled. 
  * + Has a mobile app and hardware options for client TOTP token generation.
  * + Supposedly cheaper than RSA's solution
  * + Has a web-based admin front end GUI
  * + Has useful and extensive configuration for the client. Can interop with SSH PKI and selectively apply policies to certain groups only. SecureID has this, too, but not as extensive. 
  * + Commercial support is available.
  * - Requires a Duo authentication server setup (yet another server/service). 
  * - Despite being commercial and testing on Solaris, you still have to compile the PAM module (Huh?)
  * - Documentation for the PAM module setup skips Solaris and ignores it (suspiciously like it doesn't work or something?)

=== RADIUS PAM with Smart Backend ===

RADIUS might be an option if you have an existing 2FA solution for Active Directory or other back-end authentication system which supports 2FA and has a built-in RADIUS server. For example, AD has built-in RADIUS server support so it can support things like mobile authentication, NAS devices, or WiFi routers. RADIUS can securely authenticate users on Solaris using the "pam_radius_auth" PAM module. Many 2FA products can "gang" the user's password with their TOTP code. Ie.. the user enters both as one big string with concatenation. This cleverly provides 2FA support to ANY valid RADIUS client. 

  * + The pam_radius_auth module is *known* to compile on Solaris and tested on Solaris.
  * + There is some documentation and HOWTO style docs for setting it up.
  * + Any AD based 2FA that supports concatination of the TOTP with the password will work, and most do.
  * + You get AD SSO for "free" this way and it's MUCH more simple than using samba or pam_ad
  * + RADIUS is far easier to setup than Kerberos and doesn't use keytabs (painful). 
  * - RADIUS doesn't use PKI crypto. It uses symmetric encryption. Less modern, but still secure
  * - RADIUS is a very old protocol, mostly used for modems and wifi, but perhaps not a negative
  * - RADIUS only does authentication, not authorization (user metadata, groups). So you need "stub" files for the authorization distributed to your Solaris RADIUS clients.

== Failures, Dark Alleys, Boondoggles, and Far-Out Schemes ==

Having gone through the exercise a few times. Here are the things I definitely would <b>not</b> try to make work with Solaris. 
 
  * YubiKey has no Solaris support.
  * Okta has no Solaris support. 
  * Authy has no Solaris support. However, the TOTP client may work with a normal OTP PAM module. 
  * S/Key is built-in but considered insecure by some (old crypto). It's also more complicated for users. Google Authenticator does create S/KEY compatible TOTP codes. So, if you don't have to listen to some security guy complain about completely patched/already-mitigated attacks on S/KEY, then you might still consider using it. 
  * Straight OTP is also supported but requires users to keep a list of one-time-passwords.  This isn't much better than just turning on PKI, but it's definitely 2FA.  It can be painful for users who run out of entries on their OTP lists.
  * There is an NSS module for Solaris called nss_ad but it won't do authentication, merely name lookups on AD/kerberos principle names. Don't bother trying that. It won't give the AD authentication you want. 
  * One can use LDAP authentication on Solaris against AD but there are a LOT of complications.  You have to modify the AD schema and extend it (which MS likes to break with updates).  Frankly, the cure is worse than the disease.  LDAP is awful to work with and simply a curse on IT.  Most sysadmins would rather be stabbed.
  * SAML solutions exist that have PAM modules, but they seem very Linux-oriented and probably have very little chance of working on Solaris. SAML is a cool protocol, but hasn't really caught on due to contamination and cohabitation with Java, a not so cool application programming language. 

==== Far-Out Radical Methods for 2FA/SSO On Solaris ====

There are a few ideas I've had that might work and might be too spacey or weird to be functional. 

  * Kerberos is supported by Solaris. If you have any type of authentication server that supports it (FreeIPA, Red Hat's IPA, Active Directory, and others) then you //may// be able to integrate it with Solaris and get whatever 2FA you have working on your auth server working by proxy on your Solaris host. The biggest downside is you'd lack any authorization metadata and would need "stub files" for /etc/passwd and /etc/shadow created on the Solaris clients with a full list of your users in Kerberos. 
  * The /etc/profile is not writable to normal users and they cannot opt-out if you trap the interrupt signals (control-c). One can use very simple OTP and TOTP tools to further authenticate users (and or kick them out) by calling tools from /etc/profile before the users's profile gets a chance to run. So, in theory, anything you could script could become a second authentication source. The biggest downside to this is that you'll need to enter two passwords and cannot "gang" the passwords together in this case. However, that's the norm for most 2FA anyway. 
  * I seem to remember DIAMETER (a work-a-like with RADIUS) having some Solaris support, but I don't remember where or how. RADIUS is a nice solution, though, so I'd expect DIAMETER to be just as nice. 
  * Some OTP solutions can be modified to use TOTP by adding some kind of math function to the current time. These systems can be hybridized to create something like modern 2FA systems. For example, your TOTP code could be the current minute of the hour, plus the hour, plus 11. This creates fairly random looking codes and if the math function is complex enough, they can be hard to guess or figure out. This isn't as good as using a truly random crypto function, but it's better than just using a static password and definitely functions as 2FA/MFA.