Member since
09-28-2015
14
Posts
28
Kudos Received
0
Solutions
01-27-2021
12:00 AM
Hi @abajwa, Does the Ambari Server Host also need to present it's own SSL certificate to the AD server? In case of multiple domain controllers, do we need to have separate SSL certificates from each of the domain controllers? Thanks, Megh
... View more
09-26-2017
03:39 PM
2 Kudos
You can setup encryption for the passwords stored in the Ambari properties file by running: On the Ambari server host, ambari-server setup-security This creates two files under /var/lib/ambari-server/keys, 1. credentials.jceks
2. master This article explains how to change the alias passwords stored in credentials.jceks without resetting encryption. Step 1: Take a backup of existing files cd /var/lib/ambari-server/keys
cp master master.old
cp credentials.jceks credentials.old.jceks If your cluster has JDK 1.8.xx installed, follow the below procedure: <JDK_HOME>/bin/keytool -list -v -keystore credentials.jceks -storetype JCEKS
Enter keystore password:
<JDK_HOME>/bin/keytool -delete -alias ambari.ldap.manager.password -keystore credentials.jceks -storetype JCEKS
Enter keystore password:
<JDK_HOME>/bin/keytool -importpass -alias ambari.ldap.manager.password -keystore credentials.jceks -storetype JCEKS
Enter keystore password:
Enter the password to be stored:
Re-enter password:
Enter key password for <ambari.ldap.manager.password>
(RETURN if same as keystore password): ----> Hit enter
/apps/jdk1.8.0_121/bin/keytool -list -v -keystore credentials.jceks -storetype JCEKS
Enter keystore password: If your cluster is still using JDK 1.7.xx, you can use knoxcli.sh to change the passwords as shown below: <KNOX_HOME>/bin/knoxcli.sh list-alias --cluster ambari
<KNOX_HOME>/bin/knoxcli.sh delete-alias ambari.ldap.manager.password --cluster ambari
<KNOX_HOME>/bin/knoxcli.sh create-alias ambari.ldap.manager.password --cluster ambari --value <password-to-be-stored>
... View more
Labels:
06-09-2017
04:24 PM
2 Kudos
Configure SSL for Ambari Server # On ambari-server host, take a back up of
existing files mkdir
/root/ambari-ssl-backup; cp -r /var/lib/ambari-server/keys/*
/root/ambari-ssl-backup/ # Navigate to the folder where all
certificates are stored. cd <dir> # Extract certificates from p7b file openssl
pkcs7 –in ambari-server-host-cert.p7b –print_certs > ambari-server-host-name.crt # Above .crt file contains full certificate
chain, so separate server certificate from root chain. Copy the intermediate/root chain to ca.crt
and delete intermediate/root chain from ambari-server-host-name.crt # Copy ca.crt, ambari-server-host-name.crt, ambari-server-host-privateKey.key files to /var/lib/ambari-server/keys/ cp
ca.crt /var/lib/ambari-server/keys/ cp ambari-server-host-privateKey.key /var/lib/ambari-server/keys/ cp ambari-server-host-name.crt /var/lib/ambari-server/keys/ # Update password for the keystore in a
file (Assuming it as ‘changeit’) echo
"changeit" > pass.txt # Generate the keystore for ambari-server.
Ambari uses pkcs12 keystore. Use the above
password when prompted. openssl
pkcs12 –export –out keystore.p12 –inkey ambari-server-host-privateKey.key –in ambari-server-host-name.crt –certfile ca.crt # verify the keystore /usr/jdk64/jdk1.8.0_77/bin/keytool
–list –v –keystore keystore.p12 –storetype pkcs12 –storepass changeit # Create a
truststore with Root/Intermediate/Ambari/and all agent certificates. /usr/jdk64/jdk1.8.0_77/bin/keytool
-import -file ca.crt -keystore truststore.jks -storepass changeit -alias rootCA /usr/jdk64/jdk1.8.0_77/bin/keytool
-import -file ambari-server-host-name.crt -keystore truststore.jks -storepass changeit
-alias ambari-server /usr/jdk64/jdk1.8.0_77/bin/keytool
-import -file ambari-agent-host2.crt -keystore truststore.jks -storepass changeit
-alias ambari-agent-host2 ... # Enable HTTPS for ambari-server ambari-server
setup-security Using
python /usr/bin/python Security
setup options... =========================================================================== Choose
one of the following options:
[1] Enable HTTPS for Ambari server.
[2] Encrypt passwords stored in ambari.properties file.
[3] Setup Ambari kerberos JAAS configuration.
[4] Setup truststore.
[5] Import certificate to truststore. =========================================================================== Enter
choice, (1-5): 1 Do
you want to configure HTTPS [y/n] (y)? y SSL
port [8443] ? y Enter
path to Certificate: /var/lib/ambari-server/keys/hsynlhdps100.crt Enter
path to Private Key: /var/lib/ambari-server/keys/hsynlhdps100.key Please
enter password for Private Key: <hit
enter if none> Generating
random password for HTTPS keystore...done. Importing
and saving Certificate...done. Ambari
server URL changed. To make use of the Tez View in Ambari please update the
property tez.tez-ui.history-url.base in tez-site # Configure truststore for ambari-server
(This truststore would also contain certificates for AD server(s) in case of
LDAPS between ambari-server and AD) ambari-server
setup-security Using
python /usr/bin/python Security
setup options... =========================================================================== Choose
one of the following options:
[1] Enable HTTPS for Ambari server.
[2] Encrypt passwords stored in ambari.properties file.
[3] Setup Ambari kerberos JAAS configuration.
[4] Setup truststore.
[5] Import certificate to truststore. =========================================================================== Enter
choice, (1-5): 4 Do
you want to configure a truststore [y/n] (y)? y TrustStore
type [jks/jceks/pkcs12] (jks): jks Path
to TrustStore file :/var/lib/ambari-server/keys/truststore.jks Password
for TrustStore: Re-enter
password: Ambari
Server 'setup-security' completed successfully. # Edit
/etc/ambari-server/conf/ambari.properties, add below properties security.server.two_way_ssl=true security.server.cert_name=ambari-server-host-name.crt security.server.key_name=ambari-server-host-privateKey.key security.server.keystore_name=keystore.p12 security.server.keystore_type=PKCS12 security.server.truststore_name=truststore.jks security.server.truststore_type=JKS security.server.crt_pass_file=pass.txt # Restart Ambari Server ambari-server
restart # Since the certificates were already
created, Ambari Server should not be creating any certificates # Verify by inspecting logs in
/var/log/ambari-server/ambari-server.log xxxxxxxxxxxxxxxxxxx INFO [main] CertificateManager:68 -
Initialization of root certificate xxxxxxxxxxxxxxxxxxx INFO [main] CertificateManager:70 - Certificate exists:true Configure SSL for Ambari Agent ### Repeat steps for every host in the
cluster, including ambari-server host # Extract Agent certificate from p7b file openssl
pkcs7 -in ambari-agent-cert.p7b –print_certs > `hostname –f`.crt # Copy Agent certificate and key cp `hostname –f`.crt /var/lib/ambari-agent/keys/ cp ambari-agent-privateKey.key /var/lib/ambari-agent/keys/`hostname –f`.key # Copy CA certificate (Note: We need to
copy this manually, otherwise the agent will copy over the server certificate
instead of CA certificate) cp
ca.crt /var/lib/ambari-agent/keys/ # Restart Ambari Agent ambari-agent
restart # Verify by inspecting logs in
/var/log/ambari-agent/ambari-agent.log INFO
XXXXXXXXXXXXXXXXXXXXXXX security.py:49 - Server require two-way SSL
authentication. Use it instead of one-way... INFO
XXXXXXXXXXXXXXXXXXXXXXX security.py:175 - Server certicate exists, ok INFO
XXXXXXXXXXXXXXXXXXXXXXX security.py:183 - Agent key exists, ok INFO
XXXXXXXXXXXXXXXXXXXXXXX security.py:191 - Agent certificate exists, ok INFO
XXXXXXXXXXXXXXXXXXXXXXX security.py:93 - SSL Connect being called.. connecting
to the server INFO
XXXXXXXXXXXXXXXXXXXXXXX security.py:77 - SSL connection established. Two-way SSL authentication
completed successfully. INFO
XXXXXXXXXXXXXXXXXXXXXXX Controller.py:149 - Registration Successful (response
id = 0) INFO
XXXXXXXXXXXXXXXXXXXXXXX Controller.py:153 - Got status commands on
registration.
... View more
Labels:
03-28-2017
07:59 PM
1 Kudo
@skothari It is a ranger kafka plugin limitation. Please take a look at this https://community.hortonworks.com/content/kbentry/91546/how-to-auto-create-topics-in-ranger-enabled-kafka.html
... View more
02-27-2017
07:28 PM
The user search filter can be anything you would like to filter on further within the OUs or you can just leave it to a default setting like forexample in AD Samaccountname=* or Samaccountname={0} or in the case of openldap cn=* or cn={0}
... View more
10-11-2017
06:43 PM
You can do "keytool -list -v -keystore corp_cert_chain.pfx -keystoretype PKCS12". It would list the alias name. Basically, we are renaming the alias in the corp certificate to "gateway-identity"
... View more
12-18-2015
05:01 PM
6 Kudos
Well, I was just enquiring about the same a few minutes back. It depends on the requirement if you want to enable ssl for all Web UIs, all services and also if you need wire encryption. Depending on that you can use following strategies. The set of certificates required depends upon the certificate provisioning strategy you implement. The following strategies, among others, are possible:
Certificate per host: In this strategy, you obtain one certificate for each host on which at least one SSL daemon role is running. All services on a given host will share this single certificate. Certificate for multiple hosts: Using the SubjectAltName extension, it is possible to obtain a certificate that is bound to a list of specific DNS names. One such certificate could be used to protect all hosts in the cluster, or some subset of the cluster hosts. The advantage of this approach over a wildcard certificate is that it allows you to limit the scope of the certificate to a specific set of hosts. The disadvantage is that it requires you to update and re-deploy the certificate whenever a host is added or removed from the cluster. Wildcard certificate: You may also choose to obtain a single wildcard certificate to be shared by all services on all hosts in the cluster. This strategy requires that all hosts belong to the same domain. For example, if the hosts in the cluster have DNS names node1.example.com ... node100.example.com, you can obtain a certificate for *.example.com. Note that only one level of wildcarding is allowed; a certificate bound to *.example.com will not work for a daemon running on node1.subdomain.example.com. Given above strategies, I would recommend having one certificate per host wherever you have any ssl daemon running i.e. if HDFS and YARN are on same host. Both would use the same. We have been mostly using this. Reference: http://www.cloudera.com/content/www/en-us/document...
... View more