LDAP and Integrated Technologies: A Simple Primer Brian Kowalczyk, Kowal Computer Solutions Inc., IL Richard Kerwin, R.K. Consulting Inc.

LDAP and Integrated Technologies: A Simple Primer Brian Kowalczyk, Kowal Computer Solutions Inc., IL Richard Kerwin, R.K. Consulting Inc., IL ABSTRACT SAS Integration Technologies and LDAP(Lightweight Directory Application Protocol) allows users of SAS V9 to utilize a standard API to interface their SAS environment with a centralized LDAP store, and to authenticate and validate users; readily providing them with access to SAS software interfaces like SAS Enterprise Guide, SAS Enterprise Miner, and all of the functionality that the procedural scripting language, data sources, files systems and reporting interfaces that the SAS BI and SAS Analytical Platforms offer. By integrating application security for SAS with Enterprise wide LDAP, your SAS user community will have a centralized authentication repository which will enhance performance of the SAS Application Server, improve security, and provide the user community greater continuity. With users accessing the SAS Applications through the client applications SAS Enterprise Miner and SAS Enterprise Guide, they will not be logging directly into the host server and will no longer need to maintain a user identity on the Operating system. Host authentication at the user level will be a thing of the past, as users will not need to manage separate host ids. User identity, access, permissions and exclusions can be administered in one repository on the SAS Metadata Server, and user access and settings can be added, deleted, and modified on the fly. The industry standard interface LDAP is a great way to centralize authentication and reduce maintenance with the use of trusted accounts. You may have hundreds of SAS users who need to access data in a scalable server environment. You may want to avoid giving direct access to host servers. Also, you may not want to add hundreds of unsophisticated users on to hosts with unfamiliar operating systems. Nor would you want to add all those users again to any additional UNIX servers. Setting up the metadata server to use LDAP authentication is great way to achieve these goals. However, it does have its drawbacks: How do you manage access and security to Databases and file Systems on a diverse group of users who appear as one user to the host? What do you when need to identify a process on one of these servers that was submitted from an SAS Enterprise Guide session to a particular individual? For reasons such as these, some may steer away from using LDAP authentication, because of these perceived disadvantages. This paper discusses the advantages of using LDAP authentication and some simple methods to get around these perceived issues. INTRODUCTION Information Technology has recently witnessed an explosion of networked computing devices as companies have become increasingly reliant on distributed systems to support their business applications. This proliferation has resulted in an unprecedented growth in both clients and servers that are attached to a network. As the scale of networked resources and end users has grown, problems have emerged: It is frequently difficult for end users to locate needed resources on the network. Applications managers have difficulty sharing information about services, resources, and users because information is often stored in application-specific repositories. The environment is often difficult to administer because users must access resources from multiple platforms, and security must be administered in multiple places using different tools and applications. For these reasons, directory services like LDAP and Microsoft Active Directory are becoming an important part of enterprise computing. Directory services enables you to collect information that describes users, applications, file and print resources, access control, and other resources into a common directory that is accessible for all users and applications on the network. If your Enterprise uses the SAS Open Metadata Architecture and/or SAS Integrated Technologies, you can choose to use LDAP or Active Directory server as your authentication provider for SAS Web applications, SAS Metadata Servers, and SAS OLAP Servers. Lightweight Directory Access Protocol (LDAP) is very similar to Active Directory in that both are databases. However, LDAP is primarily a read-only Database, which differentiates it from other database types like Active Directory. The most common usage of LDAP in SAS is for authentication purposes. However it can also be used as a security interface that enables you to define a security hierarchy for the data stores in a data warehouse. This hierarchy can then be utilized to control access to data stores and SAS resources in much the same way that Access Control Lists (ACLs) control access to files. On large networks, where people use multiple machines, user management can be difficult. If users change passwords on one machine, they have to change them on all the other machines they use. With LDAP, you can change your password on one system, and this change is synced up on all other machines that use LDAP for authentication. Also, LDAP offers a greater 1

