Active Directory VS' Standalone LDAP Server

1
Active Directory VS. Stand-alone LDAP Server
uPortal
February 12th, 2003
2
Intro to LDAP
LDAP (Lightweight Directory Access Protocol) a
client-server protocol used for accessing
directory services. Data in an LDAP directory is
arranged in a tree called a Directory Information
Tree (DIT). There is usually a hierarchical
structure of this tree (see diagram below).
3
Intro to LDAP (cont)

• LDAP entries consist of objectclasses and
  attributes.
• Objectclasses define a collection of attributes
  and associated valid values.
• LDAP has predefined objectclasses and attributes
  that suit most general needs, but the schema can
  be extended if additional attributes or classes
  are required.
• Example Objectclass attributes
• Objectclass contactInformation
• emailAddress
• homeTelephone
• Number
• officeTelephoneNumber
• cellularTelephoneNumber
• pagerNumber
• homeAddress
• businessAddress

4
Intro to LDAP (cont)

• A user in LDAP is thus composed of objectclasses
  and attributes of the objectclasses.
• A typical user entry stored in LDAP might look
  something like this

dn uidjdoe,dcmillersville,dcedu objectclass
top objectclass person objectclass
organizationalperson objectclass inetorgperson
cn John Doe sn Doe uid jdoe mail
jdoe_at_millersville.edu userpassword
ssha1KoDEQd/MrYJPnFgotki5AZrCyfGZYr
5
Active Directory As LDAP Server

• ADVANTAGES
• Since only one directory is being used for user
  account information, no other connections to
  directories must be made and synchronization of
  user account info is not needed.
• Any changes to user info (passwords, etc) are
  updated immediately.
• Provides most of the functionality of a
  standalone LDAP server.

6
Active Directory As LDAP Server (cont)

• DISADVANTAGES
• An admin password must be used to manage accounts
  through LDAP. If other non-uPortal accounts also
  exist in AD, these accounts and the system(s)
  that use the password could be compromised if the
  password is discovered.
• Extending the schema is more difficult than with
  a standalone LDAP server and sometimes the only
  way to get at certain attributes or manage LDAP
  info is to use the ADSI (Active Directory
  Services Interface), adding to the complexity of
  application integration.
• Some of the schema (attributes, etc) differ from
  the LDAP standard, making applications designed
  with the LDAP standards in mind more difficult to
  setup.
• Attributes or new objectclasses can never be
  truly deleted. They are instead marked as
  unused, but still exist in AD.
• Could complicate management by the WindowsNT
  System Admin if schema is extended or accounts
  are managed by two parties.
• uPortal code for LDAP connections must be
  modified to work with Active Directory.

7
Sun One Directory As LDAP Server

• ADVANTAGES
• A compromised administrator password would only
  be a security threat to the directory itself, not
  the system or other machines.
• Security of the machine and the data incoming and
  outgoing is controlled by us (SSL, TCP Wrappers,
  Firewall, etc).
• Performance would not be impacted by domain or
  mail logons.
• Control of all aspects of a user account
  (creation, updates, deletion) is handled by us.
• Better scalability for the future if additional
  applications will be using LDAP as primary means
  of authentication.
• uPortal LDAP connection code does not need the
  modification Active Directory requires.

8
Sun One Directory As LDAP Server

• DISADVANTAGES
• A means of connecting to Active Directory for
  password synchronization is needed.
• User accounts would have to be initially loaded
  into the directory from Active Directory through
  either dumps of the user account info or by
  scripts, etc. If new user accounts are created
  in Active Directory throughout the semester or at
  the start of a new semester, these accounts would
  also need to be added to LDAP.

9
Sun One As LDAP Server (cont)

• Although the issue of account synchronization is
  a disadvantage to using LDAP instead of Active
  Directory, the problem can be solved by using one
  of (or several) of the following methods
• Metadirectories often costly, but best method
  for immediate synchronization of data
• Connectors connects one directory to another so
  that if a change is made the change is reflected
  in the other directory.
• Password Synchronizers allow synchronization of
  AD-gtLDAP and often LDAP-gtAD as well.
• Scripts Perl or C scripts that use LDAP
  libraries to search for changes in accounts.

10
Benchmarks

• Sun One Directory
• Bulk Load Time (Records/sec)
• 413.2
• Messaging Test With One Client (Operations/sec)
• 1,323
• Messaging Test With 10 Clients (Operations/sec)
• 3,175

Active Directory Bulk Load Time
(Records/sec) 33.3 Messaging Test With One
Client (Operations/sec) 915 Messaging Test With
10 Clients (Operations/sec) 1,536
11
Recommendations

• Given the performance, management, security
  and scalability advantages of using a standalone
  LDAP server, it is recommended this approach is
  taken. If an Administrator in Active Directory
  can be created for managing the uPortal users
  solely and the schema can be extended and managed
  without causing the WindowsNT Administrator any
  further confusion, then Active Directory could be
  a viable solution. Additionally, since uPortal
  LDAP connection code must be modified in order to
  work correctly to Active Directory at the moment,
  it is unknown whether future uPortal releases
  could break the connection to the current
  workaround.