Member since
09-29-2015
362
Posts
242
Kudos Received
63
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1312 | 03-14-2019 01:00 PM | |
1586 | 01-23-2019 04:19 PM | |
7187 | 01-15-2019 01:59 PM | |
4530 | 01-15-2019 01:57 PM | |
10582 | 12-06-2018 02:01 PM |
10-25-2018
12:06 AM
@Saurabh Gupta The stack traces you provided are a good start, but give little in the way of why the Kerberos ticket is not available. There could be several reasons for this. Maybe the ticket cache was expired or clobbered by some other process? Can you turn on Kerberos debugging and post the logs from that? To enable Kerberos debugging in Java, set the system property "sun.security.krb5.debug" to true. If doing this on the command line, use -Dsun.security.krb5.debug=true Or in code, use System.setProperty("sun.security.krb5.debug", "true"); Kerberos debugging information should be posted to STDOUT.
... View more
10-21-2018
01:29 PM
1 Kudo
@Alex
Goron
This feature has not been fully implemented and Ambari.
... View more
10-16-2018
03:01 PM
1 Kudo
The last part of the description in your question does not make sense. The krb utils on the Linux host do not apply to an Active Directory. They are only for an MIT KDC installation.
... View more
10-16-2018
02:59 PM
It appears that the truststore may be invalid. Did you set up a truststore for Ambari. For example, using the Ambari CLI [root@c7401 ~]# 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 If so, you should check to make sure Ambari can read that file and has the proper password to access it. You should also make sure that the Active Directory's SSL certificate chain has been imported into the truststore. If you did not set up a truststore, you should. Here are some steps to follow: 1) Get the Active Directory's SSL certificate openssl s_client -connect ad.mycompay.dom:636 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > ad_server.pem 2) Import this certificate into a new or existing truststore keytool -importcert -file ad_server.pem -alias adserver -trustcacerts -storetype JKS -keystore /var/lib/ambari-server/keys/truststore.jks 3) Run ambari-server setup-security, selecting option #4 ("Setup truststore") 4) Restart Ambari Note: If Ambari's truststore is already set up you can run ambari-server setup-security and select option #5 ("Import certificate to truststore"). Then provide the path to the retrieved AD server PEM file when prompted - rather than using keytool manually to do this.
... View more
09-28-2018
01:56 PM
1 Kudo
@Rakesh S In a load balancer scenario, the browser should ask for a Kerberos ticket to access the web server on the load balancer. The load balancer should forward the request on to the real service. The real service should be able to validate the Kerberos token using the load balancer's principal and keytab entry. So the load balancer's keytab entry needs to be in the service's configured keytab file. However for all this to work, the service needs to understand that a load balancer is in the middle and behave properly. So there are some details here, related to Storm that some one familiar with storm needs to answer. For example does Storm support this scenario? I seem to have lost track of the issue here... the subject of this tread is related to an unsupported key. I think we solved this and have now moved on to another issue?
... View more
09-26-2018
03:17 PM
Turning off rdns in the krb5.conf wont help. I am not even sure the property applies to this type of scenario. The Hadoop libraries do the reverse DNS lookup on their own.
... View more
09-19-2018
07:04 PM
@Bibek N So I assume that there is a timeout error because the KDC is not responding in time. If the KDC was not found, we would see a different error. Where is the KDC located? If everything is one one host, maybe the host is overburdened and the KDC does not have cpu cycles to use. Maybe take a look at the KDC logs to see if there is anything interesting - /var/log/krb5kdc.log and /var/log/kadmind.log. Can you post your krb5.conf file?
... View more
09-19-2018
06:59 PM
1 Kudo
@Sarnjit Beesla Encryption type 14 is aes256-cts-hmac-sha384-192. As far as I know, this is not an encryption type we typically see in a Hadoop cluster. Maybe post your krb5.conf file so we can see if you have any value set for the enctype properties (default_tgs_enctypes, default_tkt_enctypes, permitted_enctypes). Also, how was the keytab file created? Are you using Ambari? Finally, is the unlimited key JCE policy installed in the relevant JVM on all hosts?
... View more
09-18-2018
01:23 PM
2 Kudos
@Gagandeep Singh Chawla I do not believe that an AD-specific script is provided with Ambari; however some of the Hortonworks support or professional services folks may have something. The provided script may be out of date and is geared towards the MIT KDC. It will not work with an Active Directory. Active Directory would prefer that all account creation and keytab export routines be executed on the Windows server, itself. However, since AD has an LDAP interface that can be used to add new objects to the database, Ambari is able to create principals and set password. Thus giving it the ability to automate creating principals and keytab files remotely - the keytab files are actually generated by Ambari and not exported from the AD. If you are looking for steps on how Ambari does this, take a look at the HCC article How to create AD principal accounts using OpenLdap utilities and adding it to a keytab. This is not exactly what Ambari does, but it is really close. Using details from that article, I can imagine that a script can be built to read an Ambari-provided CSV file and create the needed principals and keytab files.
... View more
09-18-2018
01:12 PM
@Rohit Sharma The krb5.conf file seems to be ok for the XYZ.COM realm, however you will not be able to authenticate or validate principals for the ABC.COM realm. I hope that this is what was desired. Also, I assume that "FQDN" in the file is masked and is actually a FQDN that points to the KDC for the realm of XYZ.COM. How was the change to the realm name in the krb5.conf file performed? Did you manually edit the krb5.conf file or manually edit the krb5.conf template in Ambari? In either case, I do not think that Ambari allows for the realm name to just be changed for a cluster where Kerberos is enabled. Maybe if you were manually managing the Kerberos identities this would be ok, but I would suggest that you disable Kerberos and then reenable Kerberos via Ambari using the new KDC details. At the very least, you should restart all of the services to ensure they picked up any principal changes or Kerberos infrastrucure changes - like the new krb5.conf file.
... View more