level of control over security and administrative events by giving Information Technology administrators and Security administrators a one-stop shop for locking down applications and individual ids. Since LDAP is a standard, your SAS installation can employ it with almost any operating system. In SAS, LDAP can handle user authentication and password management on Windows clients, Linux, Main Frames, and all UNIX systems. LDAP improves functionality because the LDAP directory is not specific to any one particular application. All directory-enabled applications in the enterprise can use it. This eliminates islands of information that are caused by applications that implement their own specialized repositories to manage resource information. It also eliminates the need to issue and manage host ids for every user on a machine. Furthermore, directory services like LDAP also greatly improve administration because the information is centrally managed. Any adds or changes that you make to the information in the directory are immediately available to all users and directory-enabled applications. In this presentation, we will focus on setting up LDAP as the primary sign-on authentication method vis-à-vis the Metadata server. We will also address some issues that arise when using this protocol, and ways we have found to work around these issues. THE EVOLUTION OF SAS 9 BUSINESS INTELIGENCE Each component of the SAS Intelligence Architecture leverages the sharing of common metadata and a common repository. Prior to SAS version 8, SAS programs were all run on the same computer as where the data was housed, whether that was on a PC, a UNIX server or a mainframe over a terminal connection. SAS/SHARE and SAS/CONNECT initially made it possible to connect clients to SAS servers over a network, but it was SAS Integration Technologies and the Integrated Object Model that truly turned the idea of SAS as a client-server system that could perform processing tasks over a wide variety of platforms into a reality. With Version 9, SAS expanded the use of IOM, which is primarily designed for thin client use. Applications like SAS Enterprise Guide and SAS Enterprise Miner communicate with SAS using IOM. Users needing access to SAS data and/or procedures can obtain it via the Web or through various user interfaces that can be built using common development tools like Visual Basic, C++ and even Microsoft Office. Furthermore, IOM provides remote users with access to the full capabilities of the SAS procedural language, as well as access to most relational database management systems. SAS has also responded to the domination of Microsoft on the business desktop by interfacing SAS and MS Office, via IOM, with SAS Add In for Microsoft Office. Most importantly, in SAS 9, SAS has brought platform integration and security together by pairing IOM and SAS Open Metadata Architecture together. METADATA SERVER A SAS Metadata Server is a multithreaded, multi-user SAS software server that enables multiple clients to use the same SAS process at the same time. The Metadata server listens for client applications and other processes over particular ports of communications, and spawns workspace servers, via IOM, when called upon. Each SAS client application attempts to communicate with the metadata server upon invocation. Because each client application attempts to communicate with the metadata server upon invocation, the Metadata Server is the best place for security and authentication to take place. AUTHENTICATION Authentication is the process of proving who you are to another entity. Most of the time, identification and authentication are paired via a user id and password: When you log on to most systems, you are asked for your user id and password. This identifies you to the system and allows you to prove who you say you are. Authorization is the concept of determining what you are allowed to do and what you are allowed to see. After your identity has been verified, the focus is on what you can do and what you cannot do. AUTHENTICATION DOMAIN An authentication domain is a metadata object that links logins to the servers for which the logins are valid. Each authentication domain should be associated with one or more servers and the logins that provide access to those servers, and all computing resources within an authentication domain need to use the same authentication provider. AUTHENTICATION PROVIDER An authentication provider is a technology that servers or applications use to verify that users are who they say they are. LDAP (Lightweight Directory Access Protocol) is the Authentication provider detailed here. 2

