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
