[Freeipa-users] FreeIPA Clients behind unreliable network links at remote sites

[Traiano Welcome]

Hi Jakub


On Mon, Dec 7, 2015 at 12:00 PM, Jakub Hrozek <jhrozek at redhat.com> wrote:
> 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
> :-)


:-) Something to add to the techie training manuals ...


>
> --
> 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