Secure Your Enterprise

From EDM2
Jump to: navigation, search

by Donna Skibbie and Lee Terrell

This article provides an overview of the Security Services component of the IBM Directory and Security Server (DSS) for OS/2 Warp. The complete article (DSSSEC.HTM) is available on the DevCon Home Page. The complete article provides information about how to configure DSS security services and gives more detail about each of the DSS security services. It also describes how the DSS security services interoperate with LAN Server security services.

The Directory and Security Server (DSS) for OS/2 Warp integrates the world-class file-and-print-sharing services of IBM OS/2 LAN Server with the sophisticated, distributed services of Open Software Foundation (OSF) Distributed Computing Environment (DCE). The DSS security services allow the network administrator to set up a system in which clients and servers on a distributed network can communicate with each other securely.

For existing LAN Server customers, a major benefit of the DSS security services is the ability to use a single registry database to define all the users and resources in an administrative unit called a DSS cell. Using the single registry database, the administrator creates and maintains only one definition for each user, and the user can access all resources in the local cell and foreign cell with a single logon. Other benefits include:

  • A distributed, scalable method of controlling resource access
  • Sophisticated protocols for authenticating and establishing sessions with clients
  • A means of auditing the network for unauthorized use
  • An option to improve performance by replicating the security server
  • An easy-to-use graphical user interface (GUI)
  • Interoperation with LAN Server, Warp Server, and DCE security services
  • Support for a staged migration from LAN Server or Warp Server to DSS security services

Description

The DSS security services include:

  • Registry database
  • Access control lists (ACLs)
  • Third-party authentication
  • Mutually authenticated sessions
  • Authorization
  • Auditing
  • Replication

The first two services, registry database and ACLs, are for setting up the security system. The next three services, third-party authentication, mutually authenticated sessions, and authorization, are for using the security system. The last two services, auditing and replication, are for monitoring and improving the performance and reliability of the security system.

Registry Database

The administrator s first task in setting up a DSS security system is to define all the users that can access resources in the system. The administrator defines user access using the DSS registry database service. The DSS registry database service provides the administrator a single database that defines all users, groups, organizations, and accounts in a DSS cell. DSS provides a GUI, which makes it easy for administrators to set up a registry database and organize users into groups that conform to the DSS resource domain structure. The cell administrator uses the GUI to configure the first resource domain in the cell.

When the cell administrator configures the resource domain, the groups to use in controlling access to resources are automatically configured. For example, an administrator s group is configured to perform general administrative functions in the resource domain, and a printer operator s group is configured to perform printer operations in the resource domain. The cell administrator then can define users in each group. For example, the cell administrator can define a user named Mary in the administrator s group. After defining Mary to the administrator s group, Mary can log onto the cell and act as an administrator in the resource domain. After the cell administrator defines the first resource domain, the administrators in that domain can define other resource domains in the same way the first resource domain was configured.

For administrators who are migrating LAN Server domains to resource domains in a DSS cell, DSS includes a registry migration utility. This utility makes it easy for the administrator to migrate the users and groups from the NET.ACC files of LAN Server domains to the registry database of the DSS cell. Although DSS supports many resource domain groups, it is important to note that DSS uses only one registry database and only one definition for each user in the registry database. For example, although Mary can be a member of many resource domain groups, the registry database contains only one user definition for Mary. This model is in contrast to LAN Server, which requires the administrator to define a user in each domain the user needs to access.

Having only one registry database and only one definition provide the following advantages:

  • The administrator's job is simpler because the administrator needs to maintain only one definition for each user.
  • The user s job is simpler because the user can use one logon identity to access all the application servers in the local cell and all foreign cells.
  • The risk of security leaks due to oversight is decreased because the security system is simpler to maintain and use.

Access Control Lists

After setting up the DSS registry database, the administrators and other privileged users configure ACLs for resources. An ACL defines the users and groups that have permission to access a resource and defines the type of permission each user and group has. For example, an ACL for a file could define that all users in the group XYZ have permission to read a file, but that only users Mary and John have permission to write to the file and only user Mary has permission to alter the ACL for the file.

DSS supports ACLs for:

  • File directories
  • Files
  • Print queues
  • Serial devices
  • Server administration
  • Removable media
  • Named pipes

DSS makes it easy to configure ACLs for these resources. When the cell or resource domain administrator defines the resources that are in a resource domain, a default ACL for each resource in the domain is automatically defined. Then, if desired, the administrator or another privilege user can revise the default ACLs to meet their specific needs.

For LAN Server users, it is important to note the difference between the DSS access control model and the LAN Server model With DSS, the ACL is attached to each resource. With LAN Server, the ACL is attached to each user. For LAN Server networks that are upgrading to DSS, DSS offers a migration utility that administrators can use to migrate the ACLs for users in the NET.ACC file to a DSS ACL attached to the appropriate resources.

The advantages of the DSS ACL model are:

  • A single way for users to interact with ACLs
  • An open architecture, which does not limit the use and administration of ACLs to specific workstations
  • A greater granularity in granting permissions than is provided by most personal computer networks available today For example, permissions can be assigned to each resource, and permissions such as control and test are available
  • Support of entries in ACLs from foreign users and foreign groups
  • A GUI that makes it easy to configure ACLs

