Hmmm, miss a semi-related discussion due to my email being broken for most of the month (still not convinced its full resolved....)
Don't (really) have a managed centralized userid problem....but rather its extending our current system to support machines that aren't local. In our current environment, we have CFEngine pushing around passwd/shadow files. (there used to be a homegrown system that did this, where CFEngine was initially deployed when that system died. Though we do a lot more with CFEngine now....) ....I mentioned on occasion we had a major disruption when CFEngine once pushed empty passwd files everywhere, which it couldn't fix itself, probably because everything was cron driven.... Instead of having cron periodically make sure cf-execd is still running, I have thought about having cf-execd periodically run to check on cron. Would also help where cron daemon has stopped, or somebody comments out cf-execd call from crontab (most of the time it was just meant to be temporary....didn't stop it when I was trying to upgrade a server from FreeBSD 9.1 to 9.2 once....) But, now there's interest in bring Linux laptops into this system...so been trying to figure out just how I would extend our CFEngine setup to. Thought I heard Mac laptops were possible....wonder when I'll get one. While our primary mode is the clients run the promises and copy the files as needed from the policy server.....I have started on the idea of disconnected clients with their own copy of everything (remote location connected by DSL)...since even if it doesn't get any new updates from the policy server (where it promises to run a script twice an hour to refresh all the passwd/shadow files [from central IDM - Oracle DB] that everybody else draws from)....there are promises that still have meaning. Such as ones that addresses configuration reversions every time Ubuntu updates certain packages (the systems are setup with unattended-upgrades allowing more than just security updates.) Of course, the original reason for pushing passwd/shadow files was to prevent local changes to the files....though with the client having its own copy of everything, it wouldn't be that hard for somebody determined enough to ... actually right now, they don't get all the passwd/shadow files this way....haven't worked out how to keep our current layout, but block them from the portion of the passwd tree that isn't them. or some other method. Though I have also wondered what problems there might be if I exposed 5308 to the Internet. VPN appliance on DSL, no problem.... VPN software on a Linux laptop....haven't gotten that working since we switched VPN systems. The Vendor does provide their own proprietary client....as an RPM.... But, want to try to find open way to get it working again.... (considering the switch was that it was more standards based, more likely to work from conference wireless somewhere....) But, I have a really long list of things I want to spend time investigating....but only time to maintain the list. :) On 02/07/14 09:15, Jeremy Page wrote: > I'm willing to allow Kerberos from our DMZ. We are using LDAP there too > but I am not happy with it, even if it's encrypted and never used for > authentication. > > *Jeremy Page* | Senior Technical Architect | *Gilbarco Veeder-Root, A > Danaher Company* > *Office:*336-547-5399 | *Cell:*336-601-7274 | *24x7 Emergency:*336-430-8151 > ------------------------------------------------------------------------ > On 02/07/2014 10:05 AM, Graham Dunn wrote: >> Hi, >> >> So we're using LDAP/AD pam modules to provide user logins on our Linux >> boxen that are inside our network, but what are people doing for >> "remote" (ie. colo, DMZ, etc) servers? >> >> Generating /etc/passwd locally, then shipping it across via scp or >> somesuch, or setting up a tunnel back into the local network were two >> things I thought about, are there other approaches? >> >> Thanks, >> Graham >> >> >> _______________________________________________ >> Tech mailing list >> Tech@lists.lopsa.org >> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech >> This list provided by the League of Professional System Administrators >> http://lopsa.org/ > > > Please be advised that this email may contain confidential information. > If you are not the intended recipient, please notify us by email by > replying to the sender and delete this message. The sender disclaims > that the content of this email constitutes an offer to enter into, or > the acceptance of, any agreement; provided that the foregoing does not > invalidate the binding effect of any digital or other electronic > reproduction of a manual signature that is included in any attachment. > > > _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ > -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
