Active Directory and LDAP

https://en.wikipedia.org/wiki/Directory_service

What is a Directory Service?  What is its relationship with LDAP?

The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.  Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network.  As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.

LDAP vendors:

  • OpenLDAP (OpenLDAP public license) http://www.openldap.org
  • SunOne (iPlanet) Directory Server
  • Novell’s eDirectory
  • IBM Directory Server
  • Microsoft Active Directory
  • Innosoft
  • Lotus Domino
  • Nexor
  • Critical Path

 

Active Directory (AD) is a directory service that Microsoft developed for Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. Starting with Windows Server 2008, however, Active Directory became an umbrella title for a broad range of directory-based identity-related services.

A server running Active Directory Domain Services (AD DS) is called a domain controller. It authenticates and authorizes all users and computers in a Windows domain type network—assigning and enforcing security policies for all computers and installing or updating software. For example, when a user logs into a computer that is part of a Windows domain, Active Directory checks the submitted password and determines whether the user is a system administrator or normal user.

Active Directory uses Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Microsoft’s version of Kerberos, and DNS.

References:

 

http://stackoverflow.com/questions/663402/what-are-the-differences-between-ldap-and-active-directory

https://technet.microsoft.com/en-us/library/bb463152.aspx

http://coewww.rutgers.edu/www1/linuxclass2003/lessons/lecture8.html

Active Directory and LDAP

Single-Sign-On (SSO) Implementation Requirements

Single-Sign-On (SSO) Implementation Requirements – Best Practices

  1. SSO solution should be able to integrate with existing Digital Key Management and Cryptoprocessing Modules such as Hardware Security Modules (HSM).
  1. SSO solution should be able to perform “authentication after authentication”, where the User is prompted for the Second Factor Authentication Input (SMS/Token), when required to do so.
  1. The SSO solution should be able to support different authentication policies for different User Groups (Password Requirements, Password Expiry, Session Expiry due to Inactivity, Session Absolute Expiry, Account Lockouts, etc).
  1. Password Hashing Algorithm which is used to store passwords in the backend database should be compliant with Industry Best Practices.
  1. Logging should be enabled to capture User Events, Admin Events and System Events – Timestamp, User ID, User IP Address, Failed Login Attempts, Account Lockouts, Successful Logins, Applications Being Accessed, Roles Being Accessed, Session Expiry Time/Logout Time, SSO Admin Activity, Critical System Errors, Connectivity Issues, etc.
  1. Logs should be pushed to the central SIEM infrastructure as soon as they are generated.  Logs should also be retained in the SSO system for troubleshooting/review, closer to the time of occurrence.
  1. All SSO related Administration and Service Accounts should be managed through the Privileged Account Management Solution.
  1. The SSO Solution should cater for selectively turning On/Off SSO for individual applications (example: through the provision of alternate login URLs for direct authentication into an application).
  1. If SSO infrastructure fails, it is ideal to have an alternate mechanism for Users to use to login into the individual applications.
  1. The SSO User ID format should be pre-defined and it should indicate the Group of the User.
  1. SSO solution should cater for Password Reset mechanisms which can be managed by the User after the User has authenticated himself.  The SSO solution should also be integrated with the Helpdesk/Service Desk teams so that they could reset password through their pre-defined process.
  1. SSO solution should provide High-Availability (99.99% uptime) and should have a Disaster Recovery setup.
  1. The connectivity channel offered to users and between SSO components should be secured with industry standard TLS protocol which relies on Digital Certificates and not relying on passwords pre-determined by the installer or shared secrets set by the administrators.
  1. All sensitive details in browser cookies should be encrypted using industry standard algorithms (This should be in-addition to the encryption provided by TLS).  Furthermore, cookie Secure flag and HTTPOnly flag should be set.
  1. The Product Vendor’s SLA and the Solution Implementation Vendor’s SLA should be clearly defined and communication channels should be clearly documented.  The Criticality Level definitions should match with the Company’s Internal Definitions.  The channels through which security patches will be communicated to the Company and made available should be documented.
  1. Administration functions and Admin Interfaces in the SSO solution should be clearly defined, documented and implemented.
  1. The maximum capacity and idle load (number of concurrent user sessions, response times, etc) should be clearly documented.  Additional costs (licensing, hardware, implementation, maintenance, effort, lead time, etc) and restrictions/limitations for scaling-up the capacity should be clearly documented.
  1. SSO solution configurations/implementations in an Environment (Development, SIT, UAT, and Production) should be easily deployable to another environment.   [Migration should be as automated as possible and reduce manual work/effort]
  1. SAML messages should be over TLS and they should be digitally signed.

 

An example of SSO Solution – IBM TIM and TAM

IBM Tivoli Access Manager (TAM): Is an SSO solution that authorizes and authenticates user access to Web and other hosted applications.

IBM Tivoli Identity Manager (TIM): Is a policy-based identity and access governance solution that helps automate lifecycle management of user roles, identities and access rights.  Through the use of roles, accounts, and access permissions, Tivoli Identity Manager helps automate the creation, modification, and termination of user privileges throughout the entire user lifecycle.

IBM TIM can be used with any application that requires a User ID.  Creates physical User IDs for target applications (Multiple User IDs will be created per User for the different applications).  The implementation is adapter based.

IBM TAM is used for implementing SSO for Web based applications.  It creates an SSO User ID for all applications (One User ID per TAM user).  The implementation of the solution is Reverse Proxy based.

 

References:

http://searchsecurity.techtarget.com/answer/Pre-requisites-for-implementing-enterprise-single-sign-on-SSO

http://www.authenticationworld.com/Single-Sign-On-Authentication/101ThingsToKnowAboutSingleSignOn.pdf

http://www.sans.org/reading-room/whitepapers/authentication/secure-implementation-enterprise-single-sign-on-product-organization-1520

http://stackoverflow.com/questions/8276233/is-it-recommended-to-sign-and-encrypt-saml-and-use-ssl

https://www.secureauth.com/SecureAuth/media/Resources/WhitePapers/whitepapersamlnotenough.pdf?ext=.pdf

http://resources.infosecinstitute.com/securing-cookies-httponly-secure-flags/

https://www.owasp.org/index.php/HttpOnly

https://www.ibm.com/developerworks/community/wikis/form/anonymous/api/wiki/7c6dac80-f1da-4e22-80c8-da6131356e06/page/e84fb82f-993e-40ed-9e8b-a009581673ac/attachment/5a5d17b7-35bc-46e6-a7e7-5b678d557046/media/timtam.pdf

http://www.ibm.com/developerworks/tivoli/tutorials/tvprovision/

Single-Sign-On (SSO) Implementation Requirements