LDAP DIRECTORY SERVER AUTHENTICATION Figure 1 SEARCHING A DIRECTORY INFORMATION TREE Entries in an LDAP directory can be read directly if the exact DN is known. Usually, however, the directory is searched for entries that match a particular set of specifications. In order to perform a search, the directory server has to know the starting place in the tree (called the base), how deep in the tree the user wants to look (called the scope), and the search criteria (called the filter). The base can be any DN that is served by the directory server that is being queried. If the DN is outside the domain of the server, it may return a referral. The referral has the data that is necessary to connect to another server that may have more entries that match the filter. The client might decide either to chase (peruse possible filter matches on the other server) the referral or to ignore it. A search can also contain a scope. The scope determines how far down in the tree from the base the search is made. A scope of BASE will only return the base object if it exists and matches the filter. (The filter is required even with a scope of BASE). A scope of ONE will only search the base and entries immediately below the base entry. A scope of SUB will search the entire sub tree starting at the base entry. Limiting the scope of a search makes it more efficient. If you know that an entry is one level below the base, limiting the search to that scope makes it run faster. If you want to search all entries that are below the base then search the sub tree. A scope of BASE is used when you retrieve special entries. For example, most servers support a special entry with a DN of cn=monitor that returns information about the state of the server. When you search for that entry, a scope of BASE is required. The search filter determines which entries below the base will be returned. A simple filter is composed of an attribute name, an operator, and a value. LDAP SECURITY Users must exist within the Corporate LDAP in order to gain access to the SAS Analytic Platform Tools such as SAS Enterprise Miner and the SAS Enterprise Guide. The SAS Analytic Platform will be used to perform the actual authentication and in turn populate the racfid cookie with user id for verification by SAS Metadata against the LDAP. You must verify that your user community has been included in your Corporate LDAP directory. While the intent of the directory is to share much of the information in it across many applications, it must also be protected in order to prevent unauthorized access to sensitive data. Security within the directory is achieved using both authentication and access control. Authentication identifies a user's credentials to the directory server. Access control determines which entries a user is allowed to access based on that identity. Both of these topics are discussed next. LDAP AUTHENTICATION A user establishes a connection to a directory server by performing a bind operation. Part of the information that is used in performing this operation is the user's identity and password. There are three basic bind mechanisms anonymous, simple, 3

or secure. The simplest bind mechanism is an anonymous bind. Access is granted based on the user having no identity within the directory. While it is normal to provide read access to certain entries and attributes for anonymous users, most application data will be protected against retrieval by unknown users. A simple bind operation is performed when the user provides a DN for an entry within the directory and a password that goes with that entry. The entry must have a USERPASSWORD attribute, which is checked against the password provided. If the bind is successful, the user's identity will become that DN for the duration of the connection and access to entries will be based on that identity. While the simple bind is adequate for most environments, it requires that you send the password in clear text over the network. Some directory servers implement secure authentication methods, such as Kerberos or certificate-based authentication like SSL. Any authentication method that is used must resolve to a directory entry in order to permit a comparison with the access control list (ACL). After authentication, the ACL specifies access controls that are based on the DN for the user. ACCESS CONTROL There are literally as many access control schemes as there are directory servers. The OpenLDAP server keeps the access control lists in the configuration file and uses regular expressions for the comparison of ACL targets (what is being secured) and subjects (who is being allowed access) while Netscape and IBM keep the access control information in the directory tree as an attribute of the entries. However, the basic ideas are similar across server implementations. The ACLs can control access to the entire directory tree, or portions of it, down to the attribute level. Special access can be granted so that users can access their own DNs. A user may be allowed access to attributes on his own entry that no one else has access to, such as the USERPASSWORD attribute. There is usually a default access mode, and the ACLs are used to override that default. For instance, Netscape servers have a default access of none, so if there are no ACLs that are defined on a directory tree, no users can access it except the directory manager. ACLs can be added to allow access to parts of the tree or specific entries based on user DN or group membership. OVERVIEW OF LDAP DIRECTORY SERVER AUTHENTICATION When starting a server, you can enable LDAP users who specify a particular authentication provider domain to authenticate against an LDAP server instead of against the host. When a user logs in to a SAS client, authentication is performed in one of the following ways: If the user specified a distinguished name (DN), then the client uses that DN and the user's password to authenticate the user on the LDAP server. If the user specified a user id and if a DN and password are specified in the LDAP_PRIV_DN and LDAP_PRIV_PW environment variables, then the client uses the values of LDAP_PRIV_DN and LDAP_PRIV_PW to connect to the LDAP server and searches for a DN where the value for uid matches the user id. If the LDAP_IDATTR environment variable specifies an alternative attribute, then the client searches for that attribute instead of uid and performs authentication of the user by reconnecting to the LDAP server with the DN result from the previous step and the password that the user specified. However, if the user specified a user id and if a DN and password are not specified in the LDAP_PRIV_DN and LDAP_PRIV_PW environment variables, and then the client connects to the LDAP server anonymously and searches for a DN where the value for uid matches the user id. If the LDAP_IDATTR environment variable specifies an alternative attribute, then the client searches for that attribute instead of uid and performs authentication of the user by reconnecting to the LDAP server with the DN result from the previous step and the password that the user specified. IMPLEMENTING LDAP DIRECTORY SERVER AUTHENTICATION To implement authentication for LDAP, you must perform the following tasks: Ensure that LDAP users are defined and that the appropriate user credentials are set up on an LDAP directory server. Start the server with the appropriate options for alternative authentication. When starting the server, specify the following: On the server start command or in the service configuration (if you run on Windows as a service), specify the AUTHPROVIDERDOMAIN option with the authentication provider domain to use for LDAP authentication. For example, -authproviderdomain LDAP:orion.com where orion.com is the domain that will be specified when the user wishes to authenticate against LDAP. Set the following environment variables (using the appropriate procedure for your operating system): LDAP_PORT=<port number for LDAP. If LDAP_PORT is not specified, then the default value is 389.> LDAP_BASE=<base DN to use. For example: 4

