How is the communication channel from Web Active Directory products to Active Directory secured?

How is the communication channel from Web Active Directory products to Active Directory secured?

Web Active Directory products often talk to Active Directory. These communications are secured using a programatically-created secure, signed and sealed channel. This means that all requests to and from Web Active Directory applications and Active Directory use tamper-proof Kerberos data encryption and Kerberos/NTLM authentication for the Active Directory bind account.

Review the information below for details on the communication channel security implementation. Communication goes over port 389 and not 636 (LDAPS…LDAP over SSL) and does not require a certificate, simplifying deployment while maintaining channel integrity.

Secure: Requests secure authentication. When this flag is set, the WinNT provider uses NTLM to authenticate the client. Active Directory Domain Services uses Kerberos, and possibly NTLM, to authenticate the client.

Signing: Verifies data integrity to ensure that the data received is the same as the data sent.

Sealing: Encrypts data using Kerberos.

References
Check out the AuthenticationTypes Enumeration Microsoft Knowledge Base article at https://msdn.microsoft.com/en-us/library/system.directoryservices.authenticationtypes.aspx for more information about these options and how it secures the communication channel from Web Active Directory applications to Active Directory.

To use LDAPS (LDAP over SSL) on port 636, you need to install a certificate. Check out http://support.microsoft.com/kb/321051 for instructions to do this with Active Directory.

    • Related Articles

    • Active Directory Firewall Ports

      You might want to set up a Web Active Directory solution in your DMZ and have it work with an Active Directory server behind the firewall on your internal network. You need to open up the appropriate ports to allow this communication from your DMZ to ...

    • Installing more than one instance of a Web Active Directory application on the same server

      Description  You can install multiple instances of the same Web Active Directory application–including PeopleSearch, PeopleUpdate or PeoplePassword–on the same web server. This is handy if you want to target different applications to different ...

    • Check effective permissions in Active Directory

      Description You can check the effective permissions in Active Directory to determine the privileges that one account has on another account. Notes Web Active Directory products typically use a service account to connect to Active Directory and ...

    • Configuring Active Directory applications in a DMZ

      There are a number of approaches to setting up Active Directory-empowered applications like Web Active Directory provides. Our web-enabled applications require access to Active Directory from public internet-facing servers and many organizations are ...

    • Why do Active Directory Permissions Revert After I Set Them?

      Active Directory has a feature that keeps privileged users like Domain Admins from locking themselves out of Active Directory by incorrectly setting permissions. The AdminSDHolder object and its Active Directory worker code is used by Domain ...