IBM Directory and Security Server (DSS) for OS/2 Warp

From OS2World.Com Wiki
Jump to navigation Jump to search
Article Info
Author Lee Terrell, Donna Skibbie
Date 1996-05-02
OS Version OS/2 Warp
Companion File N/A
Source Archived Article


Introduction to the DSS Security Services

IBM Directory and Security Server for OS/2 WARP (called DSS in this paper) integrates the world class IBM OS/2 LAN Server file and print sharing services with the distributed services of Open Software Foundation (OSF) Distributed Computing Environment (DCE). Through this integration, DSS is able to provide comprehensive and sophisticated services for distributed local and wide area networks.

This paper describes one significant group of services provided by DSS, which are the DSS security services. The intended audience of this paper is composed of:

  • Industry analysts
  • Technical press and media reporters
  • Information technology professionals

Benefits of the DSS Security Services

For existing LAN Server customers, a major benefit offered by the DSS security services is the use of a single registry database to define all the users in 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 cell and foreign cell with a single logon.

Other benefits offered by the DSS security services include:

  • A distributed and scalable method of controlling access to resources
  • 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) for configuring the security system
  • Interoperation with the following security services
    • LAN Server
    • WARP Server
    • Distributed Computing Environment (DCE)
  • Support for a staged migration from LAN Server or WARP Server to DSS security services

Configuration of the DSS Security Services

The DSS security services expect a network to be configured into one or more cells. A cell is a DSS administrative unit used to define all resources and users in a a line of business, region, or entire company. For example, a cell named Company X could be used to define all the resources and users in Company X.

If desired, the users and resources in a cell can be assigned to one or more resource domains. A resource domain is a DSS administrative unit that is used to group users and resources within a cell into a smaller work group. For example, some users and resources in the Company X cell can be assigned to a resource domain named Branch 1. The users and resources would be a part of the Company X cell and also would be a part of the Branch 1 resource domain group.

Configuration of a Cell

The DSS security services expect a cell to be configured with the following:

  • One master security server, which contains a master registry database of all users in the cell and is used to process requests for DSS security services.
  • One or more application servers, which contain resources (such as applications, printers, and files) that can be accessed by clients. The application servers can be any of the following types:
    • DSS
    • LAN Server
    • WARP Server
    • DCE
DSS servers have full support of all the DSS security services. Other types of application servers have partial support of the DSS security services and can interoperate with the DSS security services, as described in "Interoperation with LAN Server and WARP Server Security Services" and "Interoperation with DCE Security Services".
  • One or more clients, which can access resources on application servers. The clients can be any of the following types:
    • DSS
    • LAN Server
    • WARP Server
    • Distributed Computing Environment (DCE)
DSS clients have full support of all the DSS security services. Other types of clients have partial support of the DSS security services and can interoperate with the DSS security services, as described in "Interoperation with LAN Server and WARP Server Security Services" and "Interoperation with DCE Security Services".
  • (If required) One or more DSS domain controllers, which allow the DSS security services to interoperate with LAN Server or WARP Server security services, as described in "Interoperation with LAN Server and WARP Server Security Services". DSS domain controllers are required if the cell contains any LAN Server or WARP Server clients or servers.
  • (Optional) One or more replica security servers, which contain a read-only copy of the master registry database and, for performance and reliability reasons, can be used instead of the master security server to process any requests for DSS security services except for request to update the registry database.

Local and Foreign Cells

In some cases, it is necessary to configure more than one cell. For example, three regions that normally operate independently of each other could be configured as three separate cells within the same network. When a network contains more than one cell, the terms local cell and foreign cell are used. The local cell is the cell in which a user or resource is defined. A foreign cell is any other cell in the network.

For example, assume a network contains three cells--Region 1, Region 2, and Region 3-- and Fred is defined in Region 1. From Fred's perspective, Region 1 is the local cell, and Regions 2 and 3 are foreign cells.

Description of DSS Security Services

The DSS security services include:

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

The first two services--registry database and access control lists--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

To set up a DSS security system, the administrator needs to define all the users that can access the system. The administrator does this using the DSS registry database service. The DSS registry database service (which is the same as the DCE registry database service) provides the administrator with a single database that defines all users, groups, organizations, and accounts in a large DSS enterprise, which is referred to as a DSS cell.

The DSS GUI makes it easy for administrators 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 GUI automatically defines the following groups, which DSS will be use to control access to resources in the resource domain (as described in "Access Control Lists"):

  • resource_domains//ADMINS (administrators)
  • resource_domains/resource_domain_name/PRINT_OP (printer operators)
  • resource_domains/resource_domain_name/SVR_OP (server operators)
  • resource_domains/resource_domain_name/COMM_OP (serial device operators)
  • resource_domains/resource_domain_name/USERS (users)

The cell administrator can define users in each group and accounts for the users to use to logon to the cell. For example, the cell administrator can define a user named Mary that is in the resource_domains/corporate/administrators group and an account that Mary can use to logon to the cell. After doing this, Mary can logon to the cell and act as a resource domain administrator of the corporate resource domain.

Any administrator (cell or resource domain) can define the additional resource domains. Each time an administrator defines a resource domain, DSS will define groups for that resource domain. The administrator can define users for each of these groups and accounts for the users to use for logon. If desired, an administrator can use the GUI to order the groups so they appear logically to be organized in a resource domain hierarchy. The following figure illustrates a resource domain hierarchy:

                           res_domains
                                !
                                !
                     res_domains/corporate
                                !
                                !
