CertiGuide to Security+  9  Chapter 5:  Operational/Organizational Security (Domain 5.0; 15%)       9  5.5  Privilege Management

5.5.1  User / Group / Role Management 1 5.5.3  Centralized vs. Decentralized

Network Operating Systems were designed to behave independently of other systems. For example, in the Windows world, if a user wanted a resource in a domain that was different than the domain they are held in, the administrator had to tell the second domain to be trusting of the fact that the first domain provided proper security, so that the user did not have to have separate sets of user ID’s and passwords, one per domain. The alternative was to have that user also have user and group membership on the second domain, this increased administration overhead.

The situation grows more complex when today’s multi-vendor networks and complex applications are taken into account. A user might require access to the organization’s UNIX machine, NT file servers, and several database applications. Maintaining different accounts for the user on each platform is a headache for network administrators, and keeping track of an entire handful of user ID/password combinations a headache for users.

With Single Sign-on, instead of using a password to verify a user when accessing data protected by an Access Control List (ACL), the client’s identity is often verified using a certificate. The idea behind single sign-on is to require the client to authenticate just once (presenting credentials like a smart card or even a user ID and password, if certificates are not used), and have this identity automatically relayed to each server/application the client accesses, when authorization is required, without the user having to perform extra steps.

5.5.1  User / Group / Role Management 1 5.5.3  Centralized vs. Decentralized