== LDAP Configuration for INTERNAL only Test Servers

We've two LDAP servers for testing:

* Active Directory on Windows Server 2012
* OpenLdap on Suse Enterprise Linux 10.x

=== Configuration for OpenLdap

Here is a configuration that works for openldap.  This is using OpenSuse's method for creating ldap users that can
authenticate to the box.  So it is probably close to a real-world scenario.  For SSL the following truststore has both
public certificates in it: elasticsearch-shield/src/test/resources/org/elasticsearch/shield/transport/ssl/certs/simple/testnode.jks

[source, yaml]
------------------------------------------------------------
shield:
  ssl.keystore:
    path: "/path/to/elasticsearch-shield/src/test/resources/org/elasticsearch/shield/transport/ssl/certs/simple/testnode.jks"
    password: testnode
  authc.realms.openldap:
      type: ldap
      order: 0
      url: "ldaps://54.200.235.244:636"
      user_dn_templates: [ "uid={0},ou=people,dc=oldap,dc=test,dc=elasticsearch,dc=com" ]
      group_search:
        base_dn: "ou=people,dc=oldap,dc=test,dc=elasticsearch,dc=com"
      hostname_verification: false
------------------------------------------------------------

=== Configuration for Active Directory

You could configure Active Directory the same way (with type ldap and user_dn_templates).  But where is the fun in that!
Active directory has a simplified (non-standard) authentication workflow that helps us eliminate the templates.

BUT this technique requires you use a DNS name for your active directory server.  Do this adding the following to /etc/hosts:

`54.213.145.20   ad.test.elasticsearch.com ForestDnsZones.ad.test.elasticsearch.com DomainDnsZones.ad.test.elasticsearch.com`

[source, yaml]
------------------------------------------------------------
shield:
  authc.realms.ad:
    type: active_directory
    order: 0
    domain_name: ad.test.elasticsearch.com

------------------------------------------------------------

The above configuration results in a plaintext LDAP connection. For SSL the following configuration is required:
[source, yaml]
------------------------------------------------------------
shield:
  ssl.keystore:
    path: "/path/to/elasticsearch-shield/src/test/resources/org/elasticsearch/shield/transport/ssl/certs/simple/testnode.jks"
    password: testnode
  authc.realms.ad:
    type: active_directory
    order: 0
    domain_name: ad.test.elasticsearch.com
    url: "ldaps://ad.test.elasticsearch.com:636"
    hostname_verification: false

------------------------------------------------------------

=== Users & Groups

Isn't LDAP fun?! No? Well that's why we've created super heros!

|=======================
| CN (common name) | uid | group memberships
| Commander Kraken | kraken | Hydra
| Bruce Banner | hulk | Geniuses, SHIELD, Philanthropists, Avengers
| Clint Barton | hawkeye | SHIELD, Avengers
| Jarvis | jarvis |
| Natasha Romanoff | blackwidow | SHIELD, Avengers
| Nick Fury | fury | SHIELD, Avengers
| Phil Colson | phil | SHIELD
| Steve Rogers | cap | SHIELD, Avengers
| Thor | thor | SHIELD, Avengers, Gods, Philanthropists
| Tony Stark | ironman | Geniuses, Billionaries, Playboys, Philanthropists, SHIELD, Avengers
| Odin | odin | Gods
|=======================

They aren't very good super-heros because they all share the same password: `NickFuryHeartsES`.  You'll use the uid
for the username.

=== Groups
If you want to map group names to es roles, you'll use the fully distinguished names of the groups.  The DNs for groups in ad is
`CN={group name},CN=Users,DC=ad,DC=test,DC=elasticsearch,DC=com`
the DNs for groups in openldap is
`cn={group name},ou=people,dc=oldap,dc=test,dc=elasticsearch,dc=com`

Ping Cam Morris or Bill Hwang for more questions.