Hi Jakub
On Mon, Dec 7, 2015 at 12:00 PM, Jakub Hrozek <[email protected]> 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 -- 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
