Hi Ivan, Did you solve your problem ? I've the same issue. I can run Hadoop commands after a kinit with a "local principal" (@CLUSTER.HADOOP.DEV) but it doesn't work with AD user (@AD.HADOOP.DEV).
Could you help me ? Thanks Guillaume Polaert | Cyrès Conseil -----Message d'origine----- De : Ivan Frain [mailto:ivan.fr...@gmail.com] Envoyé : mercredi 25 juillet 2012 18:25 À : common-user@hadoop.apache.org Objet : Re: Problem setting up Hadoop security with active directory using one-way cross-realm configuration In AD: - I have created a one way incoming trust using the GUI (I guess it is the equivalent of the "netdom trust"). - ksetup /addkdc HADOOP.REALM mitkdc.hadoop.realm - ksetup /SetEncTypeAttr HADOOP.REALM RC4-HMAC-MD5 What do you think ? 2012/7/25 Mapred Learn <mapred.le...@gmail.com> > Krb5 looks good. > Can you also share commands you ran in your Windows AD ? > > Sent from my iPhone > > On Jul 25, 2012, at 8:27 AM, Ivan Frain <ivan.fr...@gmail.com> wrote: > > > Thanks for your answer. > > > > I think I already did what you propose. Some comments in the remaining. > > > > > > 2012/7/25 Mapred Learn <mapred.le...@gmail.com> > > > >> 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. > >> > > > > I set up a KDC on the linux machine and configure a one-way > > incoming > trust > > on AD to be trusted by the local KDC. I set the enc type as well on > > AD. I also create the appropriate remote TGT on the local KDC: > > krbtgt/HADOOP.REALM@DOMAIN.REALM with the same encoding type > > > > > >> > >> After this you need to modify your /etc/krb5.conf to include this > >> local realm as trust realm to your AD realm. > >> > > > > Here is the /etc/krb5.conf located in my local kdc on > > mitkdc.hadoop.realm machine. May be something is wrong there: > > > > [libdefaults] > > default_realm = HADOOP.REALM > > default_tkt_enctypes = arcfour-hmac-md5 default_tgs_enctypes = > > arcfour-hmac-md5 > > > > [realms] > > HADOOP.REALM = { > > kdc = mitkdc.hadoop.realm > > admin_server = mitkdc.hadoop.realm default_domain = > > hadoop.realm > > } > > DOMAIN.REALM = { > > kdc = ad.domain.realm > > admin_server = ad.domain.realm > > default_domain = domain.realm > > } > > > > [domain_realm] > > .hadoop.realm = HADOOP.REALM > > hadoop.realm = HADOOP.REALM > > .domain.realm = DOMAIN.REALM > > domain.realm = DOMAIN.REALM > > > > > > > >> > >> And then you should be all set. > >> > >> > > I was hoping so but it is not ... yet ... the case > > > > > > > >> Sent from my iPhone > >> > >> On Jul 25, 2012, at 2:29 AM, Ivan Frain <ivan.fr...@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+w > ith+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* > >> > > > > > > > > -- > > Ivan Frain > > 11, route de Grenade > > 31530 Saint-Paul-sur-Save > > mobile: +33 (0)6 52 52 47 07 > -- Ivan Frain 11, route de Grenade 31530 Saint-Paul-sur-Save mobile: +33 (0)6 52 52 47 07
