On Sun, Dec 06, 2015 at 09:58:58PM +0300, Traiano Welcome wrote:
> Hi List
> Current Scenario:
> =============
> I have a number of stores on really unreliable network connections:
> It's quite possible for the links to have been down for 3 - 4 days at
> a time.
> In a given store is a single Linux "Back Office" server running
> Directory 389 which holds credentials for a number of tech support
> usernames.
> There are also a number of point of sale computers running linux which
> authenticate users against the 389 Directory server on the back office
> server.
> The Directory servers in the shops all synch their copy of the
> credential database from a central Directory Server, during normal
> operation.
> At some point a support engineer goes to the store to do maintenance
> on the point-of-sale computers and logs in with his Directory 389
> credentials.
> Since the credential DB almost never changes (usernames and passwords
> stay static), a support technician can generally rely on the
> credentials being "as expected" even if the store has been out of
> contact with the master copy of 389 directory servers: The technician
> can log in to a PoS, do maintenance, even while the network link is in
> the process of being restored.
> Desired scenario:
> =============
> I'd like to deploy FreeIPA to these stores, and replace 389 Directory
> server based system running on the Linux. The problem is that the
> point-of-sale machines will frequently lose contact with the primary
> replica, and credentials will timeout. So when the support technician
> walks in and the network link happens to have been down for some time,
> he'll not be able to log in to the point-of-sale computers.
> Note: There is no possibility of installing a freeipa replica on the
> Back Office server itself, it's got a whole pile of bespoke Java +
> tomcat crud running on it. There is also no possibility of installing
> an additional FreeIPA replica server in the store itself - the
> economics of the store won't allow it.
> Possible solution:
> =============
> I think enabling offline authentication, with credential expiry
> disabled completely may do the trick, with the downside that user
> accounts that have been deleted in the 'main' FreeIPA replica may
> still linger in the store's copy ...
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache-cred.html
> "offline_credentials_expiration sets the number of days after a
> successful login that a single credentials entry for a user is
> preserved in cache. Setting this to zero (0) means that entries are
> kept forever."
> My expectation is that credentials will be updated while connectivity
> is there, but authentication will be possible even in loss of
> connectivity for quite some time.
> My question is: Is this the best approach to solving the reliable
> authentication problem, given that the client's may not be able to
> access a FreeIPA replica for long periods of time? Are there any key
> issues I'm overlooking in taking this approach, or possibly better
> approaches?

I think this should work OK. The clients (SSSD) always try to log in
offline, so as soon as the client would re-establish connection to the
server, the client would check against server's database, otherwise
consult the local cache.

Just make sure noone removes the sssd database if they think the client
is acting up as a 'troubleshooting', the credentials are cached there

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to