Our fictitious company (Contoso):
- Their core competencies are not in Technology (unlike a Google or Apple)
This means that they can't profit or showcase what they develop in house. - They have limited staff and are cost conscious
- They value operational efficiency
- They have agreed to maximize their investment in Active Directory: People, Process, Technology.
Contoso is looking to start processing credit card information, and based on PCI, in the first phase they need to start enforcing certain rules like:
- Eliminate the usage of shared privileged accounts
- Make sure people are uniquely identified (PCI 8.1)
- End users will authenticate to Unix systems with their AD credentials
- Make sure that when accounts are enabled/disabled/constrained in their Active Directory, the same is expanded to Unix and Linux systems
- The security policy for passwords needs to be uniform across platforms (Windows, UNIX, Linux)
- User passwords can be changed from Windows/Unix/Linux without synchronization.
UNIX/Linux Admin
|
-
It’s becoming very hard to keep track and
maintain local accounts.
-
We have some old NIS servers and maps that
need to go away (legacy)
-
Each time there’s I need to scramble to make
information available to auditors
-
The root, oracle and other service accounts
are shared; it’s hard to establish who did what.
- Ideally, any service accounts are managed within the UNIX system and not provisioned in the directory - I am concerned that if AD (or the network) is not available, it will be impossible to log in to servers. - I am concerned of not being able to perform functions to do my job (superuser) or that it will be hard to elevate to get rights |
Security Analyst
|
-
We will start processing credit card data soon,
therefore I need to make sure that privileged accounts are not shared
-
We need to make sure that everyone has a
unique identity
-
We need to carry over the security policy
defined on Windows to UNIX (password policy:
length, complexity and expiration)
|
IT Manager
|
-
Our workflow for provisioning and password
resets is very complex. When somebody
needs a UNIX account for our systems, more teams need to be involved.
-
We have to be ready to process credit card
data
-
We have an Identity Management System (FIM)
and we would love to leverage some of the existing processes
|
Windows Administrator
|
-
Whatever solution is coming in should not
require schema extensions to AD and no Software in domain controllers.
-
We should be able to keep the same
organization and naming conventions that we use in the directory today.
|
Planning Activities (stakeholders)
These are the planning activities to address this problem with the corresponding stakeholders. This can be the biggest challenge, especially when the status quo is to work in a fragmented and independent way. Decisions need to be made, compromises will have to be reached, etc. All projects have a cognitive, cooperation and coordination aspect. Assuming our stakeholders find the right balance, an initial set of activities include:
Access Governance (all)
After working together with the Security Analyst, the UNIX administrator decides that although the tool provides the flexibility of granular access and privilege management, the initial goal is to implement a model that provides an easy path for productivity. Because of this, there are two types of systems:
- Database Servers
- Web Servers
And two roles: System Administrators and Regular Users.
System Administrators have the right to log in to all systems.
DBAs are allowed to log in to all database servers.
Web Administrators are allowed to log in to all Web servers.
For now, the company will continue to use their sudo scheme for privilege management
Naming Conventions and Object Storage in AD (Windows and UNIX Administrator)
After researching the product, the Windows Administrator comes up with a storage strategy for the new Unix objects:
UNIX
OU (top level)
|
to store the top level objects
|
Servers
OU
|
to store the Unix computer objects
|
Computer
Groups OU
|
to the security groups for
grouping computers
|
Roles
OU
|
to the security groups related to Unix Roles
|
UNIX
Groups OU
|
to hold the Security Groups that
map to UNIX groups
|
Licenses
OU
|
to store
for the license information
|
Zones
OU
|
to store the container objects
used by Centrify to group systems.
|
Provisioning
Users: Provisioning of UNIX identities will happen manually for now. The UNIX administrator will work to perform an initial migration of the existing users. From that point on, new users must have a unique UNIX identity. Access and roles will be provisioned after the user is set up.
Systems:
- UNIX administrators will coordinate with the Windows DNS admins to add host records manually for now.
- Once a system has joined the domain, the Centrify agent will ensure that the UNIX systems are in sync with the AD domain controller's time. This is is a Kerberos requirement.
Delegation (UNIX/Windows Admins and Security Analyst)
- Active Directory administrators will delegate the administration of the UNIX OU to the Unix/Linux Sysadmins. This will allow them to provision UNIX identities, create security groups, join systems to Active Directory, etc.
- If a GPO is required, it will require the intervention of the Windows Administrators to ensure the proper scope.
- Today the DNS and time services (NTP) are fragmented, there are duplicate services for each infrastructure (Windows/UNIX)
- UNIX systems that are integrated in to AD will use the AD DNS and time synchronization schemes to ensure proper authentication functionality.
Monitoring (UNIX/Windows Admins and Security Analyst)
- Failed Attempts to log in to Unix or Linux servers must be logged
- Privileged actions should be registered with the identity of the end user that performed it.
- Unix Administrators will require at a minimum Active Directory Users and Computers to review UNIX identities stored in AD.
- The Centrify tools will be installed in a shared server (APP1) as well as in the workstation for UNIX administrators (CLIENT1)
No comments:
Post a Comment