hadoop-common-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mapred Learn <mapred.le...@gmail.com>
Subject Re: Problem setting up Hadoop security with active directory using one-way cross-realm configuration
Date Wed, 25 Jul 2012 14:59:54 GMT
You need to set up a local realm on your KDC ( linux) and run commands on windows AD to add
this realm as a trust realm on your AD realm.

After this you need to modify your /etc/krb5.conf to include this local realm as trust realm
to your AD realm.

And then you should be all set.

Sent from my iPhone

On Jul 25, 2012, at 2:29 AM, Ivan Frain <ivan.frain@gmail.com> wrote:

> *Hi all,*
> *
> *
> *I am trying to setup a one-way cross realm trust between a MIT KDC and an
> active directory server and up to now I did not success.*
> *I hope someone in this list will be able to help me.*
> *
> *
> *My config is as follows:*
> *  - hadoop version: 0.23.1 with security enable (kerberos).*
> *  - hadoop realm (mitkdc): HADOOP.REALM*
> *  - 1 linux node (mitkdc.hadoop.realm - 192.168.198.254) running : hdfs
> namenode, hdfs datanode, mit kdc*
> *  - 1 windows node (ad.domain.realm - 192.168.198.253) running: active
> directory 2003*
> *  - AD realm: DOMAIN.REALM*
> *
> *
> *Everything works well with kerberos enabled if I only use the linux
> machine with users having principal in the mitkdc: ivan@HADOOP.REALM*
> *
> *
> *What I am trying to do is to use the user database in the Active directory
> (users with principals like ivan@DOMAIN.REALM)*
> *
> *
> *To do that, I setup a one-way cross realm as explained here:
> https://ccp.cloudera.com/display/CDH4DOC/Integrating+Hadoop+Security+with+Active+Directory
> *
> *
> *
> *From the linux machine I can authenticate against an active directory user
> with the kinit command but when I perform a query using the hadoop command
> I have the following error message:*
> ---------------------
> hdfs@mitkdc:~$ kinit ivan@DOMAIN.REALM
> Password for ivan@DOMAIN.REALM:
> 
> hdfs@mitkdc:~$ klist -e
> Ticket cache: FILE:/tmp/krb5cc_10003
> Default principal: ivan@DOMAIN.REALM
> 
> Valid starting    Expires           Service principal
> 25/07/2012 11:00  25/07/2012 20:59  krbtgt/DOMAIN.REALM@DOMAIN.REALM
> renew until 26/07/2012 11:00, Etype (skey, tkt): arcfour-hmac, arcfour-hmac
> 
> hdfs@mitkdc:~$ hadoop/bin/hadoop fs -ls /user
> 12/07/25 11:00:50 ERROR security.UserGroupInformation:
> PriviledgedActionException as:ivan@DOMAIN.REALM (auth:KERBEROS)
> cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Fail to
> create credential. (63) - No service creds)]
> 12/07/25 11:00:50 INFO security.UserGroupInformation: Initiating logout for
> ivan@DOMAIN.REALM
> 12/07/25 11:00:50 INFO security.UserGroupInformation: Initiating re-login
> for ivan@DOMAIN.REALM
> 12/07/25 11:00:53 ERROR security.UserGroupInformation:
> PriviledgedActionException as:ivan@DOMAIN.REALM (auth:KERBEROS)
> cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Fail to
> create credential. (63) - No service creds)]
> 12/07/25 11:00:53 WARN security.UserGroupInformation: Not attempting to
> re-login since the last re-login was attempted less than 600 seconds before.
> 12/07/25 11:00:56 ERROR security.UserGroupInformation:
> PriviledgedActionException as:ivan@DOMAIN.REALM (auth:KERBEROS)
> cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Fail to
> create credential. (63) - No service creds)]
> 12/07/25 11:00:56 WARN security.UserGroupInformation: Not attempting to
> re-login since the last re-login was attempted less than 600 seconds before.
> 12/07/25 11:00:58 ERROR security.UserGroupInformation:
> PriviledgedActionException as:ivan@DOMAIN.REALM (auth:KERBEROS)
> cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Fail to
> create credential. (63) - No service creds)]
> 12/07/25 11:00:58 WARN security.UserGroupInformation: Not attempting to
> re-login since the last re-login was attempted less than 600 seconds before.
> 12/07/25 11:00:59 ERROR security.UserGroupInformation:
> PriviledgedActionException as:ivan@DOMAIN.REALM (auth:KERBEROS)
> cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Fail to
> create credential. (63) - No service creds)]
> 12/07/25 11:00:59 WARN security.UserGroupInformation: Not attempting to
> re-login since the last re-login was attempted less than 600 seconds before.
> 12/07/25 11:01:02 ERROR security.UserGroupInformation:
> PriviledgedActionException as:ivan@DOMAIN.REALM (auth:KERBEROS)
> cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Fail to
> create credential. (63) - No service creds)]
> 12/07/25 11:01:02 WARN ipc.Client: Couldn't setup connection for
> ivan@DOMAIN.REALM to hdfs/mitkdc.hadoop.realm@HADOOP.REALM
> 12/07/25 11:01:02 ERROR security.UserGroupInformation:
> PriviledgedActionException as:ivan@DOMAIN.REALM (auth:KERBEROS)
> cause:java.io.IOException: Couldn't setup connection for
> ivan@DOMAIN.REALMto hdfs/mitkdc.hadoop.realm@HADOOP.REALM
> ls: Failed on local exception: java.io.IOException: Couldn't setup
> connection for ivan@DOMAIN.REALM to hdfs/mitkdc.hadoop.realm@HADOOP.REALM;
> Host Details : local host is: "mitkdc.hadoop.realm/192.168.198.254";
> destination host is: ""mitkdc.hadoop.realm":8020;
> ---------------------
> 
> *On the mitkdc server log I can see something like the following meaning
> that encoded types are not supported: *
> 
> ---------------
> Jul 25 09:53:33 mitkdc.hadoop.realm krb5kdc[8630](info): TGS_REQ (5 etypes
> {3 1 23 16 17}) 192.168.198.254: PROCESS_TGS: authtime 0,  <unknown client>
> for <unknown server>, No matching key in entry having a permitted enctype
> Jul 25 09:53:36 mitkdc.hadoop.realm krb5kdc[8630](info): TGS_REQ (5 etypes
> {3 1 23 16 17}) 192.168.198.254: PROCESS_TGS: authtime 0,  <unknown client>
> for <unknown server>, No matching key in entry having a permitted enctype
> Jul 25 09:53:37 mitkdc.hadoop.realm krb5kdc[8630](info): TGS_REQ (5 etypes
> {3 1 23 16 17}) 192.168.198.254: PROCESS_TGS: authtime 0,  <unknown client>
> for <unknown server>, No matching key in entry having a permitted enctype
> Jul 25 09:53:37 mitkdc.hadoop.realm krb5kdc[8630](info): TGS_REQ (5 etypes
> {3 1 23 16 17}) 192.168.198.254: PROCESS_TGS: authtime 0,  <unknown client>
> for <unknown server>, No matching key in entry having a permitted enctype
> Jul 25 09:54:25 mitkdc.hadoop.realm krb5kdc[8630](info): TGS_REQ (5 etypes
> {3 1 23 16 17}) 192.168.198.254: PROCESS_TGS: authtime 0,  <unknown client>
> for <unknown server>, No matching key in entry having a permitted enctype
> Jul 25 09:54:30 mitkdc.hadoop.realm krb5kdc[8630](info): TGS_REQ (5 etypes
> {3 1 23 16 17}) 192.168.198.254: PROCESS_TGS: authtime 0,  <unknown client>
> for <unknown server>, No matching key in entry having a permitted enctype
> Jul 25 09:54:30 mitkdc.hadoop.realm krb5kdc[8630](info): TGS_REQ (5 etypes
> {3 1 23 16 17}) 192.168.198.254: PROCESS_TGS: authtime 0,  <unknown client>
> for <unknown server>, No matching key in entry having a permitted enctype
> Jul 25 09:54:32 mitkdc.hadoop.realm krb5kdc[8630](info): TGS_REQ (5 etypes
> {3 1 23 16 17}) 192.168.198.254: PROCESS_TGS: authtime 0,  <unknown client>
> for <unknown server>, No matching key in entry having a permitted enctype
> Jul 25 09:54:35 mitkdc.hadoop.realm krb5kdc[8630](info): TGS_REQ (5 etypes
> {3 1 23 16 17}) 192.168.198.254: PROCESS_TGS: authtime 0,  <unknown client>
> for <unknown server>, No matching key in entry having a permitted enctype
> Jul 25 09:54:38 mitkdc.hadoop.realm krb5kdc[8630](info): TGS_REQ (5 etypes
> {3 1 23 16 17}) 192.168.198.254: PROCESS_TGS: authtime 0,  <unknown client>
> for <unknown server>, No matching key in entry having a permitted enctype
> ---------------
> 
> *I captured the network packet and here are the corresponding TGS_REQ and
> TGS_REP kerberos messages, and it seems that enctype are ok, doesn't it ?*
> 
> --------------- TGS_REQ (from linux machine to windows machine)------------
> No.     Time        Source                Destination           Protocol
> Length Info
>    387 61.484270   192.168.198.254       192.168.198.253       KRB5
> 1425   TGS-REQ
> 
> Frame 387: 1425 bytes on wire (11400 bits), 1425 bytes captured (11400 bits)
> Ethernet II, Src: Vmware_2d:c2:18 (00:0c:29:2d:c2:18), Dst: Vmware_71:90:65
> (00:0c:29:71:90:65)
> Internet Protocol Version 4, Src: 192.168.198.254 (192.168.198.254), Dst:
> 192.168.198.253 (192.168.198.253)
> User Datagram Protocol, Src Port: 46893 (46893), Dst Port: kerberos (88)
> Kerberos TGS-REQ
>    Pvno: 5
>    MSG Type: TGS-REQ (12)
>    padata: PA-TGS-REQ
>    KDC_REQ_BODY
>        Padding: 0
>        KDCOptions: 00000000
>        Realm: DOMAIN.REALM
>        Server Name (Service and Instance): krbtgt/HADOOP.REALM
>            Name-type: Service and Instance (2)
>            Name: krbtgt
>            Name: HADOOP.REALM
>        till: 1970-01-01 00:00:00 (UTC)
>        Nonce: 1343206856
>        Encryption Types: des-cbc-md5 des-cbc-crc rc4-hmac des3-cbc-sha1
> aes128-cts-hmac-sha1-96
>            Encryption type: des-cbc-md5 (3)
>            Encryption type: des-cbc-crc (1)
>            Encryption type: rc4-hmac (23)
>            Encryption type: des3-cbc-sha1 (16)
>            Encryption type: aes128-cts-hmac-sha1-96 (17)
> 
> ---------------- TGS_REP (from windows machine to linux machine) -----------
> No.     Time        Source                Destination           Protocol
> Length Info
>    388 61.485538   192.168.198.253       192.168.198.254       KRB5
> 1353   TGS-REP
> 
> Frame 388: 1353 bytes on wire (10824 bits), 1353 bytes captured (10824 bits)
> Ethernet II, Src: Vmware_71:90:65 (00:0c:29:71:90:65), Dst: Vmware_2d:c2:18
> (00:0c:29:2d:c2:18)
> Internet Protocol Version 4, Src: 192.168.198.253 (192.168.198.253), Dst:
> 192.168.198.254 (192.168.198.254)
> User Datagram Protocol, Src Port: kerberos (88), Dst Port: 46893 (46893)
> Kerberos TGS-REP
>    Pvno: 5
>    MSG Type: TGS-REP (13)
>    Client Realm: DOMAIN.REALM
>    Client Name (Principal): ivan
>    Ticket
>        Tkt-vno: 5
>        Realm: DOMAIN.REALM
>        Server Name (Service and Instance): krbtgt/HADOOP.REALM
>            Name-type: Service and Instance (2)
>            Name: krbtgt
>            Name: HADOOP.REALM
>        enc-part des-cbc-md5
>            Encryption type: des-cbc-md5 (3)
>            enc-part: a12c2a02726b7e88311a68ae4d64a4e383df32f6be078604...
>    enc-part rc4-hmac
>        Encryption type: rc4-hmac (23)
>        enc-part: 3c2a75681740c9346ddd1f57a334386256c9c94705304fc7...
> ------------------------
> 
> *There is no error in the kerberos protocol so i am a little bit lost. If
> someone has successfully configured this cross-realm AD/KDC or have any
> idea about the problem above, it would be great.*
> *
> *
> *Thanks in advance.*
> *
> *
> *BR,*
> *Ivan*

Mime
View raw message