2009 International Conference on Computer Engineering and Technology
Profile Management and Authentication using LDAP Mohammed A Qadeer, Mohammad Salim, M Sana Akhtar Department of Computer Engineering Zakir Hussain College of Engineering & Technology Aligarh Muslim University, Aligarh- 202002 {maqadeer, mohdsalim, msakhtar}@zhcet.ac.in A server can store directory data locally, or simply access to external sources. Typically, it provides authentication and searching services, and may also support adding, removing and modifying directory data. It provides finegrained access control to the directory.
Abstract-- In this paper, we present the technique to manage user profiles and authentication using LDAP (Lightweight Directory Access Protocol). The User profiles maintained in the LDAP Directory Information Tree (DIT) which contains various information about users. This information can be retrieved by the users depending upon the level of access provided to them on the network. Various services use this authentication mechanism to allow the authorized users, who provide correct authentication information as stored in the LDAP Server, to use the corresponding services. Virtual Private Network (VPN), Remote Access Server (RAS), Web Server, Mail Server can use LDAP for authenticating users.
•
Clients access LDAP servers over LDAP network protocol. They function by requesting that the server performs operations on their behalf typically, a client will first connect to the directory server, then bind (authenticate) and then perform zero or more operations before finally unbinding and disconnecting.
Keywords- LDAP; client; server; SLAPD; schemas; database; ACLs; authentication; LDIF; Web Server; VPN; RAS; SendMail
I.
•
•
•
III. CONFIGURING THE SLAPD SERVER SLAPD has one main configuration file called slapd.conf . It contains basically three parts : (i) Basic part, (ii) Database Configuration part, and (iii) Access Control Lists (ACLs)
Provide LDAP services Manipulate the LDAP data Support LDAP servers Provide programming interfaces to LDAP
A.
Basic part
Include /etc/ldap/schema/core.schema include/etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema
The Server
The main server in the LDAP suite is SLAPD (the StandAlone LDAP Daemon). This server provides access to one or more directory information trees. Clients connect to the server over the LDAP protocol using a network– based connection. 978-0-7695-3521-0/09 $25.00 © 2009 IEEE DOI 10.1109/ICCET.2009.126
Libraries There are several LDAP libraries that are shared between LDAP applications. The libraries provide LDAP functions to these applications. The clients, utilities and servers all share access to some of these libraries.
II. TECHNICAL OVERVIEW : : : :
Utilities Utilities manipulate data at a lower level, and without mediation by the server. They are used primarily to help maintain the server.
INTRODUCTION
LDAP is designed to provide a digital directory which is an online equivalent of a telephone directory or address book. It is a type of database in which data can be organized into tree structures, like a file system hierarchy. A robust layer of services are provided by LDAP like searching with complex filters, representing complex entities with attributes, allowing restricted access to data and so on – that provides sophisticated directory services. Various applications like email servers, web servers, etc. use LDAP as an authoritative source of user information. Applications can authenticate users against the directory[1].
A. Components: Servers Clients Utilities Libraries
Clients
pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel none
247
Authorized licensed use limited to: ZAKIR HUSSAIN COLLEGE OF ENG AND TECH. Downloaded on March 2, 2009 at 05:56 from IEEE Xplore. Restrictions apply.
C.
modulepath /usr/lib/ldap moduleload back_hdb
The Access Control Lists (ACLs) defines various controls that a user can exercise and has been explained as under : access to attrs=userPassword
It contains lines with include directives which attempt to load the indicated schema files .These files are then treated as part of the current configuration file. Schemas provide definitions of the different object classes and attribute types that LDAP should support. Using these, LDAP can determine what entries it is allowed to store, whether any given entry is valid, and how entries should be stored . There are various schemas for defining various attributes of the users as per the needs of the organization and the type of the data to be represented.
The two directives, pidfile and argsfile, tell SLAPD where to store and find files that contain information on:
Figure1. Database Hierarchy
(i) The process ID for the SLAPD server process. (ii) The arguments that were passed into the slapd command at the startup. B.
Access Control Lists (ACLs)
by anonymous auth by self write by * none
Database Configuration
access to * by self read by * none
database hdb suffix "dc=zhcet,dc=amu" rootdn "cn=Manager,dc=zhcet,dc=amu" rootpw {MD5}BEBjwjNUEoszbfhvEYcuaA== directory /var/lib/ldap index objectclass,cn eq
ACLs are the directives with a complex syntax. They begin with the access directive, followed by a list of conditions.
This section handles the configuration of the Database Storage mechanisms. Each server can have more than one database with each database storing its own directory tree.
Details of the first access control : access to attrs=userPassword by anonymous auth by self write by * none
The first directive in the database configuration section is the database directive. This specifies which database backend will be used. For Example, to use the Hierarchical Database (Figure 1) , we should specify hdb.
This access control keeps a user's password protected. An authentication comparison is performed by the server on a password when requested by any anonymous user during the process of logging in. Apart from that, it a user can change his or her own password. Finally, it denies everyone else any access to the password. Each line of code having ‘by’ should be indented in the following manner:
The suffix directive indicates the part of the directory tree ,that holds the database. The base of this database is the Distinguished Name (DN) specified in the suffix directive (dc=zhcet,dc=amu) . The following lines assign a record for the directory manager and give the manager entry a password. The rootdn directive specifies the DN that will be considered the administrator of this directory. The root DN is created by adding cn=manager to the base DN of the directory tree. The rootpw field assigns a password for the directory manager. The directory directive shows which directory on the file system should hold the database files. In this case database is stored at /var/lib/ldap/.
access to [resources] by [who] [type of access granted] by [who] [type of access granted] by [who] [type of access granted] In each access directive there is one ‘to’ phrase, and any number of ‘by’ phrases. attrs indicates that a list of one or more attributes will follow. In this case there is only one
248
Authorized licensed use limited to: ZAKIR HUSSAIN COLLEGE OF ENG AND TECH. Downloaded on March 2, 2009 at 05:56 from IEEE Xplore. Restrictions apply.
format. When large number of entries are to be added in the directory, a single file in this format can be created to hold the entries and can then be added at a single time. Records are separated by empty lines and each record must begin with a DN as shown below:
attribute: userPassword which is used to store the value of a password for an object in the directory. In this access control the rule applies to the whole directory rather than a particular part of the directory. This means that all instances of userPassword will enforce the ACL. The other types of accesses to the userPassword attribute are indicated by the next three lines
dn:uid=msa,ou=Students,ou=Computers,dc= zhcet,dc=amu ou: Students uid: msa cn: Mohammad Sana Akhtar sn: Sana givenName: Sana displayName: Mohammad Sana Akhtar description: 3rd year mail:
[email protected] mobile: +91 945 624 1405 state: Uttar Pradesh homePostalAddress: 61-Nadeem Tarin Hall $ AMU, Aligarh $ U.P. (202002) userPassword: {SSHA}QDBOQbZaqCPqE5 objectClass: person objectClass: organizationalPerson objectclass: inetOrgPerson
The ‘by anonymous auth’ phrase grants an anonymous user, permission to authenticate using a password. The last part of the by phrase specifies what sort of permissions are granted to the record. There are four main keywords that can be used in ACLs to grant common permission levels: (i) (ii) (iii)
(iv)
auth: The server can perform an authentication operation using this resource. read: The client can have auth access and can also read this resource, but cannot make any changes. write: The client can have auth and read access to this resource and can also perform add, modify, and delete operations on whatever is specified by resource. none: The server should not give the client any access at all to this resource.
V. USING LDAP
The second by phrase, by self write, means that once a DN (usually a user) has successfully connected and authenticated to the LDAP server, it can change the value of userPassword.
A. Various Operations performed (i)
Finally, the last by phrase says by * none. The * is a wildcard that applies to everyone. And ‘none’ denies any sort of access to the userPassword attribute.
(ii) (iii)
The ACL is evaluated in an order. Server stops processing the ACL whenever it finds a rule that applies to current DN. The server checks the ACLs when an anonymous user tries to authenticate (bind) with a DN and password, to see if the DN has the permission to request an authentication comparison using the userPassword attribute.
(iv) (v) (vi)
As SLAPD evaluates this ACL . If the first by phrase applies, then it use that rule and skip the other two. If an authenticated user tries to read userPassword of another DN, the server will search by phrases until it finds one that matches. It will evaluate and skip the first two before applying the third, which denies that user the access to another record's userPassword attribute [1].
Bind (authentication ) : It involves logging in to the server by a user after successfully authenticating as a recognized user. Add (add an element to the directory) : Adds the user records into the desired directory. Search (search for elements in the directory) : Performs search operation with or without filters . Modify (edit the contents of an element) : User records can be modified as desired. New attributes can also be added. Delete (remove an element from the directory) : To remove one or more user records. Unbind (close the connection) : It involves logging out of the server and closing connection.
B. Working Mechanism Working of LDAP is based on Client-Server model. The client sends its Relative Distinguished Name (RDN ) as an identifier to the server for querying over TCP/IP. The server looks for the RDN in the LDAP Directory Information Tree (DIT). If the RDN matches , the query is processed.
IV. THE LDIF FILE FORMAT LDIF means LDAP Data Interchange Format. LDAP directory entries can be represented in a text file in this
249
Authorized licensed use limited to: ZAKIR HUSSAIN COLLEGE OF ENG AND TECH. Downloaded on March 2, 2009 at 05:56 from IEEE Xplore. Restrictions apply.
B. Securing APACHE Web Server The apache web server is the most frequently used web server on the internet. It provides virtual hosting service where one server instance can host multiple websites on different IP addresses or host names. Providing LDAP Authentication We can use LDAP authentication for accessing a web page (in this case, stored at /var/www/private/), by adding the
Figure 2. Working Mechanism [4]
Figure 4. Mechanism for Web Server Authentication [3] Figure 3. LDAP Authentication Scheme [2]
following lines in the default configuration file :
VI. SECURING LDAP The main purpose of any directory is not only to provide storage but also to secure the data present in it. LDAP provides powerful methods of securing the data among the users using Access Control Lists (ACLs). VII. GENERAL AUTHENTICATION SCHEME The benefit of employing LDAP authentication is immense as we get a centralized storage of user information, centralized management of accesses to various services and simplicity in managing user profiles over a shared network. The authentication architecture employed involves LDAP server, clients, services on the shared network etc., “Figure 3”
• • •
VIII. WEB SERVER AND LDAP
•
A. Mechanism for Web Server Authentication The web server directs the users to the LDAP server where the authenticity of the login information provided by the users are checked and verified “Figure 4”.
AuthType decides how the password information is sent from the client to the server. AuthName indicates for which service the authentication is meant for. AuthBasicProvider specifies which service is used for basic authentication. The last three lines are specifically meant for LDAP implying what DN and password Apache should use to log into the LDAP server
250
Authorized licensed use limited to: ZAKIR HUSSAIN COLLEGE OF ENG AND TECH. Downloaded on March 2, 2009 at 05:56 from IEEE Xplore. Restrictions apply.
several IT devices. For this it requires dialup and login authentication which is provided by LDAP. Once authenticated the DHCP sever assigns an IP address to the user and get connected to the LAN •
Figure 5.Snapshot showing apache authentication for an LDAP user
Figure 6. Snapshot showing successful authentication for a web page
Figure 7. Working of VPN using LDAP Authentication
•
IX. OTHER SERVICES USING LDAP AUTHENTICATION The LDAP based authentication is also utilized for various other services mentioned below: •
•
Virtual Private Network (VPN): VPN is a computer network in which the links between nodes are carried by open connections or virtual circuit in a larger network. VPNs are used to separate the traffic of different user communities over an underlying network. LDAP authentication can be used for establishing a client to site VPN connection. The Remote LDAP Server uses SSL connection to authenticate a user. The group membership of the remote users are compared with the group list as entered in the LDAP directory, when the authentication to the Remote LDAP directory is performed. This method helps us to maintain single copy of entries in the remote directory from which various users can authenticate instead of maintaining several copies at different locations. It also makes it possible for the various users to access the VPN without being in the e-Directory. Users from any LDAP directory can authenticate to the VPN [9]. Remote Access Server (RAS): RAS provides remote access to the information on a network to
Network Browsing restriction: On the sample Local Area Network the browsing capabilities are restricted using Authentication of users via LDAP. So, the users who have their LDAP accounts entered in the LDAP directory have access the internet. The server uses the ip address of the local terminal to allow or restrict internet access.
Sendmail : The Sendmail server is used to send and receive messages through a network. It allows standardized, centralized repository of user data which is integrated with the LDAP directory for providing authentication of users. The authentication is performed when a user sends or receive mails. REFERENCES
[1]
[2] [3]
[4]
[5] [6] [7]
[8]
[9]
Matt Butcher, Mastering OpenLDAP, first ed., Packt Publishing Ltd., 32 Lincoln Road, Olton, Birmingham, UK Vassiliki Koutsonikola., Athena Vakali., " LDAP: Framework, Practices, and Trends ", Aristotle University, IEEE Computer Society, October 2004. Riri Fitri Sari, Syarif Hidayat, “ Integrating Web Server Applications With LDAP Authentication: Case Study on Human Resources Information System of Ul”, IEEE,2006 Edgard Jamhour., "Distributed Security Management Using LDAP Directories", PPGIA, PUCPR – Pontificia, Universidade Catolica do Parana, 2001. Christopher Negus, BIBLE (Fedora 7), Wiley Publishing , Inc. , Indianapolis, Indiana Mick Bauer, "Paranoid penguin: authenticate with LDAP", Part III, Volume 2003 Issue 113, Specialized Systems Consultants, Inc. Sihem Amer-Yahia, Divesh Srivastava, Dan Suciu, "Distributed Evaluation of Network Directory Queries" IEEE Transactions on Knowledge and Data Engineering , Volume 16 Issue 4, 2004 John H. Terpstra, LDAP accounts manager, Linux Journal, Volume 2004 Issue 125, 2004, Specialized Systems Consultants, Inc. Darren Hartman, "SSL VPN Strong Front-end User Authentication Client Certificates using an Open Source CA", 2005, ICSA Labs
251
Authorized licensed use limited to: ZAKIR HUSSAIN COLLEGE OF ENG AND TECH. Downloaded on March 2, 2009 at 05:56 from IEEE Xplore. Restrictions apply.