____________________________________________________________________________
    !        !           !       !           !         !           !
    !        !           !       !           !         !           !
    !    res_domains/    !   res_domains/    !      res_domains/   !
    !     corporate/     !     corporate/    !        corporate/   !
    !     ADMINS         !     ADMINS        !        USERS        !
    !             res_domains/            res_domains/             !
    !                 corporate/           corporate/              !
    !                 PRINT_OP             SRV_OP                  !
    !                                                              !
    !                                                              !
    !                                                              !
res_domains/branch2                                    res_domains/branch2
     !                                                             !
     !                                                             !
     !                                                             !
   __________________________________________             __________________________________________
   !           !       !           !         !            !           !       !           !         !
   !           !       !           !         !            !           !       !           !         !
res_domains/   !    res_domains/   !      res_domains/ res_domains/   !    res_domains/   !       res_domains/
branch2/       !     branch2/      !        branch2/   branch2/       !     branch2/      !        branch2/
ADMINS         !     ADMINS        !        USERS      ADMINS         !     ADMINS        !        USERS
           res_domains/         res_domains/                      res_domains/         res_domains/
            branch2/             branch2/                          branch2/             branch2/
            PRINT_OP             SRV_OP                            PRINT_OP             SRV_OP

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 where the administrator must define a separate net.acc file for each domain and must define the user in the net.acc file of each domain the user will need to access.

Having only one registry database and only one definition for each user greatly simplifies the work of both the administrator and the user. The administrator's work is simpler because the administrator defines the user only in one place. If a change is required, such as deleting a user, this change needs to be made in only one place. The user's work is simpler because the user can use the same logon identity to access all the servers in the current cell, regardless of the resource domain, and in all foreign cells. If the user needs to make a change, such as changing a password, the user makes this change only once.

Having only one registry database also reduces the risk of security leaks, due to oversight. For example, in the LAN Server security system, if the user leaves the organization, the administrator must be careful to delete the user from each domain. Otherwise, the system will have a security leak. As another example, in the LAN Server security system, the user is required to keep track of the password that he/she uses to logon to each domain. Because users are required to keep track of many passwords, users might be tempted to keep written records of the passwords that co-workers could see, and this could cause a security leak.

Access Control Lists

After setting up the DSS registry database, the administrators and other privileged users need to define the users that have permissions to access each resource in the cell. The administrators and privileged users do this through the use of DSS access control lists, which are based on the DCE access control list model. In this model, an access control list is attached to each resource. The access control list defines the users and groups that have permission to access the resource and the type of permission each user and group has.

DSS supports access control lists for the following types of resources:

File directories
A file directory is a logical location where files are stored.
Files
A file is a collection of information that normally is stored on a disk and assigned a file name.
Print queues
A print queue is an ordered list of print jobs waiting to access a printer.
Serial devices
A serial device is a device that performs functions sequentially, such as a serial printer that prints one character at a time.
Server administration
Server administration is the ability to control the way an application server is used.
Removable media
A removable medium is a device that can be removed from the computer system, such as a floppy diskette or a CDROM
Named pipes
A named pipe is a two-way flow of data from one program to another that is referred to by a logical name.

The DSS GUI makes it easy to configure access control lists for these resources. When the cell or resource domain administrator uses the GUI to define define the resources that are in a resource domain, the GUI automatically defines a default access control list for each resource. In general, the default access control lists assigns the following permissions:

  • The resource_domain//ADMINS group has permission to control all resources in the resource domain.
  • The resource_domain//PRINT_OP group has permission to control all printer resources in the resource domain.
  • The resource_domain//COMM_OP group has permission to control all serial device resources in the resource domain.
  • The resource_domain//SVR_OP group has permission to control all file, directory, removable media, server administration, and named pipe resources in the resource domain.

After the default access control lists are defined, any member from a group containing control privileges to a resource can change the access control list for that resource. For example, any member of the resource domains/corporate/ADMINS or resource domains/corporate/SRV_OP group could add read permission for user John to the access control list for a file defined in the corporate resource domain. (However, only a cell or esource domain administrator can create or delete the definition for user John.)

The following table shows the types of permissions that can be assigned for each type of resource:

Table 1. Permissions by Resource Type

+--------------+--------+--------+--------+--------+--------+--------+--------+
! Resource     !  File  !  File  ! Print  ! Serial ! Server ! Remova ! Named  !
! Type ->      ! Direct !        ! Queue  ! Device ! Admin. !  ble   !  Pipe  !
! Permission   !  ory   !        !        !        !        ! Media  !        !
+--------------+--------+--------+--------+--------+--------+--------+--------+
! Control      !   Y    !   Y    !   Y    !   Y    !   Y    !   Y.   !   Y.   !
+--------------+--------+--------+--------+--------+--------+--------+--------+
! Read         !   Y    !   Y    !   N    !   Y    !   N    !   Y    !   Y    !
+--------------+--------+--------+--------+--------+--------+--------+--------+
! Write        !   Y    !   Y    !   N    !   Y    !   N    !   Y    !   Y    !
+--------------+--------+--------+--------+--------+--------+--------+--------+
! Execute      !   N    !   Y    !   N    !   N    !   N    !   Y    !   N    !
+--------------+--------+--------+--------+--------+--------+--------+--------+
! Insert       !   Y    !   N    !   Y    !   Y    !   N    !   Y    !   Y    !
+--------------+--------+--------+--------+--------+--------+--------+--------+
! Delete       !   Y    !   Y    !   Y    !   Y    !   N    !   Y    !   Y    !
+--------------+--------+--------+--------+--------+--------+--------+--------+
! Test         !   Y    !   Y    !   Y    !   Y    !   Y    !   Y    !   Y    !
+--------------+--------+--------+--------+--------+--------+--------+--------+
! Manage       !   N    !   N    !   Y    !   Y    !   Y    !   N    !   Y    !
+--------------+--------+--------+--------+--------+--------+--------+--------+

