After conquering Business Problem #1, there are some other challenges related to network shares, privilege management and other usability requests.
- End-users are calling in with issues accessing their files over the network (permissions issues) in NFS and Samba shares
- Some of these shares are hosted in non-centrified systems and appliances that are closed boxes.
- Database users are requesting the ability to run certain utilities with in the context of certain privileged local accounts.
- Web Administrators are requesting the ability to perform certain operations with the Apache server.
- Offshore operations: The company has outsourced some functions (backup operations) to an external group. They need to perform backups in late hours of the night.
- Access reports are produced with more efficiency, however, the Security department would like to be able to generate them on their own without the assistance of the UNIX administrators.
- Passwords stored in script utilities: there is an initiative, now that there are better tools, to eliminate the practice of using service accounts and embedded passwords in scripts or with reversible encryption.
- Since the number of servers is increasing, especially in remote sites, there's a need to make sure that a limited set of trusted administrators can access the systems in the event of an outage, even if they have not signed into the system before.
- Certain users are requesting that since the identities are consolidated in AD and the OpenSSH versions deployed support the Generic Security Services Application Program Interface (GSSAPI) if it's possible to get silent sign-on to UNIX/Linux servers using SSH.
Secondary UNIX groups
- Secondary UNIX groups are still used for different purposes. Although they are not used anymore for access or privileges with sudo, they are still used for various applications. There's an interest in streamlining this process and make it as automatic as possible.
- We should be able to maintain the auto mount maps to NFS shares.
- The process of provisioning Secondary groups should be aligned with the existing process of user provisioning.
- Additional rights can be granted to Database and Web users as long as privilege accounts are not shared.
- The offline mechanism for trusted administrators in remote servers, should not store passwords in the clear; this would conflict with another initiative.
- Users are allowed to leverage SSO, as long as it doesn't affect the deployment schedule or require additional components.
NetApp filer administrator
- The filer is a closed system. Any solution should use the facilities exposed by the appliance.
Planning ActivitiesNetwork Shares (UNIX Admins, Appliance admins)
During the initial rollout, some identities were overridden at the system level, this means that when users log into those systems there is inconsistencies with their identities. These systems need to be converted.
In addition, there are stand-alone servers running Samba and NFS that need to be aligned with the new solution.
Finally, there's NetApp filer that needs to be integrated to the system, leveraging Centrify tools.
Additional Privileges (all)
After working together with the Security Analyst, Web and Database Managers, the UNIX administrator decide to extend the privileged rights for the Database users (DBAs) and Web Administrators.
- Will continue to access only database systems via SSH
- Will be able to elevate to the db2inst account
- Will be able to run the db2 commands as the db2inst account
- Web Admins can
- Will continue to access only web systems via SSH
- Will be able to edit the files in the /etc/httpd/conf
- Will be able to control the status of the httpd service
Controls should be implemented to limit abuse.
- Offshore Operators
- Will have SSH access to Utility Servers
- Will be able to run the tar command to perform home directory backups
- The privileges will be limited from 10 PM - 6 AM
Reporting for Security Analysts
Since the reporting facility of Access Manager is an MMC snap-in, the Windows administrator states that it would not be a problem to allow read-only access to the Security Admins.
Improving Script/Service Account Security
As part of the initiative to have better security, the UNIX administrator will explore options to eliminate the practice of knowing service account passwords and the possibilities to improve the security of scripts that leverage those accounts.
Usability (UNIX Admin, Security Analyst)
There should not be any issues because both versions of SSH Server and client support GSSAPI. No additional components are required.