ou=people, dc=orion, dc=com> LDAP_HOST= <the host name of the machine where LDAP is running> LDAP_IDATTR= <(optional) an alternative attribute to identify person entries. The default value is uid.> Note: To set environment variables on the z/os operating system, see Environment Variables for the z/os Operating System If your users connect with a user id instead of a DN, and the LDAP server does not allow anonymous connections, set the following environment variables: LDAP_PRIV_DN= <privileged DN that is allowed to search for users. For example, cn=useradmin> LDAP_PRIV_PW= <password for LDAP_PRIV_DN> For the LDAP_PRIV_PW variable, you can provide a password that is encoded by using the PWENCODE procedure. For more information, see The PWENCODE Procedure in Base SAS Procedures Guide. Define login credentials on the SAS Metadata Server. After authentication, the SAS Metadata Server searches for the user id and associated user definition (identity) in the SAS Metadata Repository. Therefore, you must have a user and login definition (that contains the LDAP authentication credentials) in the appropriate SAS Metadata Repository. (For details, see Defining Users, Groups, and Logins on the SAS Metadata Server). For user ids that authenticate against the LDAP server, create a login definition with a user id that has the following format: userid@authproviderdomain Ensure that users connect with the appropriate credentials for alternative authentication. When an LDAP user connects to the server, specify the authentication provider domain in the LDAP user connection request in order to associate the authentication provider domain with the LDAP authentication provider. To authenticate against LDAP, the LDAP user must log on with the following format: userid@authproviderdomain For example: Tom@orion.com where orion.com is the authentication provider domain that you specified for the LDAP server in the AUTHPROVIDERDOMAIN option. If you have used the AUTHPROVIDERDOMAIN option to configure the LDAP server as an alternative authentication provider (for example, LDAP: <AUTHPROVIDERDOMAIN>), all logins of the form userid@<authproviderdomain> will be sent to the LDAP server (as opposed to the host authentication provider) for authentication. For example: The following is an example of a Windows metadata server start command that specifies an alternative LDAP authentication provider: "where_your_sas_is_installed\sas.exe" -log "C:\sasoma\logs\sasoma.log" -logparm "write=immediate" -linesize max -pagesize max -nosplash -noterminal -memsize 0 -authproviderdomain LDAP:orion.com -objectserver -objectserverparms "protocol=bridge port=xxxx classfactory=2887e7d7-4780-11d4-879f-00c04f38f0db" To be authenticated by this provider, a user would specify a user id in the form: userid@orion.com SAS ENTERPRISE GUIDE PROCESS MONITORING When LDAP Authentication is used, multiple users log in to the host as a single generic id. This presents the managers of the SAS Environment with a difficult task: How can a SAS administrators determine who owns what processes, when every process runs as the host id? We have created a customized process to help trace processes back to their point of origin. SET UP FOR INDIVIDUAL PC RUNNING SAS ENTERPRISE GUIDE CLIENT On each individual PC where SAS Enterprise Guide is installed, macro code must be added to the EGAuto.sas file (path %APPDATA%\SAS\SAS Enterprise Guide\4\EGAuto.sas) that will send the following desktop environmental variables to a daily process log on the host each time a new workspace is spawned from an SAS Enterprise Guide Session: 1. Process initiation time. 2. Desktop user id 3. Host process id (pid) UNIX SERVER SET UP Three scripts will need to reside on the server that will facilitate the SAS Enterprise Guide process monitoring: 5

