Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

What do these Add Service account options do?

avatar
Super Collaborator

In Ambari 2.5.0.3 I noticed the following options under "Misc" when I want to specify an custom service account name:

  1. Skip group modifications
  2. Have Ambari manage UIDs
  3. Whether to skip creating users and groups in a sysprepped cluster

Previously I only remember seeing "Skip group modifications", but may be the UID option was there. The last option definitely seems new to me. Anyway, is there documentation or an HCC article explaining exactly what these do and when I would want them? I can take a guess based on the names, but it would be nice to have a clear understanding.

Our present need is to have service accounts and groups pre-created in AD/Centrify and I assume not defined on the local OS at all. In this case it seems like checking all three options would be safe, but option 3 seems like it might imply options 1 and 2 are selected.

I would like advice on how to proceed with my current scenario, but any additional insight into what these actually do is appreciated.

Thanks.

Incidentally, for those that care - you can set these three options above in blueprints. See my previous question:

https://community.hortonworks.com/questions/103647/how-to-use-blueprints-with-pre-created-accounts-f...

1 ACCEPTED SOLUTION

avatar

@james.jones

Ambari will natively create local accounts initially to run each service in the cluster. If your intention is to move away from all local accounts, then your best bet will be to Kerberize the cluster rather than zone-enabling the cluster service accounts for an unsecured cluster. Once the cluster is Kerberized, the local accounts are abandoned for SPN accounts created in Active Directory and locally distributed keytabs. The SPN accounts do not have to be zone-enable. In fact, they should not. Although the local /etc/password accounts will remain after securing, they serve no function. I usually leave them there in case I ever need to disable Kerberos and resecure the cluster.

View solution in original post

3 REPLIES 3

avatar

Hi @james.jones

If you're a Centrify customer, you'll likely manage all of your interactive AD users and groups within a zone structure. In an unsecured cluster, all of the services on each node are started using a local /etc/passwd file account. The options you mentioned are related to how Ambari will generate those. This is common practice and there is no need to zone-enable those accounts. Best practice though, is to immediately abandon those local accounts and switch to a secured cluster. This will replace the local accounts with service principal accounts stored in AD, and kerberos authentication for all services. However, even in that configuration, SPN accounts will not have to be zone-enabled to be used by the cluster services.

Hope that helps! Please reach out if you have any additional questions or want to know more about Centrify integration with Hadoop.

avatar
Super Collaborator

@Michael Szymczak - thanks for the reply and I'm sorry it's taken so long to get back to reply. We are a Centrify customer.

I am wondering if it is possible to install HDP via Ambari if if accounts are pre-created in AD/Centrify (without any of them pre-existing or being added to /etc/password or /etc/shadow during installation). We would prefer to avoid any resemblance of a local account (or groups). This cluster will eventually be secured/kerberized which I have done numerous times with AD. However, I have always used some form of locally defined accounts and groups. The options Ambari offers (above) sounds like it will use accounts as long as it can get an the id and groups exist.

avatar

@james.jones

Ambari will natively create local accounts initially to run each service in the cluster. If your intention is to move away from all local accounts, then your best bet will be to Kerberize the cluster rather than zone-enabling the cluster service accounts for an unsecured cluster. Once the cluster is Kerberized, the local accounts are abandoned for SPN accounts created in Active Directory and locally distributed keytabs. The SPN accounts do not have to be zone-enable. In fact, they should not. Although the local /etc/password accounts will remain after securing, they serve no function. I usually leave them there in case I ever need to disable Kerberos and resecure the cluster.