4 ms·

> How robust are your routines for removing accounts when unused? For our main corporate server list (about 1000 servers and 50 users), disable account in ldap

> How robust are your routines for removing accounts when unused? For our main corporate server list (about 1000 servers and 50 users), disable account in ldap and password authentication no longer works (so they lose sudo). Takes about 5 minutes to replicate I believe. If they have a .ssh key they can still log on until the local account is disabled, which runs daily. The 100 or so servers outside the corporate walled garden, with 10 users, simply have to wait for a day for the account to be disabled - or run a bash script from rundeck to kick it off earlier. The CRL cache-time on their client certs is longer than that in any case so it's not top priority. I last did this 3 weeks ago. We didn't want central authentication for non-walled-garden machines as there's a good chance many of them may be used offline, both via ssh and local access. It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog. How do you prevent an ex-employee logging in without a generic account, other than changing credentials and authorized keys? I'm assuming it was a mutual termination and you don't need to worry about backdoors (because if you do, you're screwed regardless) But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix?

kbenson 8y ago
> It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog. I can write a system (and have, multiple times) that takes public keys from people in a file named by their users, aggregates them into a single authorized_keys file, and pushes it to the admin account on all the servers in a list in 5-10 minutes. Access removal is removal of their key and running a command that uses scp to upload a new authorized_key file for all servers. Using xargs and parallel jobs, than can complete within a minute or two even for 1000+ servers, errors are easily visible, any problem in the process is easily troubleshot, and if worse comes to worse and the system isn't functioning, you can manually update the authorized_keys on a few servers that need it ASAP. No LDAP config, requires, and anyone with basic SSH understanding can diagnose and understand what's required to fix an error within a minute or two. Give me another 30-60 minutes and it would support a config file with user groups and assigning group or individual access to servers. There are features you don't get with that, but it's dead simple and very robust. LDAP is good, but if all you need is to set up admin access to Linux/BSD servers, it also might be overkill and cause the occasional headache. There's a huge range between manually configuring every server for every change and using LDAP for account access. > But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix? SSH allows environment vars to be passed along with the authorized key file. You can set your default EDITOR for example, but your push system can also append a specific variable that denotes who the actual user was that connected, and your login config can log it to a file as you connect. There are simple solutions for most things you would want in this space. Once there isn't a simple solution, then maybe the value of a centralized authorization system might show itself.
- isostatic 8y ago
  > I can write a system (and have, multiple times) that takes public keys from people in a file named by their users, aggregates them into a single authorized_keys file, and pushes it to the admin account on all the servers in a list in 5-10 minutes. The modern way to do such a thing would be using ansible, which just as easily allows you to create/delete user accounts. While custom vim settings per user are nice to haves, the biggest benefit is AAA. I'm not sure what type of auditing you can realistically do with, you'd have to trace through machine logs to find the IP of origin for a given pts, and hope that the dhcp server still has.

kbenson 8y ago

> It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog. I can write a system (and have, multiple times) that takes public keys from people in a file named by their users, aggregates them into a single authorized_keys file, and pushes it to the admin account on all the servers in a list in 5-10 minutes. Access removal is removal of their key and running a command that uses scp to upload a new authorized_key file for all servers. Using xargs and parallel jobs, than can complete within a minute or two even for 1000+ servers, errors are easily visible, any problem in the process is easily troubleshot, and if worse comes to worse and the system isn't functioning, you can manually update the authorized_keys on a few servers that need it ASAP. No LDAP config, requires, and anyone with basic SSH understanding can diagnose and understand what's required to fix an error within a minute or two. Give me another 30-60 minutes and it would support a config file with user groups and assigning group or individual access to servers. There are features you don't get with that, but it's dead simple and very robust. LDAP is good, but if all you need is to set up admin access to Linux/BSD servers, it also might be overkill and cause the occasional headache. There's a huge range between manually configuring every server for every change and using LDAP for account access. > But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix? SSH allows environment vars to be passed along with the authorized key file. You can set your default EDITOR for example, but your push system can also append a specific variable that denotes who the actual user was that connected, and your login config can log it to a file as you connect. There are simple solutions for most things you would want in this space. Once there isn't a simple solution, then maybe the value of a centralized authorization system might show itself.

isostatic 8y ago
> I can write a system (and have, multiple times) that takes public keys from people in a file named by their users, aggregates them into a single authorized_keys file, and pushes it to the admin account on all the servers in a list in 5-10 minutes. The modern way to do such a thing would be using ansible, which just as easily allows you to create/delete user accounts. While custom vim settings per user are nice to haves, the biggest benefit is AAA. I'm not sure what type of auditing you can realistically do with, you'd have to trace through machine logs to find the IP of origin for a given pts, and hope that the dhcp server still has.