Created 05-19-2017 02:39 PM
In Ambari 2.5.0.3 I noticed the following options under "Misc" when I want to specify an custom service account name:
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:
Created 05-24-2017 03:22 PM
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.
Created 05-19-2017 09:33 PM
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.
Created 05-24-2017 02:36 AM
@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.
Created 05-24-2017 03:22 PM
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.