"username_attribute=cn" for HTTP but not available for Transport

Search Guard
1

Hi -

HTTP honours username_attribute parameter and picks CN as the username attribute (see output below). Whereas in Transport, it always expect DN. Is this by design? Why is this inconsistent while HTTP accepts CN and DN, whereas accepts only DN?

Thanks.

Jalaja

When asking questions, please provide the following information:

  • Search Guard and Elasticsearch version

SG - 6-6.1.1-20.1

ES - 6-1-1

  • Search Guard configuration files

bash-4.2# cat sg_config.yml

searchguard:

dynamic:

authc:

clientcert_auth_domain:

http_enabled: true

transport_enabled: true

order: 1

http_authenticator:

type: clientcert

config:

username_attribute: cn #optional, if omitted DN becomes username

challenge: false

authentication_backend:

type: noop

2

This might actually be a bug. Could you please open an issue for this on our GitHub Issue Tracker so we can investigate. Thanks!

···

On Thursday, August 30, 2018 at 5:34:40 PM UTC-4, Jalaja Dx wrote:

Hi -

HTTP honours username_attribute parameter and picks CN as the username attribute (see output below). Whereas in Transport, it always expect DN. Is this by design? Why is this inconsistent while HTTP accepts CN and DN, whereas accepts only DN?

Thanks.

Jalaja

When asking questions, please provide the following information:

  • Search Guard and Elasticsearch version

SG - 6-6.1.1-20.1

ES - 6-1-1

  • Search Guard configuration files

bash-4.2# cat sg_config.yml

searchguard:

dynamic:

authc:

clientcert_auth_domain:

http_enabled: true

transport_enabled: true

order: 1

http_authenticator:

type: clientcert

config:

username_attribute: cn #optional, if omitted DN becomes username

challenge: false

authentication_backend:

type: noop