You have to run netdom trust command to set up trust realm on your windows
AD after ksetup command:

netdom trust HADOOP.REALM /Domain:DOMAIN.REALM /add /realm
/passwordT:<Password>

and then ktpass command:

ktpass /MITRealmName HADOOP.REALM /TrustEncryp RC4

I think the second ksetup command you ran is not needed.

Only first one and the two above are usually sufficient.

Let me know how does it go after these 2 commands.



On Wed, Jul 25, 2012 at 9:25 AM, Ivan Frain <ivan.fr...@gmail.com> wrote:

> 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+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*
> > >>
> > >
> > >
> > >
> > > --
> > > 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
>

Reply via email to