The meanings of these permissions vary, depending on the type of resource. In general, the meanings are as follows:

Control
permission to change the access control list permissions for the resource.
Read
Permission to read the contents of the resource.
Write
Permission to write to the resource.
Execute
Permission to execute the resource.
Insert
Permission to insert objects in the resource.
Delete
Permission to delete objects in the resource.
Test
Permission to test the access control list permissions that have been configured for a resource.
Manage
Permission to change the configuration of a resource.

It is important to note the difference between the DSS access control model (based on DCE) and the LAN Server model. With DSS, the access control list is attached to each resource. With LAN Server, the access control list 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 access control lists for users in the net.acc file to a DSS access control list attached to the appropriate resources.

The advantages of the DSS access control list model are:

  • A single way for users to use to interact with access control lists.
  • An open architecture, which does not limit the use and administration of access control lists to specific work stations.
  • A greater granularity in granting permissions than is provided by 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 access control lists from foreign users and foreign groups.
  • A GUI that makes it easy to configure access control lists.

Third-Party Authentication

For a DSS client to access a DSS server, the DSS client first must logon to 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 (discussed in the next section). If the security server is not able to authenticate the client, the security server retuns an error.

The following figure illustrates how the DSS client logon program and the security server exchange information using the third party protocol:

  DSS Client                                      Security Server
___________________________                      ___________________________
!                         !                      !                         !
!                         !                      !                         !
!  1. Create and encrypt  !  2. Send TGT request !  3. Decrypt and verify  !
!     TGT request.        ! -------------------> !     TGT request.        !
!                         !                      !  4. Prepare and encrypt !
!                         !  5. Return TGT       !     TGT.                !
!  6. Decrypt and verify  ! <------------------- !                         !
!     TGT.                !                      !                         !
!                         !                      !                         !
!  7. Create and encrypt  !  8. Send request for !  9. Decrypt and verify  !
!     request for access  !     access to PS.    !     request for access  !
!     to PS.              ! -------------------> !     to PS.              !
!                         !                      !  10.Encrypt ticket for  !
!                         ! 11. Return ticket    !     access to PS.       !
!  12.Decrypt encrypted   !     to access PS.    !                         !
!     ticket to access    ! <------------------- !                         !
!     PS.                 !                      !                         !
!                         ! 13.Send ticket to    !  14.Decrypt ticket to   !
!                         !    access PS.        !     access PS.          !
!                         ! -------------------> !  15.Prepare EPAC.       !
!                         !                      !  16.Prepare PTGT.       !
!                         ! 18.Return PTGT       !  17.Prepare PTGT        !
!                         !    envelope & EPAC.  !     envelope            !
! 19.Decrypt PTGT         ! <------------------  !                         !
!    envelope.            !                      !                         !
___________________________                      ___________________________
DSS Client

1. The DSS logon program prepares a request for a ticket granting ticket (TGT) for the client. The request contains two secret keys (key 1 and key 2) and a timestamp. Key 1 is encrypted in the user's machine identifier. Key 2 and the timestamp are doubly encrypted in the client's password and key 1.

2. The DSS logon program sends the encrypted TGT request to the security server authentication service.

Security Server (authentication service)

3. The security server authentication service decrypts the TGT request and validates the client's identity.

4. The security server authentication service prepares a TGT and encrypts it in key 2.

5. The security server authentication service sends the encrypted TGT to the DSS client.

DSS Client

6. The DSS logon program decrypts and verifies the TGT.

7. The DSS logon program prepares a request to access the Security Service privilege service and encrypts this request in key 1.

8. The DSS logon program sends the encrypted request to access the security server privilege service to the security server authentication service.

Security Server (authentication service)

9. The security server authentication service decrypts the request to access the security server privilege service and verifies that it is from the same user that sent the TGT request.

10. The security server authentication service prepares a ticket to access the the security server privilege service. The ticket contains the id of the user and key 2, and the ticket is encrypted in the secret key of the security server privilege service. The encrypted ticket is packaged in an envelope containing key 2, and the envelope is encrypted in key 1.

11. The security server authentication service sends the doubly encrypted envelope containing the ticket to access the security server privilege service to the DSS client.

DSS Client

12. The DSS logon program decrypts the encrypted ticket to access the privilege server and key 2 from the envelope.

13. The DSS logon program sends the encrypted ticket to access the security server privilege service to the security server privilege service.

Security Server (privilege service)

14. The security server privilege service decrypts the ticket.

15. The security server privilege service prepares an extended privilege attribute certificate (EPAC) containing information about the user and the groups of which the user is a member.

16. The security server privilege service prepares a privilege ticket granting ticket (PTGT) containing key 3 and an EPAC checksum, and encrypts the PTGT in the key of the security server authentication service.

17. The security server privilege service prepares an envelope containing key 3 and the encrypted PTGT. The envelope is encrypted in key 2.

18. The security server privilege service sends the encrypted envelope and EPAC to the DSS client.

DSS Client

