# Cloud active directory auth (Not SAML) **URL:** \ **Category:** Elasticsearch\ **Created:** [November 8, 2024, 1:33am UTC](https://discuss.elastic.co/t/cloud-active-directory-auth-not-saml/370190 "2024-11-08T01:33:41Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![rugenl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rugenl/32/12887_2.png) [@rugenl](https://discuss.elastic.co/u/rugenl)\ **Post date:** [November 8, 2024, 1:33am UTC](https://discuss.elastic.co/t/cloud-active-directory-auth-not-saml/370190/1 "2024-11-08T01:33:41Z")
Cloud 8.15.3, using SAML auth now, moving from on-prem using Active Directory. SAML works for interactive users, but apparently won't work for things like ingest and scripts. API keys work for scripts, but I get grumbling that they aren't revoked like our on-prem AD users would be if they move or leave. Another issue is the \*beats setup, which needs both Elastic and Kibana access, neither API keys nor SAML work for that, all that I've found so far is a native account and again, it's not revoked as part of our AD procedures. Replacing beats with Fleet managed agents would work, but I've encountered non-technical resistance... I read that AD realm's aren't supported in the cloud, but is that still the case? Our on-prem AD realm needs to refer to a CA PEM file and I don't think that's possible in the cloud. Thanks for any ideas. ---
**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\ **Post date:** [November 8, 2024, 4:44am UTC](https://discuss.elastic.co/t/cloud-active-directory-auth-not-saml/370190/2 "2024-11-08T04:44:11Z")
> [@rugenl](#): > > Another issue is the \*beats setup, which needs both Elastic and Kibana access, neither API keys API Keys should work for beats setup. > [@rugenl](#): > > read that AD realm's aren't supported in the cloud, but is that still the case? Yes, that is still the case. * * * For ingest, do you really want credentials that are revoked according to employee transitions? Most people want to have ingest processes that are independent of a specific employee (assuming you are ingesting company data - logs, metrics, catalog items, etc - rather than having individuals ingest their own data). ---
**Author:** ![rugenl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rugenl/32/12887_2.png) [@rugenl](https://discuss.elastic.co/u/rugenl)\ **Post date:** [November 8, 2024, 3:31pm UTC](https://discuss.elastic.co/t/cloud-active-directory-auth-not-saml/370190/3 "2024-11-08T15:31:46Z")
The ingest AD creds aren't tied to a person, but a "function". It's more of a non-technical issue here. I always load the Kibana dashboards at setup, so I thought that needed Kibana creds. API keys might solve the issues. I'm testing setup with an API key, but keep getting invalid credentials. I have a python script that uses the api key that works, so I know the key is valid. The python client just uses the key, beats config needs the different format of key\_id:key. I get the key\_id from devtools (the "id" field?). Sanitized error message is below. I tried with an API key that was invalidated and got a different error, saying it was invalidated. I'm stumped as to why I can't the the api key format correct. Thanks for the help. > Blockquote > 401 Unauthorized: {"error":{"root\_cause":[{"type":"security\_exception","reason":"unable to authenticate with provided credentials and anonymous access is not allowed for this request","additional\_unsuccessful\_credentials":"API key: invalid credentials for API key [xxxx]","header":{"WWW-Authenticate":["Basic realm=\"security\", charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}}],"type":"security\_exception","reason":"unable to authenticate with provided credentials and anonymous access is not allowed for this request","additional\_unsuccessful\_credentials":"API key: invalid credentials for API key [xxxx]","header":{"WWW-Authenticate":["Basic realm=\"security\", charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}},"status":401}","service.name":"filebeat","ecs.version":"1.6.0"} ---
**Author:** ![rugenl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rugenl/32/12887_2.png) [@rugenl](https://discuss.elastic.co/u/rugenl)\ **Post date:** [November 8, 2024, 4:46pm UTC](https://discuss.elastic.co/t/cloud-active-directory-auth-not-saml/370190/4 "2024-11-08T16:46:08Z")
Ah, when you create an API key with Kibana, it returns the combined id:key encoded. More testing needed, after I figure out how to get the id:key decoded...