My Oracle Support Banner

BDA V4.2 and Higher Active Directory Kerberos Install and Upgrade Frequently Asked Questions (FAQ) (Doc ID 2013585.1)

Last updated on DECEMBER 25, 2023

Applies to:

Big Data Appliance Integrated Software - Version 4.2.0 and later
Linux x86-64

Purpose

This document provides answers to frequently asked questions on how to install and upgrade to BDA v4.2.0 with Active Directory Kerberos enabled.

 

Questions and Answers

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!

In this Document
Purpose
Questions and Answers
 What is the recommended way to integrate Kerberos with Active Directory (AD) on the BDA?
 Is Active Directory without TLS supported on BDA 4.5 and higher?
 What is new in BDA v4.2 with regards to Kerberos?
 For new BDA v4.2.0 installs will the configuration utility require the Kerberos realm to be filled in?
 When 4.2 is installed with Enable Active Directory Kerberos-based authentication, are there still manual steps to follow? Or Mammoth does everything to get started?
 Are there any known issues with enabling AD Kerberos with Mammoth?
 Are there any constraints when setting up the name of an Organizational Unit?
 In the case of removing AD prior to upgrade must it be installed again manually? 
 What do the questions look like for "bdacli enable ad_kerberos"?
 What else should be known about Microsoft Active Directory Kerberos, either for use or how to install or upgrade?
 Will it be possible to NOT grant Create, Delete and Manage User Accounts privileges to the user account (OU) in Active Directory?
 Can Create/Delete/Manage User Accounts privileges  be revoked upon installation?
 How can you enable direct-to-AD  Kerberos (i.e. use KDC in Active Directory) if a KDC realm is defined and Organizational Unit created, so BDA 4.2 would point to AD KDC?
 What is the default encryption type that Mammoth uses?
 Is there any problem using aes128-hmac?
 What about changing the ticket lifetime for Active Directory?  Is this done with Mammoth?
 Are there any steps needs to be performed from Cloudera Manager for this AD integration?
 For the step of "copy AD Ceritification Authority (CA) file under /opt/oracle/BDAMammoth" - Do we need to copy this in all nodes in the cluster or just Node 1?
 Is there any Hadoop users (hdfs, hue, mapred, yarn) that needs to be setup on AD server as part of this integration? Would like to clarify on this since I read in some document "hdfs" user needs to be setup in AD for Kerberos integration.
 Can we use our existing OU?
 From first set of steps "Use AD's Delegate Control wizard to allow this new user to Create, Delete and Manage User Accounts".  - Do we need to give this privilege for this new user?  IT security admin handles this and they don't want to give this privilege.  Please confirm the options here.
 Do we need to add Hue user on the BDA?
 Is there an alternative to generating a CA in Active Directory.  We already have an internal CA for Active Directory that should be leveraged. Any reason to have a unique CA?
 We will also need specifics regarding the creation / deletion of User Accounts.
 There is an IT requirement that all accounts in the AD server must be set to change password on first log in.  Will this cause issues?
 Does the bdacli enable ad_kerberos use LDAP to connect?
 How does BDA Mammoth/Cloudera Manager managing Kerberos ticket creation, modification, and deletion?
 How does the BDA Mammoth Direct AD integration work with AD Domain Controller for AD Kerberos ticket administration?
 What are the steps mammoth performs when running 'bdacli enable ad_kerberos'?
 What is the detailed process of authenticating services to their principals on the AD server? Does Cloudera generates a different keytab for services every time a process is running i.e. restarting a service?
 Can we set up without using the wizard?
 Running mammoth -c on BDA side will try to create user on AD server?  Is this ongoing issue whenever it tries to do AD integration (create/delete test user?).  Other than Oracle and hdfs test users - any other user expected?
 Is Oracle OS password used for Active Directory configuration?
 AD has a problem with a special character of / in the username that it cannot be created and will turn it into an underscore. How can user be created in AD with a slash?
 Since BUG 21316069 - ORACLE USER FOR EACH CLUSTER DEPENDING ON THE SAME ACTIVE DIRECTORY   is fixed in BDA V4.3 will there be any problems with this issue going forward?
 Apart from the suggested workaround in MOS document: On BDA V4.2 Enabling AD Kerberos with 'bdacli enable ad_kerberos' Fails with:  "Unable to create oracle user on the Active Directory" (Doc ID 2025717.1) is there any other option for BDA V4.2? 
 In the case of a  BDA V4.2 cluster and a BDA V4.3 cluster sharing the same AD server can you in fact  integrate multiple clusters without problems when creating the 'oracle' principal. Or do you need to use the workaround for Bug 21316069?
 With the BDA V4.3 configuration utility the  "-" character is not accepted the same as was the case  with BDA V4.2  when entering the Active Directory Domain.
 Does the 'oracle' user password need to be the same on all BDA systems due to the above discussion?
 If the oracle user password needs to be the same on each cluster is there anything do other other than doing: `kinit oracle@REALM.COM` and providing the 'oracle' password?
 If the requirement is to use two different AD Domains to have separate users how can this be accomplished in this case? It looks like this will  not be valid for the 'oracle' user.  Any other options?
 If "bdacli enable ad_kerberos" fails due to the 'oracle' password not being created to meet the AD restrictions, a subsequent "./mammoth -c" may raise: "ERROR: Problem copy keytabs to Mammoth node. Exiting."  Why is that?
 In BDA V4.4 when would 'bdacli disable kerberos --force' be used?
References

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.