19. The DSS client logon program decrypts the envelope. The DSS client holds onto the encrypted PTGT and the EPAC. The encrypted PTGT and EPAC will be used to establish a mutually secured session with a DSS server, as described in the next section.

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 shared secrets and timestamps. Therefore, the user and security server are always checking for impersonators. Because of the timestamp, impersonation techniques such as record and playback are not affective.
  • All information passed between the DSS user and the Security Server is encrypted and all plain text information is doubly encrypted.
  • The security server uses the DES (data encryption standard) 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 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 next), 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 following figure shows how DSS uses the SMB and DSS security protocols to establish a mutually authenticated session between a DSS client and DSS server when the client requests access to the server:

 Security Server             DSS Client                                      DSS Server
 ________________          ___________________________                      ________________________
 !              !          !                         !                      !                      !
 !              !          !                         !                      !                      !
 !              !          !                         !  1. Setup session &  !                      !
 !              !          !                         !     select protocol  !                      !
 !              !          !                         !     (DSS, LAN 4.0,   !                      !
 !              !          !                         !      LAN 3.0, etc.)  !                      !
 !              !          !                         ! -------------------> !                      !
 !              !          !                         !                      !                      !
 !              !          !                         !  2. Use DSS          !                      !
 !              !          !                         ! <------------------- !                      !
 !              !          !                         !                      !                      !
 !              !3a.Request!                         !                      !                      !
 !              !ticket to !                         !                      !                      !
 !              !DSS Server!                         !                      !                      !
 !              !<-------- !                         !                      !                      !
 ! Encrypt ticket          !                         !                      !                      !
 ! to DSS Server!          !                         !                      !                      !
 !              !3b.Ticket !                         !                      !                      !
 !              !to DSS    !                         !                      !                      !
 !              !Server    !                         !                      !                      !
 !              !--------->!3c.Create GSSAPI-encrypted                      !                      !
 !              !          ! token containing ticket !                      !                      !
 !              !          ! to DSS Server and EPAC. !                      !                      !
 !              !          !                         ! 4. GSSAPI token      !                      !
 !              !          !                         !--------------------> !                      !
 !              !          !                         !                      ! 5. Decrypt GSSAPI    !
 !              !          !                         !                      !    token.            !
 !              !          !                         !                      ! 6. Encrypt GSSAPI    !
 !              !          !                         !                      !    reply token with  !
 !              !          !                         !                      !    success message.  !
 !              !          !                         ! 7. GSSAPI reply token!                      !
 !              !          !                         ! <------------------- !                      !
 !              !          ! 8. Decrypt GSSAPI reply ! 9. Request session   !                      !
 !              !          !    token.               ! -------------------->!                      !
 !              !          !                         !                      !                      !
 !              !          !                         !10. Start session.    !                      !
 !              !          !                         ! <------------------- !                      !
 ________________          ___________________________                      ________________________
 
DSS Client

1. DSS sends an SMB request to the server to start a session and select a security protocol. The SMB request lists the security protocols supported by the client. These protocols include DSS security, LAN Server 4.0 security, and LAN server 3.0 security. (The names of these protocols are actually different, but, for clarity, this paper calls them the DSS, LAN Server 4.0, and LAN Server 3.0 protocols.)

DSS Server

2. Because the server supports the DSS security protocol and the DSS protocol is the best offered by the client, DSS sends an SMB response to the client informing the client that the server selects the DSS security protocol.

DSS Client

3. DSS uses GSSAPI to

a. Request a ticket from the security server authentication service to access a DSS server. The request contains an encrypted PTGT, the user ID of the DSS server, and a timestamp encrypted in key 3. The DSS client obtained the encrypted PTGT and key 3 when it performed third-party authentication, as described in the previous section.

b. Get a ticket from the security server to access the DSS Server. The ticket is encrypted in a secret key known only to the Security Server and the DSS Server.

c. Create an encrypted token containing the ticket, the EPAC of the DSS client, and a timestamp. The DSS client obtained the EPAC when it performed third-party authentication, as described in the previous section.

4. DSS sends an SMB message to the server containing a SecPkg message (an SMB standard). The SecPkg message contains the GSSAPI-encrypted token.

DSS Server

5. The DSS server uses GSSAPI to decrypt the GSSAPI encrypted token, determine whether the DSS client is authenticated, and, if so, create a GSSAPI-encrypted reply token containing an encrypted success message.

6. The DSS server sends an SMB message to the client containing a SecPkg message. The SecPkg message contains the GSSAPI-encrypted reply token.

DSS Client

7. The DSS client uses GSSAPI to decrypt the GSSAPI- encrypted reply token.

8. If the client is able to decrypt the reply token, the client authenticates the server. The client sends an SMB request to the server to establish a secure session. All communication between the client and server must be through this connection.

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

  • Both the DSS client and the DSS server are able to 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 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 EPAC of the DSS client to determine the id of the user and the ids of any groups of which the client is a member. (The client passed the EPAC to the server when the client established a secure session with the server, as previously described in "Mutually Authenticated Sessions.")
  2. Checks the access control list of the resource the client wants to access to determine whether the client has the proper permission to access the resource. (The access control list was configured as previouly described in "Access Control Lists.")

Note that in the DSS model, DSS checks the access control list of the resource to determine whether the user has permissions. This is in contrast to the LAN Server model, where LAN Server checks the access control list assigned to the user.

Auditing

In addition to protecting the system, the DSS security services have provisions for monitoring system and user activity. This is necessary because detecting and recording security events is as important as the system protection provided for by the access control mechanisms. Thus, the DSS audit services provide an important service in detecting potential and real attempts at defeating the security in the system. The auditing services writes security-relevant events to an audit log (that is, a file), so that a record is kept of the events for potential future analysis of suspicious system activity.

