add support for active directory KDC server #132
Conversation
|
+1 |
| under the License. | ||
| --> | ||
|
|
||
| When Kerberos authentication is enabled at the user level, HAWQ uses the Generic Security Service Application Program Interface \(GSSAPI\) to provide automatic authentication \(single sign-on\). When HAWQ uses Kerberos user authentication, HAWQ itself and the HAWQ users \(roles\) that require Kerberos authentication require a principal and keytab. When a user attempts to log in to HAWQ, HAWQ uses its Kerberos principal to connect to the Kerberos server, and presents the user's principal for Kerberos validation. If the user principal is valid, login succeeds and the user can access HAWQ. Conversely, the login fails and HAWQ denies access to the user if the principal is not valid. |
There was a problem hiding this comment.
I realize this text has been around for a while, but it seems like maybe we could standardize the terminology a bit here. I was thinking something like this might be clearer: "When HAWQ uses Kerberos user authentication, both the HAWQ server and those HAWQ users (roles) that use Kerberos authentication require a principal and a keytab. When a user attempts to log in to HAWQ, the HAWQ server uses its Kerberos principal to connect to the Kerberos server, and presents the user's principal for Kerberos validation. If the user's principal is valid, then login succeeds and the user can access HAWQ."
Continuation of edit in the next comment.
|
|
||
| When Kerberos authentication is enabled at the user level, HAWQ uses the Generic Security Service Application Program Interface \(GSSAPI\) to provide automatic authentication \(single sign-on\). When HAWQ uses Kerberos user authentication, HAWQ itself and the HAWQ users \(roles\) that require Kerberos authentication require a principal and keytab. When a user attempts to log in to HAWQ, HAWQ uses its Kerberos principal to connect to the Kerberos server, and presents the user's principal for Kerberos validation. If the user principal is valid, login succeeds and the user can access HAWQ. Conversely, the login fails and HAWQ denies access to the user if the principal is not valid. | ||
|
|
||
| When HAWQ utilizes Kerberos for user authentication, it uses a standard principal to connect to the Kerberos KDC. The format of this principal is `postgres/<FQDN_of_master>@<realm>`, where \<FQDN\_of\_master\> refers to the fully qualified distinguish name of the HAWQ master node. |
There was a problem hiding this comment.
"When HAWQ utilizes Kerberos for user authentication, it uses a single HAWQ server principal to connect to the Kerberos KDC. The format of the HAWQ server principal is ..."
| **Step 1a**: [Configuring the HAWQ Principals using an MIT KDC Server](#hawq_kerb_cfg_mitkdc) | ||
|
|
||
| If you use an Active Directory Kerberos KDC Server: | ||
| **Step 1b**: [Configuring the HAWQ Principal using an AD KDC Server](#hawq_kerb_cfg_adkdc) |
There was a problem hiding this comment.
I think this would read better if it were a regular numbered list of links. Step 1 would obviously have two options for the 1a and 1b links.
| root@kdc-server$ | ||
| ``` | ||
|
|
||
| 2. Create a keytab entry for the HAWQ `postgres/<master>` principal using the `kadmin.local` command. Substitute the HAWQ master node fully qualified distinguished hostname and your Kerberos realm. For example: |
There was a problem hiding this comment.
"Create a keytab entry for the HAWQ server"
|
|
||
| The `addprinc` command adds the principal `postgres/<master>` to the KDC managing your \<realm\>. | ||
|
|
||
| 3. Generate a keytab file for the HAWQ `postgres/<master>` principal. Provide the same name you used to create the principal. |
There was a problem hiding this comment.
"Generate a keytab file for the HAWQ server"
|
|
||
| 1. Log on to the Windows Active Directory Kerberos KDC server system as a user with administrator privileges. | ||
|
|
||
| 2. From the **Start** menu, select **Control Panel > Administrative Tools > Active Directory Users and Computers**. (If the **Active Directory Users and Computers** menu item is not available, the Active Directory service may not have been (correctly) installed.) |
There was a problem hiding this comment.
remove parentheses from (correctly).
|
|
||
| 4. Fill in the **New Object - User** fields: | ||
|
|
||
| **First name:** gpadmin |
There was a problem hiding this comment.
I think we typically format these entries as 2-column tables.
There was a problem hiding this comment.
i can make this a table if you want. i was using the convention we used when we documented ranger UI steps. see step 1d in this link:
http://docs-hdb-review.cfapps.io/review/hawq/ranger/ranger-kerberos.html#kerb_rps2ra_proc
There was a problem hiding this comment.
No - problem, let's keep it as-is given that there's a precedent for it.
|
|
||
| **Note**: Place the Kerberos entry in the appropriate location in the `pg_hba.conf` file. For example, you may choose to retain `pg_hba.conf` entries for the `gpadmin` user that grant `trust` or `ident` authentication for local connections. Locate the Kerberos entry after these line(s). Refer to [Configuring Client Authentication](client_auth.html) for additional information about the `pg_hba.conf` file. | ||
|
|
||
| 4. Update HAWQ configuration and restart your cluster. You will perform different procedures if you manage your cluster from the command line or use Ambari to manage your cluster. |
There was a problem hiding this comment.
"Update the HAWQ configuration"
| gpadmin@master$ kinit gpadmin@<realm> | ||
| ``` | ||
|
|
||
| **Note**: If you are using an Active Directory KDC server and the `kinit` command fails with the error "Preauthentication failed while getting initial credentials", navigate to the `gpadmin` **Account options** view on the Windows AD server system and enable the **Do not require Kerberos preauthentication** checkbox. |
There was a problem hiding this comment.
Shouldn't we call this out as a step in the AD KDC procedure above?
There was a problem hiding this comment.
i don't know if there would be an issue doing the kinit before updating pg_hba.conf, configing the keytab file, and restarting the cluster. this order does work for MIT KDC.
what if i move the note to the end of the "cfg hawq principal with AD KDC" section and reword a bit?
There was a problem hiding this comment.
I see - I just thought if it were something they could do while in the AD configuration interface to begin with that would be better. But if this sequence has been tested, let's leave it as-is.
restructured the kerberos topic - broke it up into 3 pages. link to the "landing" page:
you can click the > in the left subnav to see the subtopics.
the bulk of the AD KDC content is in these links: