Support Questions
Find answers, ask questions, and share your expertise

Ambari managing krb5.conf

Can anyone explain why when Ambari is managing a clients krb5.conf file the default_tgs_enctypes value in the krb5.conf file is commented out? The values reflect the Ambari values, they are just commented out.

The TGT is showing aes-256, I'm just trying to pull together the amabri configure in context to the krb5.conf.

sh-4.1$ klist -e Ticket cache: FILE:/tmp/krb5cc_49003
Default principal: hdpuser3@FOO.COM Valid starting Expires Service principal
07/15/16 12:10:15 07/15/16 22:07:30 krbtgt/FOO.COM@FOO.COM renew until 07/22/16
12:10:15, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

Thanks,

russ

It is configured with the kerberos configuration, see below

"ad_create_attributes_template" : "\n{\n  \"objectClass\":
[\"top\", \"person\", \"organizationalPerson\",
\"user\"],\n  \"cn\":
\"$principal_name\",\n  #if( $is_service
)\n  \"servicePrincipalName\":
\"$principal_name\",\n 
#end\n 
\"userPrincipalName\": \"$normalized_principal\",\n  \"unicodePwd\": \"$password\",\n  \"accountExpires\":
\"0\",\n 
\"userAccountControl\": \"66048\"\n}",
 
"admin_server_host" : "rs-2008r2-dc.foo.com",
 
"case_insensitive_username_rules" : "false",
 
"container_dn" : "ou=rshdp1",
 
"encryption_types" : "aes des3-cbc-sha1 rc4
des-cbc-md5",
 
"executable_search_paths" : "/usr/bin, /usr/kerberos/bin,
/usr/sbin, /usr/lib/mit/bin, /usr/lib/mit/sbin",
 
"install_packages" : "true",
 
"kdc_create_attributes" : "",
 
"kdc_host" : "rs-2008r2-dc.foo.com",
 
"kdc_type" : "active-directory",
snip from the krb5.conf:
[libdefaults] 
renew_lifetime = 7d 
forwardable = true 
default_realm = FOO.COM 
ticket_lifetime = 24h dns_lookup_realm = false 
dns_lookup_kdc = false 
#default_tgs_enctypes = aes des3-cbc-sha1 rc4 des-cbc-md5
#default_tkt_enctypes = aes des3-cbc-sha1 rc4 des-cbc-md5
1 ACCEPTED SOLUTION

Accepted Solutions

@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 solution in original post

3 REPLIES 3

Super Guru

@russ stevenson

If you don't Ambari to manage your krb5.conf then as per below screenshot, you can turn off "Manage Kerberos client krb5.conf" option.

Login to Ambari --> Goto Kerberos --> Goto config --> Turn off "Manage Kerberos client krb5.conf"

5874-screen-shot-2016-07-19-at-45131-pm.png

Regarding commented entries - I'm not too sure why it is commented, if I change encryption type via Ambari then also it will be commented. Adding few Ambari experts in this thread.

@vpoornalingam / @ctam

Note - I found this bug though - https://issues.apache.org/jira/browse/AMBARI-14001

@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 solution in original post

@Robert Leva

@Kuldeep Kulkarni

Thanks for the response, the combination of the MIT documentation recommendation and the Jira, clarify this observation.

Cheers!