According to the Department of Defense (DoD) 'orange' book, the operating system shall be able to record (that is, audit) all security relevant events. For each recorded event, the audit record shall identify: date and time of the event, user, type of event, and success or failure of the event. For identification/authentication events the origin of request (for example, terminal ID) shall be included in the audit record. For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object. The system administrator shall be able to selectively audit the actions of any one or more users on individual identity.

The DSS auditing system is designed to comply with these requirements. DSS audit records contain information including:

  • the date/timestamp of the event entry
  • name of the requestor that established the session
  • name of the user that initiated the session

In cases of user resource access attempts, also included is the name of the resource owning the object (for example, files) accessed. In all cases, included is the completion code - success/failure - of the attempted operation.

The the audit log itself must be protected, by means of access control lists, from modification or unauthorized access or destruction. The audit data is protected so that read access to it is limited to those who are authorized for audit data.

Audit events for users and groups in the DSS resource domains are logged in the DSS audit log. Audit events for existing (or legacy) domains will only be audited in the LAN Server audit log and will not be migrated into DSS. The DSS administrator can establish which audit events go into the audit logs by creating audit filters. DSS audit (possible) events include:

  • user logon/logoff
  • invalid logon attempts
  • valid logons
  • invalid session setup
  • all session setups
  • users exceeding logon limit hours
  • file (or any) resource opens/accesses

The DSS auditing system is based on two models: the DCE model and the logon model.

DCE Model

The DSS system auditing design is modeled after and is based on the DCE technology. Pictorially, it is described in the following figure:


     ------------------     -----------------  Filter    -------------
     ! audit log file !     !   Audit       !  Requests  ! dcecp     !
     !                !<----!   Daemon      !<-----------!           !
     !                !     !               !            !cmd i/f    !
     !                !     !               !            !           !
     ------------------     -------A---------            -------------
                                   !
                                   !
         --------------------      !  audit api calls
         ! application / OS !      !
         !   client lib     !      !
         !                  !-------
         !                  !
         !                  !
         --------------------


DSS links in audit client library api's which, in turn, communicate with the audit daemon to record (or not record) a particular event based upon the audit event 'filters' that are in place. If a particular event is to be recorded, then a complete audit record is constructed and written to the audit log file. DSS auditable events include:

TGT Requests
  • TGT renewal requests
  • Account Adds/Deletes/Lookups/Replace
  • Account get policy requests
  • Principal/Group/Organization (PGO)
    • adds
    • deletes
    • replaces
    • renames
    • lookups
    • add group member
    • delete group member
    • replace group member
    • check group membership

Logon Model

There is a second model that needs discussion. Because the DCE technology from which the DSS product was built did not audit user logons, a second set of logic had to be developed. The following figure describes the logon process handling.

   DSS Logon Server                              DSS Client
-----------------------------------          ------------------
!  -------------    ------------  !          !   Logon        !
!  ! NETLOGON  !    ! lsauditd !<-!----------!                !
!  !           !    ------------  !          ! (lsauditc api) !
!  !           !---     !         !          ------------------
!  --A----------  !     !         !
!    !            !     V         !
!    !            !-> net.aud     !
!    !                            !
!    !                            !
-----!-----------------------------
     !
     !
     !         Legacy Client
     !       -----------------
     !       !   Logon       !
     !       !               !
     !-------!               !
             !               !
             -----------------

The lsauditd daemon is a detached process that allows DSS clients to remotely audit events in the LS audit log. The lsauditd daemon runs as a child process of the server. The lsauditd daemon accepts command line parameters for specifying what audit events to record in the log. Client processes may send events that are not currently being recorded (in the log), but this is unknown to the calling client. The lsauditd daemon does the event filtering. The lsauditd daemon can dynamically alter which events are being written to the log as the result of command line reconfigure options.

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 and the security server registry database. The replica security servers can be used to access security services and read from the security databases. 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. The performance gains are derived from the fact that a single security server is not solely responsible for handling all client-issued authentication and authorization requests. Successive requests to the security server are directed to available security servers.

Spreading security requests across multiple replicated servers reduces the probability of a service bottleneck, due to a single overloaded security server, and provides the opportunity for load balancing. For increased performance it is advisable to locate replica servers near users.

The reliability of the security service is improved due to the fact that a single system failure (or multiple failed systems) will not bring the cell security-related operations to a halt. In addition to the increased reliability, DSS tends to perform better as replicas are added. DSS cells have a single master security database. Replica security servers are read-only. This means that updates to the database is made only to the master and then propagated to the read-only replicas. For this reason, if a replica server is not unavailable, updates are queued and may not be propagated immediately. Once the replica server is returned to active status, the read-only replicas will be updated. This may result in some increase in network activity until the replica updating is complete.

The important point to note is that since the updates are queued, they are not lost, even if one of the replica databases is unavailable. The master database will attempt repeatedly to update the replica until it is successful. Should these attempts span a long period of time, the frequency of the update attempts will be decreased in order to reduce network traffic.

For increased reliability, it is advisable to have a replica on each network segment that could, because of the network topology, become unavailable. Should a network segment fail, the cell can continue to operate with the read-only replica security server.

Interoperation with LAN Server and WARP Server Security Services

The DSS security services are designed to interoperate with LAN Server and WARP Server clients and servers, without the need of of installing upgrades on the clients and servers. Before discussing this interoperation, it would help to discuss the LAN Server and WARP Server security services.

