You are maintaining 50 servers for multiple contracts and they want to know what is patched.

To me this would be a completely fair and normal situation.

I haven't worked with Windows Server in 8+ years. But WSUS was great for telling you what patches were needed and approving them to be installed.

I know that RedHat has similar technologies. Though you can also roll your own as well.

From my own company, I attend a Change Control meeting and one meeting a month has the Microsoft patch bundle as part of it. The patches get installed on a subset of the company on day X and they day X+2 they get pushed to everyone. This allows testing.

For production servers that customers are using to me it is a no brainer that the customer wants to know and approve what changes are happening to their server.

Depending how busy you are, you might have a resource issue which is fair to complain about.

But that they want to track and approve patches / changes? Suck it up buttercup.

The issue is that many programs can generate a shell.

For example, many sudoers files will let you "/bin/vi /etc/X11" or "bin/vi /etc/hosts"

And if your type ":shell" in vi, you now are logged in as root with a shell.

Sudo is far from perfect, but it like disabling root login and requiring "su" to become root, at least let you know who most like messed it up.

When you just have a small group of UNIX admins, it makes sense to just log su for most systems. On critical systems, setting scripts or suid binaries so that they can do typical tasks as their own idea also work great.

There are ways to secure environments enough, but almost no way to perfectly secure them.

No matter what you do, someone needs to know the all powerful password to the system (And they should be written down and stored in a safe so that if that person dies/quits/terminated, someone else can get them).

Even if you make the most perfect system there will be the occasions when you something out of the ordinary happens and you will need root.

I personally prefer an environment setup, so that people have to log in as themselves and switch to root. That way you have some audits of who did what. And on critical systems, I've actually installed a key logger so that we knew even what commands were run.

And if it is possible setting up Roles or sudo so that common tasks are can be done as themselves.

But in the end you will need to completely trust at least one or two of your IT people. They will have the keys to all your critical systems and know all the security/checks and balances around your systems. In medium/large companies, you might have silos, so that specific groups own systems, which makes it so that one set of IT people don't control everything, but even then you need to trust the people running your ERP system.

A few comments:

1) Why on earth are they allowing people to use personal computing on the company network?

2) For home access, they should deploy some type of terminal environment at the office. So that you get the screen displayed on your home computer, but don't actually get the data stored there.

Personally I think they should be banning any non-company devices from their internal network. Period.

As for the home access, I agree with you about not wanting them to install software on your personal machines (if they just want Anti-Virus, that is one thing, but requiring disk encryption...)

But I agree with their need to lock it down. They're just going about it wrong.

The other thing you can consider is whether to split the directory services and the authentication.

At my last job we did the following:

- Use Windows AD for all windows machines
- Use NIS for passwd, group, automounter maps... everything but authentication.
- And then key the Linux machines to use Kerberos off the Active Directory

Now if I was doing it again, I'd do the following:

- Use Windows AD for all windows machines
- Setup up a UNIX/Linux based Kerberos domain that "trusted" by the AD Kerberos
- Use NIS, NIS+ or LDAP from Windows AD for directory services for UNIX/Linux

- Setup all the UNIX/Linux machines on the UNIX/Linux Kerberos domain and have them use the windows domain for user authentication.

The adavantage to this would be that once you have a valid ticket you can securely log into any of the machines. Plus then you could securely setup NFS v4.

As for which NIS, NIS+ or LDAP to use, I haven't looked into recently.

And why I would use two Kerberos domains is that the Windows AD says it should play nice with Linux machines and allow you at keys onto them. But the commands from Microsoft never worked. I used a simple utility from some consulting company that worked well, but it wasn't supported and there it seemed to be hitting some hard limits. Since I'd hate to wait for Microsoft to fix their setup, I'd use two domains but setup a trust between them.