Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 80A5F200D29 for ; Thu, 26 Oct 2017 21:21:53 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 7EF9F1609E8; Thu, 26 Oct 2017 19:21:53 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 754B41609E5 for ; Thu, 26 Oct 2017 21:21:52 +0200 (CEST) Received: (qmail 21125 invoked by uid 500); 26 Oct 2017 19:21:51 -0000 Mailing-List: contact dev-help@hawq.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hawq.incubator.apache.org Delivered-To: mailing list dev@hawq.incubator.apache.org Received: (qmail 21114 invoked by uid 99); 26 Oct 2017 19:21:51 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Oct 2017 19:21:51 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 896D818030B for ; Thu, 26 Oct 2017 19:21:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -4.02 X-Spam-Level: X-Spam-Status: No, score=-4.02 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id YfzsISfvSbyF for ; Thu, 26 Oct 2017 19:21:48 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with SMTP id 109BC5FD41 for ; Thu, 26 Oct 2017 19:21:47 +0000 (UTC) Received: (qmail 20957 invoked by uid 99); 26 Oct 2017 19:21:47 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Oct 2017 19:21:47 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id 6C568DFBC6; Thu, 26 Oct 2017 19:21:47 +0000 (UTC) From: dyozie To: dev@hawq.incubator.apache.org Reply-To: dev@hawq.incubator.apache.org References: In-Reply-To: Subject: [GitHub] incubator-hawq-docs pull request #132: add support for active directory KDC ... Content-Type: text/plain Message-Id: <20171026192147.6C568DFBC6@git1-us-west.apache.org> Date: Thu, 26 Oct 2017 19:21:47 +0000 (UTC) archived-at: Thu, 26 Oct 2017 19:21:53 -0000 Github user dyozie commented on a diff in the pull request: https://github.com/apache/incubator-hawq-docs/pull/132#discussion_r147240598 --- Diff: markdown/clientaccess/kerberos-userauth.html.md.erb --- @@ -0,0 +1,459 @@ +--- +title: Configuring Kerberos User Authentication for HAWQ +--- + + + +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/@`, where \ refers to the fully qualified distinguish name of the HAWQ master node. + +(You may choose to configure HAWQ user principals before you enable Kerberos user authentication for HAWQ. See [Configuring Kerberos-Authenticated HAWQ Users](#hawq_kerb_user_cfg).) + +The procedure to configure Kerberos user authentication for HAWQ includes: + +If you use an MIT Kerberos KDC Server: +**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) + +**Step 2**: [Configuring HAWQ to use Kerberos Authentication](#hawq_kerb_cfg) +**Step 3**: [Configuring Kerberos-Authenticated HAWQ Users](#hawq_kerb_user_cfg) +**Step 4**: [Authenticating User Access to HAWQ](#hawq_kerb_dbaccess) + +## Step 1a: Configuring the HAWQ Principals using an MIT KDC Server + +Perform the following procedure to configure HAWQ Kerberos and `gpadmin` principals when you are using an MIT KDC server. + +**Note**: Some operations may differ based on whether or not you have configured secure HDFS. These operations are called out below. + +1. Log in to the Kerberos KDC server system: + + ``` shell + $ ssh root@ + root@kdc-server$ + ``` + +2. Create a keytab entry for the HAWQ `postgres/` principal using the `kadmin.local` command. Substitute the HAWQ master node fully qualified distinguished hostname and your Kerberos realm. For example: + + ``` shell + root@kdc-server$ kadmin.local -q "addprinc -randkey postgres/@REALM.DOMAIN" + ``` + + The `addprinc` command adds the principal `postgres/` to the KDC managing your \. + +3. Generate a keytab file for the HAWQ `postgres/` principal. Provide the same name you used to create the principal. + + **If you have configured Kerberos for your HDFS filesystem**, add the keytab to the HAWQ client HDFS keytab file: + + ``` shell + root@kdc-server$ kadmin.local -q "xst -norandkey -k /etc/security/keytabs/hawq.service.keytab postgres/@REALM.DOMAIN" + ``` + + **Otherwise**, generate a new file for the keytab: + + ``` shell + root@kdc-server$ kadmin.local -q "xst -norandkey -k hawq-krb5.keytab postgres/@REALM.DOMAIN" + ``` + +4. Use the `klist` command to view the key you just generated: + + ``` shell + root@kdc-server$ klist -ket ./hawq-krb5.keytab + ``` + + Or: + + ``` shell + root@kdc-server$ klist -ket /etc/security/keytabs/hawq.service.keytab + ``` + + The `-ket` option lists the keytabs and encryption types in the identified key file. + +5. When you enable Kerberos user authentication for HAWQ, you must create a Kerberos principal for `gpadmin` or another HAWQ administrative user. Create a Kerberos principal for the HAWQ `gpadmin` administrative role, substituting your Kerberos realm. For example: + + ``` shell + root@kdc-server$ kadmin.local -q "addprinc -pw changeme gpadmin@REALM.DOMAIN" + ``` + + This `addprinc` command adds the principal `gpadmin` to the Kerberos KDC managing your \. When you invoke `kadmin.local` as specified in the example above, `gpadmin` will be required to provide the password identified by the `-pw` option when authenticating. Alternatively, you can create a keytab file for the `gpadmin` principal and distribute the file to HAWQ client nodes. + +6. Copy the file in which you added the `postgres/@` keytab to the HAWQ master node: + + ``` shell + root@kdc-server$ scp ./hawq-krb5.keytab gpadmin@:/home/gpadmin/ + ``` + + Or: + + ``` shell + root@kdc-server$ scp /etc/security/keytabs/hawq.service.keytab gpadmin@:/etc/security/keytabs/hawq.service.keytab + ``` + +## Step 1b: Configuring the HAWQ Principal using an AD KDC Server + +Perform the following procedure to configure a HAWQ Kerberos principal when you are using an AD KDC 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.) + + The **Active Directory Users and Computers** window displays. + +3. When you enable Kerberos user authentication for HAWQ, you must create a Kerberos principal for the `gpadmin` HAWQ administrative user. Use the left pane tree view to navigate to your Kerberos \ **Managed Service Accounts** folder, right-click, and select **New > User** to create a user with this name. + + The **New Object - User** wizard displays. + +4. Fill in the **New Object - User** fields: + + **First name:** gpadmin + **User logon name:** gpadmin + +5. Click **Next** to advance to the next screen. + +6. Add and confirm the password. Be sure to enable the **Password never expires** checkbox. + +7. Click **Next**, and then **Finish** to complete creation of the `gpadmin` user. + +8. Open an administrative terminal window or command prompt session on the Windows AD KDC server system. Be sure to select **Run as administrator -> Yes**. + +9. Add a Service Name Principal (SNP) for the `gpadmin` account you just created. Substitute the fully qualified distinguished name of your HAWQ master node. This hostname must be resolvable from the Windows AD KDC server. For example: + + ``` shell + PS C:\Users\Administrator> setspn -A postgres/ gpadmin + ``` + + The `setspn` command adds the principal `postgres/` to the KDC managing your \. + +10. Create a keytab file for the `postgres/` SPN using the `ktpass` command. Substitute the HAWQ master node fully qualified distinguished hostname and your Kerberos realm. For example: + + ```shell + PS C:\Users\Administrator> ktpass -princ postgres/@ -pass changeme -mapuser gpadmin -crypto ALL -ptype KRB5_NT_PRINCIPAL -out hawq-krb5.keytab -kvno 0 + ``` + + The `ktpass` command generates a keytab file named `hawq-krb5.keytab`. + +11. Copy the keytab file to the HAWQ master node. + + +## Step 2: Configuring HAWQ to use Kerberos Authentication + +Perform the following procedure to configure Kerberos user authentication for HAWQ. You will perform operations on the HAWQ \ node. + +1. Log in to the HAWQ master node as the `gpadmin` user and set up the HAWQ environment: + + ``` shell + $ ssh gpadmin@ + gpadmin@master$ . /usr/local/hawq/greenplum_path.sh + ``` + +2. If you copied the `hawq-krb5.keytab` file, verify the ownership and mode of this file: + + ``` shell + gpadmin@master$ chown gpadmin:gpadmin /home/gpadmin/hawq-krb5.keytab + gpadmin@master$ chmod 400 /home/gpadmin/hawq-krb5.keytab + ``` + + The HAWQ server keytab file must be readable (and preferably only readable) by the HAWQ `gpadmin` administrative account. + +3. Add a `pg_hba.conf` entry that mandates Kerberos authentication for HAWQ. The `pg_hba.conf` file resides in the directory specified by the `hawq_master_directory` server configuration parameter value. For example, add: + + ``` pre + host all all 0.0.0.0/0 gss include_realm=0 krb_realm=REALM.DOMAIN + ``` + + This `pg_hba.conf` entry specifies that any remote access (i.e. from any user on any remote host) to HAWQ must be authenticated through the Kerberos realm named `REALM.DOMAIN`. + + **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. --- End diff -- "Update **the** HAWQ configuration" ---