The LAN Server and WARP Server security services are identical. Therefore, from this point on, the term LAN Server security services will be used to define both LAN Server and WARP Server security services.

Description of LAN Server Security Services

A LAN Server network consists of one or more domains. Each domain consists of the following:

  • A domain controller
  • (Optional) a backup domain controller
  • One or more LAN Server clients
  • One or more LAN Server servers

To provide security in the network, LAN Server offers the following security services:

  • Security database
  • Authentication
  • Authenticated sessions and authorization
  • Auditing

This paper does not discuss the LAN Server auditing service.

LAN Server Security Database

The LAN Server administrator uses the net.acc file, located on the LAN Server domain controller to store all security information for each domain. The net.acc file is replicated on each LAN Server server so that each server in the domain contains a copy of the net.acc file. The net.acc file contains definitions of all users, groups, and accounts in the domain. It also contains access control information on each user. Passwords of users are stored in encrypted rather than plain text form.

It is important to note that the administrator must configure a different net.acc file for each domain. Also, the administrator must configure the user in each domain the user needs to access. This is different from the DSS model, where the administrator configures only one registry database for a cell, and the administrator needs to configure only one definition for each user.

Lan Server Authentication

After the administrator has set up the net.acc file with a user definition for a LAN Server client, the client can perform a logon (for example, with the NET LOGON command) to the LAN Server domain controller or to an individual LAN Server server in the domain. If the client performs the logon to the domain controller, the client can access all the LAN Server servers in the domain. If the client performs the logon to a server, the client can access only that server.

A separate net.acc file exists in each domain. Therefore, if a client needs to access servers in more than one domain, the administrator must configure a definition for the client in each domain the client needs to access and the client must perform a separate logon to each domain.

The following figure illustrates a LAN Server client performing a domain logon to the LAN Server domain controller:

LAN Server 4.0 client logon program                           LAN Server 4.0 domain controller
_________________________                                     ____________________
!                       !                                     !                  !
!                       !                                     !                  !
!                       !       1. Setup session and          !                  !
!                       !          select protocol            !                  !
!                       !          (LAN 4.0, LAN 3.0, etc.)   !                  !
!                       ! ----------------------------------> !                  !
!                       !                                     !                  !
!                       !       2. Use LAN 4.0 with my        !                  !
!                       !           random number challenge   !                  !
!                       ! <---------------------------------  !                  !
! 3. Calculate encrypted!                                     !                  !
!    password.          !                                     !                  !
!                       !                                     !                  !
! 4. Create proof.      !                                     !                  !
!                       !                                     !                  !
!                       !                                     !                  !
!                       !        5. Here is my proof.         !                  !
!                       !  -------------------------------->  !                  !
!                       !                                     !  6. Verify proof !
!                       !                                     !                  !
!                       !        7. Session OK                !                  !
!                       !  <-------------------------------   !                  !
!                       !                                     !                  !
!                       !                                     !                  !
!                       !        8. Set up client application !                  !
!                       !           environment               !                  !
!                       !  <------------------------------->  !                  !
!                       !                                     !                  !
!                       !                                     !                  !
!                       !        9. End session.              !                  !
!                       !  <------------------------------->  !                  !
_________________________                                     ____________________
  1. The LAN Server client logon program sends an SMB request to the domain controller to start a session and select a security protocol. In this request, the client lists the protocols it supports, such as LAN Server 4.0 and LAN Server 3.0.
  2. The LAN Server domain controller selects best protocol (the protocol that offers the highest amount of security), which in this case is LAN Server 4.0. The domain controller also sends the client a random number challenge.
  3. The LAN Server client logon program uses an encryption algorithm to encrypt the client's password. The resulting encrypted password is supposed to match the encrypted password stored in the net.acc file of the LAN Server domain controller.
  4. The LAN Server client logon program encrypts the encrypted client password with the random number challenge. This doubly encrypted client password is called a proof.
  5. The LAN Server client logon program sends the proof to the LAN Server domain controller.
  6. The LAN Server domain controller gets the encrypted client password from the net.acc file and encrypts it with the same previous random number challenge that the domain controller sent to the client. The domain controller then compares the result, which is a doubly encrypted password, with the proof received from the client. If the two match, the domain controller is able to verify the proof and, from that information, determines the client is an authentic user.
  7. Since the domain controller has determined the client is an authentic user, the domain controller sends a message to the client that the session is OK.
  8. The LAN Server client logon program and the domain controller send a series of messages to each other so the LAN Server client logon program can set up an application environment for the client. During this exchange of messages, the LAN Server client logon program might set up links for the client with other DSS servers (not shown in the figure).
  9. The LAN Server client logon program now has an application environment that it can use to establish sessions with other DSS servers in the domain, so the client ends the session.

LAN Server Authenticated Sessions and Authorization

After logging on to the domain, the LAN Server client can connect to LAN Server servers and access resources controlled by the servers (for example, by issuing the NET USE command). The LAN server client does this is much the same way as the client performed the logon. The only differences are:

  • The client no longer needs to encrypt the password (the encrypted password from the logon can be used) or set up an application environment.
  • If the client wants to access a resource, the server checks the net.acc file to determine whether the client is authorized to make the request.
  • The session continues until the request handled by the client is processed.

The following figure illustrates a LAN Server client issuing a request to a LAN Server server:

