Member since
09-29-2015
362
Posts
242
Kudos Received
63
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 1821 | 03-14-2019 01:00 PM | |
| 2109 | 01-23-2019 04:19 PM | |
| 8611 | 01-15-2019 01:59 PM | |
| 6315 | 01-15-2019 01:57 PM | |
| 15283 | 12-06-2018 02:01 PM |
07-26-2016
01:34 PM
If Ambari was managing the krb5.conf file, then the "Manage Kerberos client krb5.conf" checkbox will be checked in the Kerberos service configuration screen - probably under "Advanced krb5.conf". By default this will be checked. The fact that ccache_type is defined indicates that Ambari is probably not managing the krb5.conf file, however it could be that Ambari is, but maybe Centrify is also trying to manage it. The default value of ccache_type is 4. I am not srue what 3 is, but it indicates an older version of the cache format. I am not sure if this is causing your issue. Re-reading your issue... to list the contents of the cache file, you can do klist /var/lib/ambari-agent/tmp/web_alert_cc_4610ec9b283dcfc90bc6df1e519e1c52 However being that there was an I/O issue with that file, it does not exist - as seen in the listing you provided: -rw------- 1 yarn hadoop 1547 Jul 13 11:54 /tmp/krb5cc_513
-rw------- 1 hcat hadoop 1417 Jul 22 12:23 /tmp/krb5cc_516
-rw------- 1 hdfs hadoop 2775 Jul 22 12:24 /tmp/krb5cc_511
-rw------- 1 oozie hadoop 3046 Jul 22 12:24 /tmp/krb5cc_504
-rw------- 1 ambari-qa hadoop 1456 Jul 26 02:48 /tmp/krb5cc_1002
-rw------- 1 hdfs hadoop 2775 Jul 22 12:24 /tmp/krb5cc_511
-rw------- 1 oozie hadoop 3046 Jul 22 12:24 /tmp/krb5cc_504
-rw------- 1 ambari-qa hadoop 1456 Jul 26 02:48 /tmp/krb5cc_1002 Also, looking at the listing, it appears the file caches are being created. What happen if you execute the following when logged in as root and then as the same user that the Ambari agents run as (changing the host and realm to match your installation): /usr/share/centrifydc/kerberos/bin/kinit -l 5m -c /var/lib/ambari-agent/tmp/web_alert_cc_4610ec9b283dcfc90bc6df1e519e1c52 -kt /etc/security/keytabs/spnego.service.keytab HTTP/abcd_fqdn.com@Realm.COM Note: to get the principal(s) listed in a keytab file you can do: klist -kte /etc/security/keytabs/spnego.service.keytab
... View more
07-26-2016
12:41 PM
@Anshul Sisodia How were the krb5.conf files created? Did Ambari create/modify them or are they managed manually? Check to see if the krb5.conf file has any of the following attribute specified: ccache_type default_ccache_name
Typically these values are not set so that the infrastructure default values are used. Sometimes we see the default_ccache_name specify a KEYRING rather than a file. This has historically not been supported by the Hadoop services. If there is no value for default_ccache_name, try setting it to "/tmp/krb5cc_%{uid}". For example: default_ccache_name = /tmp/krb5cc_%{uid}
... View more
07-20-2016
01:10 PM
3 Kudos
@Krishna Pandey is mostly correct, however: For #1, though Ambari does store the manager DN and password, it does not store the synced users passwords. Because of this, Ambari relies on the LDAP server to validate authentication for these users. For #2 and #3, Ambari has no ability to manage passwords in the LDAP server. Therefore if a user wants to change their password or is required to change their password, they need to use some other facility. With this, if the user must change their password before authenticating, then authenticate will fail until the password is changed using some other facility. I assume that if the user is no longer required to change their password, authentication should work again.
... View more
07-20-2016
12:20 AM
3 Kudos
@russ stevenson
The reason they are commented out is based on recommendations from MIT - http://web.mit.edu/kerberos/krb5-1.13/doc/admin/conf_files/krb5_conf.html (see default_tgs_enctypes" and "default_tkt_enctypes") Do not set this unless required for specific backward compatibility purposes; stale values of this setting can prevent clients from taking advantage of new stronger enctypes when the libraries are upgraded. We left them in the krb5.conf file, commented out, so you can see what they would have been set to. You can change this by editing the krb5-conf/content property, found under Advanced krb5-conf in the Kerberos service configs as "krb5-conf template".
... View more
07-13-2016
07:54 PM
Hi @Milan Sladky... It is unclear whether this solves your problem or not. So when kinit host/hadoop-poc2-01.my.hadoop.domain.com is invoked after my domain_realm suggestion is apply, the assumed realm should be PROD.COM, not HADOOP.COM. This is because no explicit realm or domain is indicated in the principal name... the "/hadoop-poc2-01.my.hadoop.domain.com" part of the principal name does not get used by the underlying libraries to determine the relevant host, domain, or realm. Therefore, the default realm value is used.
... View more
07-11-2016
02:18 PM
1 Kudo
@Milan Sladky If you add a [domain_realm] section to your krb5.conf file, mapping the domain or DNS names of the hosts in the cluster to the HADOOP.COM realm, this should help: Example using just the domain portion of the FQDNs of the hosts in the hadoop cluster [domain_realm]
.my.hadoop.domain.com = HADOOP.COM
Example using the explicit FQDNs of the hosts in the hadoop cluster [domain_realm]
hadoop-poc2-01.my.hadoop.domain.com = HADOOP.COM
hadoop-poc2-02.my.hadoop.domain.com = HADOOP.COM
... View more
07-07-2016
07:58 PM
1 Kudo
@Ravi Mutyala Currently Ambari cannot use a Kerberos ticket for authentication. This seems to becoming a popular topic, so I assume in some future version the feature will be added - either in Ambari itself or via Knox. Regarding SSO... I believe (but I am not totally certain) that in Ambari 2.4.0 there are some SSO integration points. I am not sure of all the details but hopefully when the docs come out they describe this feature.
... View more
07-05-2016
02:58 PM
I am not too familiar with Hue or Ranger. Have you followed the steps in https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.2/bk_installing_manually_book/content/ref-143b07da-bb1f-4c54-91b0-cd7be91569dd.1.html in order to allow Hue to authenticate using Kerberos?
... View more
07-05-2016
02:19 PM
@Dale Bradman, I believe you are using an incorrect option for klist to list your credential cache: hue@edge:/tmp$ klist -k hue_krb5_ccache
Keytab name: FILE:hue_krb5_ccache
klist: Unsupported key table format version number while starting keytab scan The -k option means "List keys held in a keytab file." You are trying to list the contents of a cache file, not a keytab file. Without the "-k" option you should get some more usable information [root@c6501 ~]# klist /tmp/krb5cc_1002
Ticket cache: FILE:/tmp/krb5cc_1002
Default principal: hdfs-c1@EXAMPLE.COM
Valid starting Expires Service principal
07/05/16 14:18:58 07/06/16 14:18:58 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 07/05/16 14:18:58
... View more
07-01-2016
08:32 PM
17 Kudos
When enabling Kerberos, where Ambari is managing the Kerberos identities (principals and keytab files), the KDC administrator's credentials are needed in order to create the needed accounts in the KDC. During the process of enabling Kerberos via Ambari's web-based UI, the user is prompted for this information and has the option to store the credentials in either the temporary or persisted credential store. The temporary credential store is a keystore in memory where each entry is removed after 90 minutes (from initial creation), when Ambari is restarted, or by user request. The persisted credential store is a keystore stored on disk where each entry is removed only by user request. The option to store a credential in the persisted store is only available if Ambari's credential store has been setup.
Creating Ambari's Credential Store To set up Ambari's credential store, the following commands must be invoked from the Ambari server host's command line: ambari-server setup-security Option #2, "Encrypt passwords stored in ambari.properties file", is then used to start the process: Example: 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): 2
Please provide master key for locking the credential store:
Re-enter master key:
Do you want to persist master key. If you choose not to persist, you need to provide the Master Key while starting the ambari server as an env variable named AMBARI_SECURITY_MASTER_KEY or the start will prompt for the master key. Persist [y/n] (y)? y
Adjusting ambari-server permissions and ownership...
Ambari Server 'setup-security' completed successfully. Once this is complete, the Ambari credential store will be located at /var/lib/ambari-server/keys/credentials.jceks. To test the password entered when creating the credential store, you can issue the following command: $JAVA_HOME/bin/keytool -list \
-keystore /var/lib/ambari-server/keys/credentials.jceks \
-storetype JCEKS Where $JAVA_HOME is the path to where Java is installed. For example, /usr/jdk64/jdk1.8.0_60. Example: /usr/jdk64/jdk1.8.0_60/bin/keytool -list \
> -keystore /var/lib/ambari-server/keys/credentials.jceks \
> -storetype JCEKS
Enter keystore password:
Keystore type: JCEKS
Keystore provider: SunJCE
Your keystore contains 1 entry
ambari.db.password, Jul 1, 2016, SecretKeyEntry, Note that this is optional if there is no need to persist the KDC administrator credentials. However, if opting to create Ambari's credential store, other passwords typically stored in plaintext in Ambari's properties file (/etc/ambari/conf/ambari-server.properties) will be encrypted and stored in the created credential store.
Restarting Ambari After this has been set up, Ambari must be restarted in order for it to acquire the new information about the credentials store. If Ambari was stopped before setting up the credential store, it must be started. ambari-server start If Ambari was not stopped before setting up the credential store, it must be restarted. ambari-server restart
Storing the KDC Administrator's Credential From outside Ambari's web-based user interface, there are two ways to manually add the KDC administrator's credential to one of Ambari's credentials stores: via Ambari's REST API and via the Java keytool command. To add a credential via Ambari's REST API, a cluster must already be established. This is because credentials are linked to clusters to avoid collisions in the event Ambari is able to manage multiple clusters. The URL for the credentials entrypoint is /api/v1/clusters/:CLUSTER_NAME/credentials where :CLUSTER_NAME is the name of the relevant cluster. This entrypoint can be used to add, get, update, and remove credentials. However, when getting credentials via this interface, no secret information will be return. To set the KDC administrator's credential, the following information must be supplied:
KDC administrator principal KDC administrator key (or password) credential store type ["persisted" or "temporary"] Also, the credential's alias must be appended to the entrypoint and must be "kdc.admin.credential" Example: POST /api/v1/clusters/:CLUSTER_NAME/credentials/kdc.admin.credential
{
"Credential" :
{
"principal" : "admin/admin@EXAMPLE.COM",
"key" : "h4d00p&!",
"type" : "persisted"
}
}
Example using curl: curl -H "X-Requested-By:ambari" -u admin:admin -X POST -d '{ "Credential" : { "principal" : "admin/admin@EXAMPLE.COM", "key" : "h4d00p&!", "type" : "persisted" } }' http://ambari.example.com:8080/api/v1/clusters/c1/credentials/kdc.admin.credential This credential may be retrieved (no matter what store it is in - temporary or persisted) using GET /api/v1/clusters/:CLUSTER_NAME/credentials/kdc.admin.credential Example: curl -H "X-Requested-By:ambari" -u admin:admin -X GET http://ambari.example.com:8080/api/v1/clusters/c1/credentials/kdc.admin.credential
{
"href" : "http://localhost:8080/api/v1/clusters/c1/credentials/kdc.admin.credential",
"Credential" : {
"alias" : "kdc.admin.credential",
"cluster_name" : "c1",
"type" : "persisted"
}
} To update an existing credential: PUT /api/v1/clusters/:CLUSTER_NAME/credentials/kdc.admin.credential Example: curl -H "X-Requested-By:ambari" -u admin:admin -X PUT -d '{ "Credential" : { "principal" : "admin/admin@EXAMPLE.COM", "key" : "h4d00p&!", "type" : "persisted" } }' http://ambari.example.com:8080/api/v1/clusters/c1/credentials/kdc.admin.credential It should be noted that the credential can be moved from the persisted store to the temporary store (and vice versa) using this mechanism; however the principal and key values must be supplied. If only updating the key, only the key value is needed. To remove the KDC administrator credential (from no matter what store it is in - temporary or persisted) DELETE /api/v1/clusters/:CLUSTER_NAME/credentials/kdc.admin.credential Example: curl -H "X-Requested-By:ambari" -u admin:admin -X DELETE http://ambari.example.com:8080/api/v1/clusters/c1/credentials/kdc.admin.credential To add a credential using the Java keytool command, a cluster does not already need to be established, but the name of the cluster to assign the credential to must be known. Also, Ambari's credential store must have been previously set up and this method only allows for storage into Ambari persisted credential store. This is useful when preparing for a Kerberized cluster to be created via Blueprints and the KDC administrator password is not to be placed in plaintext in either the Blueprint or Cluster Creation files. The Java keytool command is typically found in the bin directory under the Java home directory ($JAVA_HOME): $JAVA_HOME/bin/keytool For example: /usr/jdk64/jdk1.8.0_60/bin/keytool This command can be used to mange keystores like Ambari's credential store; however care must be taken to not destroy any useful information stored in it that Ambari needs to use - like the Ambari DB password. To set the KDC administrator's credential, the following information must be supplied:
location of credential store - "/var/lib/ambari-server/keys/credentials.jceks" type of credential store - "JCEKS" (Java Cryptography Extension KeyStore) password for the credential store (previously created) cluster name (existing or to be created) KDC administrator principal KDC administrator key (password) credential alias - "kdc.admin.credential" The following Java keytool "importpass" command is used to insert the credential into the credential store: $JAVA_HOME/bin/keytool -importpass \
-keystore /var/lib/ambari-server/keys/credentials.jceks \
-storetype JCEKS \
-alias cluster.CLUSTER_NAME.kdc.admin.credential Where CLUSTER_NAME is the name of the cluster to link this credential to. Once executed, the credential store password will be requested; and then if successful, the password (or credential) to store will be requested. If still successful, a prompt for a password to encrypt the new credential will be displayed. Nothing should be entered to use the "same as keystore password". The credential to store must be in the following format: PrincipalKeyCredential{"principal":"PRINCIPAL","key":[PASSWORD_CHARS]} Where, PRINCIPAL is the KDC administrator's principal and PASSWORD_CHARS are the characters of the password spilt into a comma-delimited array of quoted characters. For example, "hadoop" becomes "h","a","d","o","o","p" Example where the KDC administrator principal is "admin/admin@EXAMPLE.COM" and the password is "hadoop": PrincipalKeyCredential{"principal":"admin/admin@EXAMPLE.COM","key":["h","a","d","o","o","p"]} Example: /usr/jdk64/jdk1.8.0_60/bin/keytool -importpass \
> -keystore /var/lib/ambari-server/keys/credentials.jceks \
> -storetype JCEKS \
> -alias cluster.c1.kdc.admin.credential
Enter keystore password:
Enter the password to be stored:
Re-enter password:
Enter key password for <cluster.c1.kdc.admin.credential>
(RETURN if same as keystore password):
To remove the KDC administrator credential from the credential store, use the "delete" command: /usr/jdk64/jdk1.8.0_60/bin/keytool -delete \
> -keystore /var/lib/ambari-server/keys/credentials.jceks \
> -storetype JCEKS \
> -alias cluster.c1.kdc.admin.credential
Updates are not possible using the Java keytool command; however the credential may be deleted and re-added. For more information about using Java keytool, see Oracle's keytool reference page
... View more
Labels: