[Freeipa-users] FreeIPA and Application Specific Passwords

[Steven Jones]

Hi,

There is always a tradeoff between ease of use, complexity/cost and security.  Looking at what you have written suggests to me that your entire system lacks a proper security / network architecture model and you are trying to enforce a "policy" from one point, IPA.  

regards

Steven
________________________________________
From: freeipa-users-bounces at redhat.com <freeipa-users-bounces at redhat.com> on behalf of Martin Minkus <martin.minkus at sonic.com>
Sent: Thursday, 19 February 2015 1:06 p.m.
To: freeipa-users at redhat.com
Subject: [Freeipa-users] FreeIPA and Application Specific Passwords

Hello all,

Am wondering what support FreeIPA has for Application Specific
Passwords? My research seems to indicate 'none'. I've seen quite a few
people ask about this, usually the example is wanting a separate
password for dovecot etc.

Google itself implemented this, allowing multiple passwords for imap
accounts in gmail so that a stolen phone or ipad doesn't give the thief
complete unfettered access to the entire google account. The single
password can be easily changed or locked out and even if it is not, it
only has access to email.

I work for an organisation and we are looking at standardising on
FreeIPA for all our single sign on and auth requirements.

Except where we don't want single sign on, and separate passwords are
advantageous or even required:

 - Web logins
 - VPN logins
 - Tacacs

I'm assuming it's somewhat understandable to want to keep web logins
separate - web sites are notoriously insecure, and we wouldn't want an
employee's web login getting stolen/phished/etc giving an attacker vpn
access, kerberos/ldap access to all our linux servers, and tacacs access
to network infrastructure.

The solution I've seen suggested to others that have asked about FreeIPA
or OpenLDAP and Application Specific Passwords seems to be: Just create
a separate user login for each application.

Messy, but sure.

I also see we could extend the schema and add in extra fields like
webPassword and vpnPassword, but we'd have to maintain those
fields/enforce complexity and length requirements/password expiry
ourselves which is less than ideal.

Or the final option might just be to run separate ldap instances for
each application, so the username stays the same group membership is
application specific in each ldap instance, and it gives us the password
separation we desire. Also, most users don't need tacacs access or vpn
access, though most(all) users will need web application access.

Anyway. I'm wondering if there are any other potential options that I
have missed? Or some better way we should be going about this?

Yeah, we should probably trust our employees with their passwords more
but apparently that is not the case.

Thanks,
Martin.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project