You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Sandor Molnar (JIRA)" <ji...@apache.org> on 2018/06/07 18:11:00 UTC
[jira] [Commented] (AMBARI-24054) Test Kerberos Client fail after
reenter of right realm value
[ https://issues.apache.org/jira/browse/AMBARI-24054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16505031#comment-16505031 ]
Sandor Molnar commented on AMBARI-24054:
----------------------------------------
Please find [this document|https://dev.mysql.com/doc/refman/5.7/en/case-sensitivity.html] to see why this is happening with MySQL but not with Postgres/Oracle.
Sample database queries:
{code:java}
mysql> select * from kerberos_keytab_principal;
+--------+------------------------------------------------------------+-----------------------------------+---------+----------------+
| kkp_id | keytab_path | principal_name | host_id | is_distributed |
+--------+------------------------------------------------------------+-----------------------------------+---------+----------------+
| 1 | /etc/security/keytabs/kerberos.service_check.060618.keytab | cluster1-060618@ambari.apache.org | 1 | 1 |
| 2 | /etc/security/keytabs/kerberos.service_check.060618.keytab | cluster1-060618@ambari.apache.org | 2 | 1 |
| 3 | /etc/security/keytabs/kerberos.service_check.060618.keytab | cluster1-060618@ambari.apache.org | 3 | 1 |
| 7 | /etc/security/keytabs/kerberos.service_check.060718.keytab | cluster1-060718@ambari.apache.org | 1 | 1 |
| 8 | /etc/security/keytabs/kerberos.service_check.060718.keytab | cluster1-060718@ambari.apache.org | 2 | 1 |
| 9 | /etc/security/keytabs/kerberos.service_check.060718.keytab | cluster1-060718@ambari.apache.org | 3 | 1 |
+--------+------------------------------------------------------------+-----------------------------------+---------+----------------+
6 rows in set (0.00 sec)
mysql> select * from kerberos_keytab_principal where principal_name in ('cluster1-060718@ambari.apache.org');
+--------+------------------------------------------------------------+-----------------------------------+---------+----------------+
| kkp_id | keytab_path | principal_name | host_id | is_distributed |
+--------+------------------------------------------------------------+-----------------------------------+---------+----------------+
| 7 | /etc/security/keytabs/kerberos.service_check.060718.keytab | cluster1-060718@ambari.apache.org | 1 | 1 |
| 8 | /etc/security/keytabs/kerberos.service_check.060718.keytab | cluster1-060718@ambari.apache.org | 2 | 1 |
| 9 | /etc/security/keytabs/kerberos.service_check.060718.keytab | cluster1-060718@ambari.apache.org | 3 | 1 |
+--------+------------------------------------------------------------+-----------------------------------+---------+----------------+
3 rows in set (0.00 sec)
mysql> select * from kerberos_keytab_principal where principal_name in ('cluster1-060718@AMBARI.APACHE.ORG');
+--------+------------------------------------------------------------+-----------------------------------+---------+----------------+
| kkp_id | keytab_path | principal_name | host_id | is_distributed |
+--------+------------------------------------------------------------+-----------------------------------+---------+----------------+
| 7 | /etc/security/keytabs/kerberos.service_check.060718.keytab | cluster1-060718@ambari.apache.org | 1 | 1 |
| 8 | /etc/security/keytabs/kerberos.service_check.060718.keytab | cluster1-060718@ambari.apache.org | 2 | 1 |
| 9 | /etc/security/keytabs/kerberos.service_check.060718.keytab | cluster1-060718@ambari.apache.org | 3 | 1 |
+--------+------------------------------------------------------------+-----------------------------------+---------+----------------+
3 rows in set (0.00 sec)
{code}
There are two approaches to solve this issue:
1.) Making queries against _kerberos_keytab_principal_ and _kerberos_principal_ tables case sensitive by creating these tables with UTF-8 collation (we may consider creating the entire database with this flag; I'm not sure if there is any side effect/performance penalty)
2.) The problem occurred because the 'Test Kerberos Client' stage failed at the 'Check Kerberos' step when the wrong realm name has been defined but other steps after this one have not been executed. These other steps are responsible for destroying the service check principals and removing the Kerberos Client keytab. IMO these steps should have been executed even if the 'Check Kerberos' steps failed. As a result - no matter of case sensitivity in the database - the second try with the correct realm name would have been succeeded.
In 2.7 the first approach will be implemented.
> Test Kerberos Client fail after reenter of right realm value
> ------------------------------------------------------------
>
> Key: AMBARI-24054
> URL: https://issues.apache.org/jira/browse/AMBARI-24054
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: 2.7.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Blocker
> Fix For: 2.7.0
>
>
> Test Kerberos Client fail after reenter of right realm value during kerberos enabling
> STR:
> 1)Start of kerberos enabling
> 2)Select existing MIT
> 3)Go to Configure Kerberos page
> 4)Set wrong "Realm name" value. As an example: "example.com" (expected EXAMPLE.COM)
> 5)Go to Install and Test Kerberos Client step
> 6)Wait of Test Kerberos Client fail
> 7)Back to Configure Kerberos step
> 8)Enter right "Realm name" value
> 9)Go to Install and Test Kerberos Client step
> Expected:
> Test Kerberos Client pass successfully
> Actual:
> Test Kerberos Client fail
> The supposed main reason is using old realm value for principals creation:
> {code:java}
> 2018-05-30 11:13:38,895 - Failed to create principal, cl1-053018@example.com - Failed to create service principal for cl1-053018@example.com
> STDOUT: Authenticating as principal admin/admin@EXAMPLE.COM with existing credentials.
> STDERR: WARNING: no policy specified for cl1-053018@example.com; defaulting to no policy
> add_principal: No such entry in the database while creating "cl1-053018@example.com".
> Administration credentials NOT DESTROYED.
> {code}
> This is happening only using MySQL.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)