Member since
09-29-2015
362
Posts
242
Kudos Received
63
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1797 | 03-14-2019 01:00 PM | |
2086 | 01-23-2019 04:19 PM | |
8566 | 01-15-2019 01:59 PM | |
6223 | 01-15-2019 01:57 PM | |
15076 | 12-06-2018 02:01 PM |
03-20-2017
05:45 PM
3 Kudos
Overview Ambari's Kerberos Descriptor is JSON-formatted document used to help Ambari enable Kerberos for installed services. The descriptor contains the information needed to create the required principals and keytab files. It also declares configuration changes needed by the serviced so they a are configured for Kerberos properly. The Kerberos Descriptor is comprised of the compiled Kerberos descriptors found in the relevant service definitions with user-specified changes applied to it. This combination of data is known as the "Composite Kerberos Descriptor", where the separate parts are known as the "Stack-level Kerberos Descriptor" and the "User-specified Kerberos Descriptor". Each of these descriptors may be obtained from Ambari via is REST API: GET /api/v1/clusters/{CLUSER_NAME}/kerberos_descriptors/COMPOSITE GET /api/v1/clusters/{CLUSER_NAME}/kerberos_descriptors/STACK GET /api/v1/clusters/{CLUSER_NAME}/kerberos_descriptors/USER NOTE: Be sure to replace {CLUSTER_NAME} when the name of the relevant cluster. These REST API calls are for informational purposes only and therefore are read-only. Also, this data is available whether Kerberos is enabled or not. However the User-specified Kerberos Descriptor will most-likely be empty. The Kerberos Descriptor was designed to favor user-supplied change over the stack-level defaults; while maintaining forward compatibility in the even the stack-definitions change by adding new or updating existing component definitions. Because of this, it is expected that the User-specified Kerberos Descriptor is sparse, containing only the changes needed to be applied on top of the stack-level defaults. However as of Ambari 2.4.2, when enabling Kerberos via Ambari's Enable Kerberos Wizard, the complete Kerberos Descriptor is stored as the User-Defined Kerberos Descriptor. Storing the entire Kerberos Descriptor as the User-Defined Kerberos Descriptor is not necessarily a problem since the Composite Kerberos Descriptor will still be valid; and any additions to the Stack-level Kerberos Descriptor will be realized after Ambari server or stack upgrades. Unfortunately, issues can occur when changes to existing pieces of the Stack-level Kerberos Descriptor are encountered durning an upgrade. This is due to ambiguities encountered when upgrading the User-Specified Kerberos descriptor. If an issue with User-Defined Kerberos Descriptor is encountered, it may be necessary to manually edit it. This can be done by Getting the descriptor using Ambari's REST API Editing the descriptor using a text editor Putting the updated descriptor using Ambari's REST API Getting the descriptor using Ambari's REST API To get the User-Specified Kerberos Descriptor, the following REST API call may be issued to Ambari: GET /api/v1/clusters/{CLUSTER_NAME}/artifacts/kerberos_descriptor NOTE: Be sure to replace {CLUSTER_NAME} when the name of the relevant cluster. Notice that the API call access the "artifacts" resource of the cluster rather than "kerberos_descriptors" resource of the cluster. This is due to the storage implementation of the User-Specified Kerberos Descriptor data. If User-Specified Kerberos Descriptor was set, the response will look something like {
"href" : "http://host1.example.com:8080/api/v1/clusters/c1/artifacts/kerberos_descriptor",
"Artifacts" : {
"artifact_name" : "kerberos_descriptor",
"cluster_name" : "c1"
},
"artifact_data" : {
...
}
} The user-specified data will exist under the "artifact_data" section, which was removed to brevity. This API call can be issued using a command-line tool like curl and the output can be stored to a local file. For example: curl -u admin:admin -X GET -o kerberos_descriptor.json http://localhost:8080/api/v1/clusters/c1/artifacts/kerberos_descriptor NOTE: The user credentials ("-u admin:admin") and cluster name ("c1") should be changed for the particular cluster. After the call completes, the User-specified Kerberos Descriptor (with some additional metadata) will be in the file named kerberos_descriptor.json in the local directory.
Editing the descriptor using a text editor Once the User-specified Kerberos Descriptor has been obtained and stored in a local file, it may be edited using a text editor. Other than any fixes (additions, subtractions, etc...), the following lines in the file must be removed: "href" : "http://host1.example.com:8080/api/v1/clusters/c1/artifacts/kerberos_descriptor",
"Artifacts" : {
"artifact_name" : "kerberos_descriptor",
"cluster_name" : "c1"
}, This is metadata that will cause a failure when attempting to store the updated User-specified Kerberos Descriptor. The resulting JSON document should be something like {
"artifact_data" : {
...
}
} The user-specified data will exist under the "artifact_data" section, which was removed to brevity. After all needed changes are made, be sure to save the file.
Putting the updated descriptor using Ambari's REST API After the needed changes are made to the User-specified Kerberos Descriptor, it must be stored in Ambari. This is done by issuing the following API call to Ambari while adding the changed data as the payload: PUT /api/v1/clusters/{CLUSTER_NAME}/artifacts/kerberos_descriptor NOTE: Be sure to replace {CLUSTER_NAME} when the name of the relevant cluster. This API call can be issued using a command-line tool like curl and the payload can be specified via a local file. For example: curl -u admin:admin -X PUT -d @kerberos_descriptor.json http://localhost:8080/api/v1/clusters/c1/artifacts/kerberos_descriptor NOTE: The user credentials ("-u admin:admin") and cluster name ("c1") should be changed for the particular cluster. After the call completes, the User-specified Kerberos Descriptor stored in the file named kerberos_descriptor.json will be used to update the stored data in the artifact resource. Ambari should realize the changes without restarting.
... View more
Labels:
08-08-2018
01:38 PM
I am glad you found this useful. Thanks for the note.
... View more
11-09-2017
06:46 AM
Changing REALM to UPPERCASE in Ambari helps. No need to change in AD(it worked for me on windows server 2012 r2)
... View more
03-05-2017
02:21 PM
This should have been automatically created for you if you entered CHRSV@COM in the "Additional Realms" box on the Configure Identities in the Enable Kerberos Wizard. Assuming that you didn't do this, how was the krb5.conf file set up to acknowledge the trusted realm?
... View more
09-07-2017
07:00 PM
Is this one way trust encrypted between kdc and ad?
... View more
02-01-2017
11:04 PM
@Robert Levas thanks for that pointer, however here customer would like to enable the Kerberos after some time with custom principals names.
... View more
01-24-2017
03:17 PM
1 Kudo
@Timo Burmeister A new container does not need to be created specifically for the Ambari-managed Kerberos identities; however, it would be recommended since there potentially may be a lot of accounts created for service and user principals in the Active Directory. In any case, there needs to be a container available in the Active Directory that Ambari can create and manage accounts within. The credentials used to access the Active Directory must give access to Ambari so that new accounts can be created for each of the cluster-specific service and user principals. That account must able to able to update the password for each of those accounts. It is recommended that a special account is given access to the container for security purposes and ease-of-mind. You may not want to give out a domain administrator's credentials or give Ambari full rein over the Active Directory - not that Ambari will do anything nefarious.
... View more
03-06-2017
08:38 PM
@Georg Heiler - Yes. Please use refer below curl command for the same curl -H "X-Requested-By: ambari" -X GET-u <admin-user>:<admin-password> http://<ambari-server>:8080/api/v1/clusters/<cluster-name>?format=blueprint
... View more
12-30-2016
08:27 PM
Well eventually I was able to solve all this. I did multiple things, don't know exactly what solved it. -Installed Mac_OS_X_10.4_10.6_Kerberos_Extras.dmg -Upgraded Firefox to 50.1.0 from 49.x -Reset value of 'network.negotiate-auth.trusted-uris' in Firefox about:config to '.field.hortonworks.com' -Mapped all cluster nodes short and long fqdn in local /etc/hosts like 1xx.2x.x3x.220 sg-hdp24-mst6b sg-hdp24-mst6b.field.hortonworks.com The local Kerberos config at /etc/krb5.conf has to have both REALMS: [libdefaults]
default_realm = MIT.KDC.COM
[domain_realm]
.field.hortonworks.com = MIT.KDC.COM
field.hortonworks.com = MIT.KDC.COM
[realms]
FIELD.HORTONWORKS.COM = {
admin_server = xxxx.field.hortonworks.com
kdc = ad01.field.hortonworks.com
}
MIT.KDC.COM = {
admin_server = sg-hdp24-mst6b.field.hortonworks.com
kdc = sg-hdp24-mst6b.field.hortonworks.com
}
Both curl and webhdfs calls from Firefox work now. After such a successful call local cache looks like this: $ klist
Credentials cache: API:C1AAF010-41BB-4705-B4FB-239BC06DCF8E
Principal: jk@FIELD.HORTONWORKS.COM
Issued Expires Principal
Dec 30 20:34:42 2016 Dec 31 06:34:42 2016 krbtgt/FIELD.HORTONWORKS.COM@FIELD.HORTONWORKS.COM
Dec 30 20:34:49 2016 Dec 31 06:34:42 2016 krbtgt/MIT.KDC.COM@FIELD.HORTONWORKS.COM
Dec 30 20:34:49 2016 Dec 31 06:34:42 2016 HTTP/sg-hdp24-mst7@MIT.KDC.COM
So now the cross realm trust cluster MIT --> AD is fully functional. One peculiar thing was that in Firefox the SPNEGO auth works just as well now for the destination 'http://sg-hdp24-mst7:50070/webhdfs/v1/?op=LISTSTATUS' as it is for http://sg-hdp24-mst7.field.hortonworks.com:50070/webhdfs/v1/?op=LISTSTATUS. So somehow Firefox figured out it needed to use Kerberos to auth without the domain indicator ('network.negotiate-auth.trusted-uris')
... View more
12-23-2016
04:51 PM
3 Kudos
There was a failure during "Configure Ambari Identity", but retry passed. So I thought it was not really a problem. I am sure the sudo rule is the problem. Will try again and let you know the outcome. Update the sudo permission and got another error: "you must have a tty to run sudo". this turns out to be related to sudo setting, use visudo to comment requiretty fixed the problem visudo
#Defaults requiretty
... View more