Third-Party Authentication

For a DSS client to access a DSS server, the DSS client first must log onto the cell. When the client logs on, DSS uses the DCE third-party authentication protocol to determine whether the client is an authentic user. The third-party protocol is based on the Kerberos protocol, originally developed by MIT. It offers the highest protection of all authentication protocols available.

Using the third-party protocol, the DSS client logon program requests a trusted third party (the security server) to authenticate the client. The client logon program makes this request by initiating an exchange of messages between the client and security server, in which both must prove their identities to each other. During this exchange, the client logon program and the security server use shared secrets, known only by the client and server, to encrypt the information. The first shared secret is the client's password and machine identifier. Other shared secrets are keys (random numbers) passed between the client and server. If, after this exchange, the security server is able to authenticate the client, the security server returns authentication information, which the DSS client can use to establish a session with a DSS server. If the security server is not able to authenticate the client, the security server returns an error.

The DSS third-party authentication protocol offers the following security advantages:

  • The DSS user must be authenticated by the security server, through the use of secrets shared only between the client and the security server In networks requiring tight security, the security server could be monitored to be sure that no unauthorized users have physical access to it.
  • The DSS user and the security server continually verify each other's identity through the use of timestamps and shared secrets Therefore, the user and security server are always checking for impersonators. The timestamp makes impersonation techniques such as record and playback not affective.
  • All information passed between the DSS user and the security server is encrypted, and text information is doubly encrypted
  • The security server uses the data-encryption standard (DES) algorithm to encrypt information, which is a highly regarded encryption standard.

Mutually Authenticated Sessions

After the DSS client completes a successful logon, the client can request access to DSS servers. For example, the client can issue the NET USE command to access a DSS server for the purpose of reading a disk drive controlled by the server. When the client requests access to a DSS server, DSS attempts to establish a mutually authenticated session between the DSS client and the DSS server. If the mutually authenticated session succeeds, DSS proceeds to authorization (discussed below), if necessary If the session fails, DSS returns an error to the client.

To establish the mutually authenticated session, DSS uses a combination of the server message block (SMB) protocol and the DSS security protocol. The SMB protocol is an X/Open standard that LAN Server and many other network software products use to establish sessions. When using the SMB protocol, the client and server must negotiate a security protocol to use in securing the session. A DSS client and DSS server select the DSS security protocol. The DSS security protocol is based on the DCE generic security service application programming interface (GSSAPI) protocol and offers a higher degree of protection than other security protocols that can be negotiated with SMB.

The DSS protocol for establishing mutually authenticated sessions offer the following security advantages:

  • DSS client and DSS server can mutually authenticate each other.
  • All security information passed between the DSS client and DSS server is encrypted in GSSAPI tokens. The DSS client passes an extended privilege attribute certificate (EPAC) to the DSS server (encrypted in a GSSAPI token), so the DSS server does not need to keep a database on users.

Authorization

If the DSS client requests access to a resource, the DSS server must determine whether the client has permission to access the resource in the way the user wants to access the resource. For example, if the DSS client wants to write to a file, the DSS server must determine if the client has permission to write to the file.

DSS uses the DCE authorization model to determine whether users have permission to access resources. Using this model, DSS:

  1. Checks the security information of the DSS client to determine the ID of the user and the IDs of any groups of which the client is a member.
  2. Checks the ACLs of the resource the client wants to access to determine whether the client has the proper permission to access the resource.

Auditing

DSS provides auditing services, which allow an administrator to monitor the security system and detect attempts to defeat it. Some possible events the administrator might want to monitor are:

  • User logon and logoff
  • Invalid logon attempts
  • Valid logons
  • Invalid session set up
  • All session set ups
  • Users exceeding logon limit hours
  • File (or any) resource opens and accesses

Replication

An administrator can choose to configure one or more replica security servers. A replica security server is a read-only copy of the security server. The replica security servers can be used to access security services and read from the registry database. However, updates to the registry database can take place only at the master security server.

Configuring replica security servers offers two benefits, better performance and greater reliability. Performance is improved because multiple security servers can be used to handle security requests. Reliability is improved because the failure of a single security server will not bring all security operations to a halt.

Interoperation with Other Security Services

The DSS security services are designed to interoperate with LAN Server and Warp Server clients and servers, without needing to install upgrades on the clients and servers. For the administrator who wants to migrate the LAN Server security services to DSS, DSS provides a staged migration path. The administrator can perform one or more stages, and the administrator can time these stages as needed. This feature allows the administrator to set the pace of migration. Also, because the DSS security services are based on DCE, and because DSS supports all the DCE application programming interfaces (APIs) and command-line interfaces, the DSS security services are able to interoperate with the DCE services. For example, an application developer could develop an application in which DSS clients and servers interact with DCE clients and servers (using the DCE APIs to perform the cell logon) to establish a secure connection.

Summary

The DSS security services provide sophisticated, scalable, and easy-to-administrate protection services required on distributed local-area networks (LANs) and wide-area networks (WANs). They can interoperate with existing LAN Server and Warp Server clients and application servers, without needing to install upgrades on the clients and application servers. They also can interoperate with DCE clients and application servers.

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

Retrieved from "http://www.edm2.com/index.php?title=Secure_Your_Enterprise&oldid=78546"