Member since
09-29-2015
362
Posts
242
Kudos Received
63
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1362 | 03-14-2019 01:00 PM | |
1651 | 01-23-2019 04:19 PM | |
7450 | 01-15-2019 01:59 PM | |
4811 | 01-15-2019 01:57 PM | |
11288 | 12-06-2018 02:01 PM |
01-22-2018
06:01 PM
Do you have a rule like to following? RULE:[1:$1@$0](.*@EXAMPLE.COM)s/@.*// Also, do you have the following at the end? DEFAULT
... View more
01-22-2018
04:02 PM
@Julian Blin Maybe there is an issue with the auth-to-local rules used by SOLR. If you set them manually, check out this article on the auth-to-local rule syntax - Auth-to-local Rules Syntax.
... View more
01-09-2018
07:24 PM
Your solution of copying keytab files around is not valid. There must be some cause for the missing keytab file.
... View more
01-01-2018
02:50 PM
You should not have had to manually copy anything, so I am confused as to what the issue was.
... View more
12-28-2017
04:19 PM
One of a few issues may be in play. First, make sure that the unlimited key JCE policy is installed. Then make sure that the krb5.conf file or the KRB5CCNAME environment variable is not forcing the ticket cache to be stored in a KEYRING facility - the ticket cache needs to be stored in a file. Finally, ensure DNS and reverse DNS name resolution is configured properly. Let me know if you need detailed explanations on any of those.
... View more
12-22-2017
03:20 PM
I just tried this and had no issues. Ambari 2.4.2/HDP 2.4 curl command worked fine Express upgrade to HDP 2.5 (Ambari 2.4.2/HDP 2.5) curl command worked fine Check your ambari.log file to see if there are any interesting errors.
... View more
12-21-2017
03:26 PM
1 Kudo
Hi @Mahesh Thumar Given the same version of Ambari (version 2.2), I am not sure why the stack would make a difference. On that note, as far as I know, nothing has changed for that entry point since Ambari 2.1.0. When I get a chance I will see if I can figure out what the deal is.
... View more
12-05-2017
09:19 PM
It
appears the ambari-server script does not support setting option via the
command line when setting up SSO. I
do not think that there is a workaround for this and the interactive mode must be used to set the SSO options.
... View more
10-27-2017
04:17 PM
kadmin.local is only available on the KDC server host. It is a utility that basically manages the KDC DB directly, which by passes the user set in the relative Kerberos ticket cache. kadmin is a tool that comes with the Kerberos client suite, It connects to the kadmin service and uses the user's Kerberos ticket cache to determine who the acting user is and what privs they have. If the user does not have the appropriate privileges then the action will fail - as you see in your test. For my (test) environment, I have it set so that any principal with "/admin" in the name can perform any administrative task. So using kadmin.local, I create a principal with the name "admin/admin" and set its password. Then I edit the /var/kerberos/krb5kdc/kadm5.acl file and set it as shown above: */admin@EXAMPLE.COM * Then, I restart the kadmind and krb5kdc services. After that, I can manage the KDC using kadmin -p admin/admin I uploaded install-kdc-sh.txt. This is the script I use when installing a KDC in my test environment on Centos6
... View more
10-27-2017
12:18 PM
It seems like there may be an issue with the configuration of your KDC. Make sure the "admin" account you are using has rights to create accounts in the KDC. In my setup, any user with /admin in their principal name has fully rights to the KDC: # cat /var/kerberos/krb5kdc/kadm5.acl
*/admin@EXAMPLE.COM * Try to manually create an account first to make sure your account has the proper rights. In my case, my admin user is admin/admin@EXAMPLE.COM: # kadmin -p admin/admin
Authenticating as principal admin/admin with password.
Password for admin/admin@EXAMPLE.COM:
kadmin: add_principal test_user
WARNING: no policy specified for test_user@EXAMPLE.COM; defaulting to no policy
Enter password for principal "test_user@EXAMPLE.COM":
Re-enter password for principal "test_user@EXAMPLE.COM":
Principal "test_user@EXAMPLE.COM" created.
kadmin: The test above, done from the Ambari server, ensure that the krb5.conf is set up properly, the admin user credentials are correct, and the admin user has rights to create principals. If you cannot perform the same, something is wrong with the KDC config. If the problem is related to the /etc/krb5.conf file, make sure you enter the correct information into Ambari's Enable Kerberos Wizard fields. For example, the hostname of the KDC should not be localhost, it should be the FQDN (fully qualified domain name) of the host where the KDC is. For more research on the error, take a look at the Ambari server log (/var/log/ambari-server/ambari-server.log). There may be more information on the error there.
... View more