OpenSearch/shield/docs/private/ldap-testing.asciidoc

94 lines
3.7 KiB
Plaintext
Raw Normal View History

== 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.