LAN Server client                                              LAN Server server
_________________________                                     ____________________
!                       !                                     !                  !
!                       !                                     !                  !
!                       !       1. Setup session &            !                  !
!                       !          select protocol            !                  !
!                       !          (LAN 4.0, LAN 3.0, etc.)   !                  !
!                       ! ----------------------------------> !                  !
!                       !                                     !                  !
!                       !       2. Use LAN 4.0 with my        !                  !
!                       !           random number             !                  !
!                       ! <---------------------------------  !                  !
!                       !                                     !                  !
!                       !                                     !                  !
!                       !                                     !                  !
! 3. Create proof.      !                                     !                  !
!                       !                                     !                  !
!                       !                                     !                  !
!                       !        4. Here is my proof.         !                  !
!                       !  -------------------------------->  !                  !
!                       !                                     !  5. Verify proof !
!                       !                                     !                  !
!                       !        6. Session OK.               !                  !
!                       !  <-------------------------------   !                  !
!                       !                                     !  7. Determine if !
!                       !                                     !     user is      !
!                       !                                     !     authorized.  !
!                       !        8. Handle request            !                  !
!                       !  <------------------------------->  !                  !
!                       !                                     !                  !
!                       !        9. End session.              !                  !
!                       !  <------------------------------->  !                  !
_________________________                                     ____________________

Migration of LAN Server Security Services to DSS

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 allows the administrator to set the pace of migration.

Stage 1 Migration

In a Stage 1 migration, the administrator adds a master security server and, if desired, one or more replica security servers. The administrator also migrates each LAN Server domain controller to a DSS domain controller. The resulting configuration consists of the following:

  • A master security server
  • (Optional) One or more replica security servers
  • One DSS domain controller for each domain
  • One or more LAN Server clients
  • One or more LAN Server servers

When the administrator performs this migration, he/she uses migration utilities to migrate all the information from the net.acc file of each LAN Server domain controller to the DSS registry database and DSS access control lists of the DSS domain controller. After performing a Stage 1 migration, the LAN Server clients and LAN Server can use the following DSS security services:

  • Registry database
  • Access control list databases
  • Auditing
  • Replication

To support a Stage 1 migration, DSS must provide a way for LAN Server clients to perform a cell logon using the DSS domain controller, without the LAN Server clients being aware of the cell or DSS. DSS supports this through the registry synchronization task, which resides on the DSS domain controller.

The following figure illustrates a LAN Server client performing a cell logon to a DSS domain controller.

   LAN Server client                                 DSS Domain Controller
                                                     with Registry Sync            Security Server
_________________________                            __________________          ____________________
!                       !                            !                !          !                  !
!                       !                            !                !          !                  !
!                       ! 1. Setup session and       !                !          !                  !
!                       !    select protocol         !                !          !                  !
!                       !    (LAN 4.0, LAN 3.0, ..)  !                !          !                  !
!                       !--------------------------- !                !          !                  !
!                       !                            !                !          !                  !
!                       ! 2. Use LAN 4.0 with my     !                !          !                  !
!                       !     random number challenge!                !          !                  !
!                       !<-------------------------- !                !          !                  !
! 3. Calculate encrypted!                            !                !3.Get info!                  !
!    password.          !                            !                !  on user !                  !
!                       !                            !                !--------->!                  !
!                       !                            !                !          !                  !
!                       !                            !                !4. Info   !                  !
!                       !                            !                !   on user!                  !
!                       !                            !                !<---------!                  !
!                       !                            !5. Create EPAC  !          !                  !
!                       !                            !                !          !                  !
!                       !                            !                !          !                  !
! 6. Create proof.      !                            !                !          !                  !
!                       !                            !                !          !                  !
!                       !                            !                !          !                  !
!                       !  7. Here is my proof.      !                !          !                  !
!                       !--------------------------> !                !          !                  !
!                       !                            ! 8.Verify proof !          !                  !
!                       !                            !                !          !                  !
!                       !  9. Session OK.            !                !          !                  !
!                       !<-------------------------  !                !          !                  !
!                       !                            !                !          !                  !
!                       ! 10. Setup client           !                !          !                  !
!                       !     application environment!                !          !                  !
!                       !<-------------------------> !                !          !                  !
!                       !                            !                !          !                  !
!                       ! 11. End session.           !                !          !                  !
!                       !<-------------------------> !                !          !                  !
_________________________                            _________________           ___________________

To support a Stage 1 migration, DSS must also provide a way for a LAN Server client to establish a session with a LAN Server server, without the client or server being aware of DSS or the fact that the registry database is actually located on the DSS server rather than the net.acc file and the access control lists are actually located in resource-connected access control databases rather than the net.acc file. DSS supports this through the registry synchronization task at the DSS domain controller.

The registry synchronization obtains the information for the net.acc file from the security server registry database. (Extended attributes in the registry database contain LAN Server-specific information on each user, such as access control list information of each user and the encyrypted password of each user.)

The following figure illustrates a LAN Server client establishing a connection to a LAN Server server, using the registry synchronization task to update the net.acc file with information from the security server registry database:

                                                                                            DSS domain controller
   LAN Server client                                          LAN Server server             with registry sync             Security Server
