Categories
- ABAP Development
- BASIS Security
- BASIS Administration
- BASIS Database
- BI - Business Intelligence
- CRM Customer Relationship
- EP Enterprise Portals
- FICO Financials
- HCM HR Human Capital
- JAVA Development
- Management Accounting
- Master Data Management
- MM Material Management
- PLM Customer Service
- PLM Data Management
- PLM Plant Management
- PLM Project Management
- PLM Quality Management
- PP Production Planning
- SAP Analytics
- SAP ERP Fundamentals
- SCM Discreet Mfg
- SCM Inventory Warehouse
- SCM Logistics Execution
- SCM Process Mfg
- SCM TM Transportation
- SD Sales and Distribution
- SMI Solution Manager
- SOA Service Architecture
- SRM Supplier Relationship
- XI PI Process Integration
Most Rated Articles
»
BASIS Administration
Rate Author : Current :
2.87 /5
Rate this Article : Current :
2.91 /5
What Are Directory Services?
Not only in the Internet, but also in company networks, there is a danger that information will be lost because it is made available in an unstructured way, becomes obsolete, or no one knows that it exists. A modern information system is needed.
A directory server is an information system for particular information. Directory services can help us to answer questions such as "What is the project leader's e-mail address?" or "Where is the nearest color printer?" in the same way that the yellow pages help us to find a lawyer or the nearest florist.
Unlike a relational database management system (RDBMS), where information is stored in two-dimensional tables, directory services use a hierarchical (tree) structure to organize the data. Another difference is the relationship of write to read accesses. Directory services are designed for a high read load, but unlike relational databases, they do not support transaction or lock concepts, or costly queries such as joins.
Directory services are typically used to store information about users, documents, or hardware resources; however, any other objects could also be stored.
Example Scenario
Directory services can fully demonstrate their strengths in heterogeneous system landscapes (where products from different vendors are used). The example below will illustrate this concept.
A company hires a new employee. This employee is first created in the HR system (which can be an SAP system or come from a different vendor). Some properties (such as name, personnel number, telephone number, e-mail address, department, and group assignment) are transferred to the corporate directory server, while others (such as date of employment, manager, and salary) are deliberately held only in the HR system. If different applications are connected to the directory server:
• The new employee can immediately log onto the corporate domain at operating-system level
• The employee has a functioning e-mail account immediately
• Telephone and fax numbers are assigned to the user
• The employee can log onto the enterprise portal
• The employee has access to certain SAP systems (such as SAP EBP, to place orders).
• Other external systems can be easily integrated
If an employee leaves the company, he or she is deleted from the HR system and therefore also from the directory. Consequently, all of his or her accounts are deleted or locked - not an easy task if it has to be performedmanually. This closes gaps in security due to accounts that have not been deleted.
What Is LDAP?
LDAP stands for Lightweight Directory Access Protocol. It describes how operations are to be formulated for a directory service. The most common operation is querying entries; however, it is also possible to create, change, or delete entries.
From a technical point of view, LDAP follows the client/server model: one or more servers hold the information that the client(s) access. Originally, LDAP implemented only communication with an X.500 server, as described by the International Organization for Standardization (ISO).
LDAPv2 was implemented in 1995 by Yeong, Howes, and Kille at the University of Michigan, to "minimize the complexity of clients so as to facilitate widespread deployment of applications capable of utilizing the Directory." LDAP uses a TCP/IP stack and simplifies access to X.500 servers. The current version of LDAP is LDAPv3. For more information about the technical details, see RFC 2251 (RFC means "Request for Comments" here; for more information about this, see www.ietf.org).
An X.500 server is no longer required; various vendors offer "standalone" servers that can be addressed using LDAP. In addition to commercial products (such as eDirectory from Novell, SunOne Directory Server from Sun/Netscape, DirX from Siemens, and Active Directory from Microsoft), there is also an Open Source development. For more information, see www.openldap.org.
The Data Model
There are a number of models for LDAP. In addition to the access protocol, these define how information is stored and identified, and how access is protected.
A directory contains entries that consist of one or more attributes. An attribute, in turn, consists of a type (frequently abbreviated strings such as "cn" for "common name," "c" for "country," or "mail" for e-mail address) and one or more values.
Certain attributes are required, while others are optional; this is controlled with LDAP using a special attribute, object class. Object classes have an inheritance hierarchy. The information about object classes and attribute types is stored in schemas, which are provided by Internet organizations and vendors of directory servers (and which can be customized by the user).
The entries are also organized in a hierarchical tree structure. Each entry contains a name that is unique directory-wide, the Distinguished Name (DN). The DN is created by describing the path from the entry to the root of the tree (in the form of a comma-separated list) (for example: cn=AHeepmann, ou=instructors, o=sap, c=de). An individual component of the DN is called the Relative Distinguished Name (RDN), which always identifies the node uniquely relative to the superordinate node in the tree. Two nodes under the same superordinate node could not, therefore, have the same RDN. The entire tree of entries (which can be stored physically across multiple hosts) is called the Directory Information Tree (DIT).
SAP and Directory Services
SAP has provided ways to connect SAP systems to directory services for a number of years. In 1997, the LDAP Gateway, a program that runs independently of the application server, was delivered in Java with SAP Basis 4.0A (supported up to SAP Basis 4.6B). Integration into the application server came with the LDAP Connector, which has been available since SAP Basis 4.6A. With SAP Web AS 6.10, user-friendly functions for user master synchronization (mapping, delta management, and synchronization) were added.
For a list of partners certified by SAP for the directory server interface (technical name: BC-LDAP-USR), see the SAP Service Marketplace under the Quick Link /partnerdirectory.
SAP's enterprise portals also require a store for user data such as master data and group assignment (user persistence store). SAP Enterprise Portal 5.0 (first delivered at the end of 2001) uses one or more directory servers for this purpose, which users are checked against when they log onto the portal. With SAP Enterprise Portal 6.0 (first shipped at the end of 2002), additional storage options were added to the directory server (SAP system or a portal database), thanks to the UME from SAP Web AS Java. Directory servers are used for most portal implementations.
Both Central User Administration (CUA) and directory services allow you to maintain user data at one location, and to synchronize it in multiple systems. Both concepts can be implemented independently. However, you can also connect them with each other.
In this way, you could use CUA to connect SAP systems with SAP Basis 4.5 or 4.6, while other SAP systems with SAP Web AS could also be connected directly to the directory service.
In a scenario of this type, LDAP synchronization functions as a "remote control" for the CUA, meaning that all prerequisites and restrictions of the CUA continue to apply
Not only in the Internet, but also in company networks, there is a danger that information will be lost because it is made available in an unstructured way, becomes obsolete, or no one knows that it exists. A modern information system is needed.
A directory server is an information system for particular information. Directory services can help us to answer questions such as "What is the project leader's e-mail address?" or "Where is the nearest color printer?" in the same way that the yellow pages help us to find a lawyer or the nearest florist.
Unlike a relational database management system (RDBMS), where information is stored in two-dimensional tables, directory services use a hierarchical (tree) structure to organize the data. Another difference is the relationship of write to read accesses. Directory services are designed for a high read load, but unlike relational databases, they do not support transaction or lock concepts, or costly queries such as joins.
Directory services are typically used to store information about users, documents, or hardware resources; however, any other objects could also be stored.
Example Scenario
Directory services can fully demonstrate their strengths in heterogeneous system landscapes (where products from different vendors are used). The example below will illustrate this concept.
A company hires a new employee. This employee is first created in the HR system (which can be an SAP system or come from a different vendor). Some properties (such as name, personnel number, telephone number, e-mail address, department, and group assignment) are transferred to the corporate directory server, while others (such as date of employment, manager, and salary) are deliberately held only in the HR system. If different applications are connected to the directory server:
• The new employee can immediately log onto the corporate domain at operating-system level
• The employee has a functioning e-mail account immediately
• Telephone and fax numbers are assigned to the user
• The employee can log onto the enterprise portal
• The employee has access to certain SAP systems (such as SAP EBP, to place orders).
• Other external systems can be easily integrated
If an employee leaves the company, he or she is deleted from the HR system and therefore also from the directory. Consequently, all of his or her accounts are deleted or locked - not an easy task if it has to be performedmanually. This closes gaps in security due to accounts that have not been deleted.
What Is LDAP?
LDAP stands for Lightweight Directory Access Protocol. It describes how operations are to be formulated for a directory service. The most common operation is querying entries; however, it is also possible to create, change, or delete entries.
From a technical point of view, LDAP follows the client/server model: one or more servers hold the information that the client(s) access. Originally, LDAP implemented only communication with an X.500 server, as described by the International Organization for Standardization (ISO).
LDAPv2 was implemented in 1995 by Yeong, Howes, and Kille at the University of Michigan, to "minimize the complexity of clients so as to facilitate widespread deployment of applications capable of utilizing the Directory." LDAP uses a TCP/IP stack and simplifies access to X.500 servers. The current version of LDAP is LDAPv3. For more information about the technical details, see RFC 2251 (RFC means "Request for Comments" here; for more information about this, see www.ietf.org).
An X.500 server is no longer required; various vendors offer "standalone" servers that can be addressed using LDAP. In addition to commercial products (such as eDirectory from Novell, SunOne Directory Server from Sun/Netscape, DirX from Siemens, and Active Directory from Microsoft), there is also an Open Source development. For more information, see www.openldap.org.
The Data Model
There are a number of models for LDAP. In addition to the access protocol, these define how information is stored and identified, and how access is protected.
A directory contains entries that consist of one or more attributes. An attribute, in turn, consists of a type (frequently abbreviated strings such as "cn" for "common name," "c" for "country," or "mail" for e-mail address) and one or more values.
Certain attributes are required, while others are optional; this is controlled with LDAP using a special attribute, object class. Object classes have an inheritance hierarchy. The information about object classes and attribute types is stored in schemas, which are provided by Internet organizations and vendors of directory servers (and which can be customized by the user).
The entries are also organized in a hierarchical tree structure. Each entry contains a name that is unique directory-wide, the Distinguished Name (DN). The DN is created by describing the path from the entry to the root of the tree (in the form of a comma-separated list) (for example: cn=AHeepmann, ou=instructors, o=sap, c=de). An individual component of the DN is called the Relative Distinguished Name (RDN), which always identifies the node uniquely relative to the superordinate node in the tree. Two nodes under the same superordinate node could not, therefore, have the same RDN. The entire tree of entries (which can be stored physically across multiple hosts) is called the Directory Information Tree (DIT).
SAP and Directory Services
SAP has provided ways to connect SAP systems to directory services for a number of years. In 1997, the LDAP Gateway, a program that runs independently of the application server, was delivered in Java with SAP Basis 4.0A (supported up to SAP Basis 4.6B). Integration into the application server came with the LDAP Connector, which has been available since SAP Basis 4.6A. With SAP Web AS 6.10, user-friendly functions for user master synchronization (mapping, delta management, and synchronization) were added.
For a list of partners certified by SAP for the directory server interface (technical name: BC-LDAP-USR), see the SAP Service Marketplace under the Quick Link /partnerdirectory.
SAP's enterprise portals also require a store for user data such as master data and group assignment (user persistence store). SAP Enterprise Portal 5.0 (first delivered at the end of 2001) uses one or more directory servers for this purpose, which users are checked against when they log onto the portal. With SAP Enterprise Portal 6.0 (first shipped at the end of 2002), additional storage options were added to the directory server (SAP system or a portal database), thanks to the UME from SAP Web AS Java. Directory servers are used for most portal implementations.
Both Central User Administration (CUA) and directory services allow you to maintain user data at one location, and to synchronize it in multiple systems. Both concepts can be implemented independently. However, you can also connect them with each other.
In this way, you could use CUA to connect SAP systems with SAP Basis 4.5 or 4.6, while other SAP systems with SAP Web AS could also be connected directly to the directory service.
In a scenario of this type, LDAP synchronization functions as a "remote control" for the CUA, meaning that all prerequisites and restrictions of the CUA continue to apply