1. put_todays_file.sh: this script runs each night, at midnight and creates the daily process log. 2. active.sas: this program finds active workspace server processes that are associated with SAS Enterprise Guide sessions 3. sys_apps/sas913/processlogs/eg: this script greps through the information from active.sas and filters out to include only processes associated with the LDAP id parameter that was passed to the eg script. When logged into the UNIX server you can find all the spawned workspace server processes by simply running the eg command. The first and only required parameter of the eg command is the LDAP id for which you would like to see all associated processes. Make sure that you only specify the id. Do not put @ldap in the parameter. For example, if you would like to see all workspace server processes that are associated with SAS Enterprise Guide sessions spawned by Rich Kerwin, you could run the following from the server prompt: eg rkerwin When you run this command you might get the following information returned: 9:55 rkerwin 262604 11:35 rkerwin 303412 This specifies that a workspace server process with the process id of 262604 was started for Rich at 9:55 am CDT. There was also another server process with the process id of 303412 that was started for Rich at 11:35 am CDT. Please note that a workspace server process will begin when either the SAS Main icon is clicked on or code is first submitted through an SAS Enterprise Guide client and that workspace server process will remain open until either that SAS Enterprise Guide session is shut down or the user right clicks on the SAS Main icon and selects Disconnect. For example: 1. A user opens his SAS Enterprise Guide session and clicks on the SAS Main icon to see what SAS libraries are available to him at 9:55 am CDT. 2. He then begins working on an Excel spreadsheet for about 30 minutes. 3. He goes back to his SAS Enterprise Guide session and then submits code at 10:30 am. This code is running against the workspace server that was started at 9:55 am. 4. Now the user decides that he won t be working in SAS Enterprise Guide for some time, so he right clicks on the SAS Main icon and selects Disconnect. 5. He does some work in a Word document and then at 11:35am, He goes back into SAS Enterprise Guide and submits some code to run on SAS Main. At that point a new workspace server process is started at 11:35 am. In addition to displaying process information, the eg script might display nothing. If the script returns nothing, it most likely means that the id is not running any SAS Enterprise Guide processes or that the above mentioned PC set up was done improperly. The eg script can be run by any id that has the group sas and can be run from any directory. The way that the eg script works is that it first runs the /sys_apps/sas913/processlogs/active.sas program to find out active workspace server processes that are associated with SAS Enterprise Guide sessions. It then takes that information and filters out to include only processes associated with the LDAP id parameter that was passed to the eg script. Before the eg script can work properly, there needs to be a way for the server to collect information on workspace server processes spawned by SAS Enterprise Guide sessions. In order for the server to log information from all users, a process log file needs to be created and opened up for all users to write to. The following script needs to be scheduled to run the very first thing everyday in order to create this file: put_todays_file.sh If any SAS Enterprise Guide processes are spawned before the above script has been run for the day, the information from those processes will not be logged and will not be displayed when the eg script is executed. CONCLUSION When needing to integrate application security for a SAS V9 installation for license compliance, usage monitoring, login issues, and integration with SAS Client Components and the SAS Open Metadata Architecture, LDAP Authentication is a 6

solution worth investigating. Utilizing your company LDAP, you can avoid having users log directly into UNIX, while still maintaining a unique identity in the SAS Metadata, and on the SAS System. Users will no longer need to maintain multiple user host ids. Thus, LDAP allows a centralized, single point of authentication, and helps to minimize user maintenance on multiple servers. By using LDAP, you can avoid host authentication, but still manage individual user access centrally. Moreover, your users will have no need to periodically change their host ids, or maintain multiple passwords. As an added level of security, they will have no longer have need to directly access UNIX via Telnet or a secure Shell emulator. ACKNOWLEDGMENTS Special thanks to Paresh Patel of Shlomish Consulting Inc for assisting with details of the paper. CONTACT INFORMATION About the authors: The authors, Brian Kowalczyk and Rich Kerwin, are SAS Certified Professionals with expertise in architecture, application design and development, business intelligence, data warehousing, and training. They have over 25+ years of combined experience in the Financial, Health, Government, and Telecommunication industries. Brian T-Bone Kowalczyk Kowal Computer Solutions, Inc. Email: solutions_4u@sbcglobal.net Cell: 847.420.5669 Rich Kerwin RK Consulting, Inc. Email: r_k_consulting@sbcglobal.net Cell: 708.703.0609 SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. indicates USA registration. Other brand and product names are trademarks of their respective companies. 7