_________________________                                   ____________________          ____________________           ____________________
!                       !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !1.Get latest                  !
!                       !                                   !                  !          !                  ! info from !                  !
!                       !                                   !                  !          !                  ! registry  !                  !
!                       !                                   !                  !          !                  ! database  !                  !
!                       !                                   !                  !          !                  !---------->!                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !2.Latest   !                  !
!                       !                                   !                  !          !                  !  info     !                  !
!                       !                                   !                  !          !                  !<----------!                  !
!                       !                                   !                  !          ! 3.Update net.acc !           !                  !
!                       !                                   !                  !          ! file with latest !           !                  !
!                       !                                   !                  !4.Send    ! info             !           !                  !
!                       !                                   !                  !updated   !                  !           !                  !
!                       !                                   !                  !net.acc   !                  !           !                  !
!                       !     5. Set up session             !                  !<-------- !                  !           !                  !
!                       !        and select protocol        !                  !          !                  !           !                  !
!                       !   (LAN 4.0, LAN 3.0, etc.)        !                  !          !                  !           !                  !
!                       ! --------------------------------> !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !     6. Use LAN 4.0 with my        !                  !          !                  !           !                  !
!                       !         random number challenge   !                  !          !                  !           !                  !
!                       ! <-------------------------------  !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
! 7. Create proof.      !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !      8. Here is my proof.         !                  !          !                  !           !                  !
!                       !  ------------------------------>  !                  !          !                  !           !                  !
!                       !                                   !  9. Verify proof !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !     10. Session OK                !                  !          !                  !           !                  !
!                       !  <-----------------------------   !                  !          !                  !           !                  !
!                       !                                   ! 11. Determine if !          !                  !           !                  !
!                       !                                   !     user is      !          !                  !           !                  !
!                       !                                   !     authorized.  !          !                  !           !                  !
!                       !     12. Handle request            !                  !          !                  !           !                  !
!                       !  <----------------------------->  !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !     13. End session.              !                  !          !                  !           !                  !
!                       !  <----------------------------->  !                  !          !                  !           !                  !
_________________________                                   ____________________          ____________________           ____________________

Stage 2 Migration

In Stage 2, the administrator migrates one or more LAN Server servers to DSS servers. The resulting configuration consists of the following:

  • A master security server
  • (Optional) One or more replica security servers
  • One DSS domain controller for each domain
  • One or more LAN Server clients
  • One or more LAN Server servers
  • One or more DSS servers

After performing a Stage 2 migration, the DSS servers are able to use all the security services.

Stage 3 Migration

In Stage 3, the administrator migrates one or more LAN Server clients to DSS clients. The resulting configuration consists of the following:

  • A master security server
  • (Optional) One or more replica security servers
  • One DSS domain controller for each domain
  • One or more LAN Server clients
  • One or more LAN Server servers
  • One or more DSS servers
  • One or more DSS clients

After performing a Stage 3 migration, the DSS clients are able to use all the security services.

To support a Stage 3 migration, DSS must provide a way for DSS clients to establish a session with LAN Server servers. DSS supports this through the use of the registry synchronization task.

                                                                                            DSS domain controller
   DSS client                                                 LAN Server server             with registry sync             Security Server
_________________________                                   ____________________          ____________________           ____________________
!                       !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !1.Get latest                  !
!                       !                                   !                  !          !                  ! info from !                  !
!                       !                                   !                  !          !                  ! security  !                  !
!                       !                                   !                  !          !                  ! databases !                  !
!                       !                                   !                  !          !                  !---------->!                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !2.Latest   !                  !
!                       !                                   !                  !          !                  !  info     !                  !
!                       !                                   !                  !          !                  !<----------!                  !
!                       !                                   !                  !          ! 3.Update net.acc !           !                  !
!                       !                                   !                  !          ! file with latest !           !                  !
!                       !                                   !                  !4.Send    ! info             !           !                  !
!                       !                                   !                  !updated   !                  !           !                  !
!                       !                                   !                  !net.acc   !                  !           !                  !
!                       !     5. Setup session &            !                  !<-------- !                  !           !                  !
!                       !        select protocol            !                  !          !                  !           !                  !
!                       !   (DSS, LAN 4.0, LAN 3.0, etc.)   !                  !          !                  !           !                  !
!                       ! --------------------------------> !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !     6. Use LAN 4.0 with my        !                  !          !                  !           !                  !
!                       !         random number challenge   !                  !          !                  !           !                  !
!                       ! <-------------------------------  !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
! 7. Create proof.      !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !      8. Here is my proof.         !                  !          !                  !           !                  !
!                       !  ------------------------------>  !                  !          !                  !           !                  !
!                       !                                   !  9. Verify proof !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !     10. Session OK.               !                  !          !                  !           !                  !
!                       !  <-----------------------------   !                  !          !                  !           !                  !
!                       !                                   ! 11. Determine if !          !                  !           !                  !
!                       !                                   !     user is      !          !                  !           !                  !
!                       !                                   !     authorized.  !          !                  !           !                  !
!                       !     12. Handle request            !                  !          !                  !           !                  !
!                       !  <----------------------------->  !                  !          !                  !           !                  !
!                       !                                   !                  !          !                  !           !                  !
!                       !     13. End session.              !                  !          !                  !           !                  !
!                       !  <----------------------------->  !                  !          !                  !           !                  !
_________________________                                   ____________________          ____________________           ____________________

Interoperation with DCE Security Services

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. This interoperability could be used in the following ways:

  • A DSS administrator could add DCE users, groups, and organizations to the registry database so that DCE users are able to logon to the DSS cell.
  • A DSS administrator or operator could add DCE users and groups to the access control lists of DSS resources so that the DCE users and groups can access the DSS resources.
  • 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, establish a secure connection. The application could establish a secure connection using either of the following methods:
    • Authenticated remote procedure call (RPC). Using this method the developer can choose the level of security desired, with the highest level being that of encrypting all data exchanged between the client and server.
    • GSSAPI
  • A DSS administrator could configure extended registry attributes in the registry database supporting data required by other security systems.