[OpenAFS] Re: OpenAFS 1.6.0 with Microsoft Active Directory 2008 - Questions about DES

Thu, 05 Jan 2012 15:55:54 -0600

On 1/5/2012 2:49 PM, Jeff White wrote:
> On 01/05/2012 02:27 PM, Douglas E. Engert wrote:
>> Another tool that could help is Wireshark to get network traces.
>> It does a very nice job of formatting the Kerberos packets, and can
>> show problems with KDC, principal, enc-type, kvno and cross realm issues.
>>
>> One other long shot to look at, is the realm of the AFS server.
>>
>> Jeff Altman said in 2007:
>> > Where you will experience great pain is if the realm derived
>> > from the name of the db servers does not match the authentication
>> > realm of the cell. The heuristic used by aklog to obtain the
>> > correct service ticket is to perform a domain to realm mapping
>> > on the hostname of the first db server. This is either derived
>> > from the hostname itself or by looking at the domain_realm
>> > section of the local machine's krb5.conf file.
>>
>> So it could be looking for CSSD.PITT.EDU
>>
>>
>> On 1/5/2012 12:14 PM, Jeff White wrote:
>>> On 01/05/2012 12:02 PM, Andrew Deason wrote:
>>>> On Thu, 05 Jan 2012 11:31:01 -0500
>>>> Jeff White<jaw171@pitt.edu> wrote:
>>>>
>>>>> 1. He created an AD domain called ad.dementia.org.
>>>>> 2. He created a user with a logon name of 'afs-adtest'.
>>>>> 3. He exported the keytab with: ktpass -princ
>>>>> afs/adtest.dementia.org@AD.DEMENTIA.ORG -mapuser afs -pass * -crypto
>>>>> DES-CBC-MD5 -out afs-keytab
>>>>> 4. Imported the keytab with: asetkey add 3 /etc/afs.keytab
>>>>> afs/adtest.dementia.org@AD.DEMENTIA.ORG
>>>>>
>>>>> Why didn't he use the logon name afs-adtest in that ktpass command?
>>>> I don't have that presentation in front of me, but that may have just
>>>> been a mistake.
>>>>
>>>>> Where did 'afs/adtest.dementia.org@AD.DEMENTIA.ORG' come from,
>>>>> particularly the 'afs/adtest.dementia.org' part? His logon name is
>>>>> not afs and what is adtest?
>>>> I don't know the internal AD details etc, but conceptually that commands
>>>> maps the principal name afs/adtest.dementia.org@AD.DEMENTIA.ORG to the
>>>> AD user "afs" (or "afs-adtest" or whatever you call it). OpenAFS by
>>>> convention uses the principal name afs/<cell_name>@REALM for krb5. So,
>>>> adtest.dementia.org is the AFS cell name in that example.
>>>>
>>>>> $ aklog -d
>>>>> Authenticating to cell pitt.edu (server afs-dev-03.cssd.pitt.edu).
>>>>> Trying to authenticate to user's realm PITT.EDU.
>>>>> Getting tickets: afs/pitt.edu@PITT.EDU
>>>>> Kerberos error code returned by get_cred : -1765328164
>>>>> aklog: Couldn't get pitt.edu AFS tickets:
>>>>> aklog: unknown RPC error (-1765328164) while getting AFS tickets
>>>> Well, you're getting a different error this time, so that's something.
>>>> What krb5 implementation are you running on that machine? I think that
>>>> error is KRB5_REALM_CANT_RESOLVE... is PITT.EDU in krb5.conf, or in dns
>>>> or what? Anything odd with that configuration?
>>>>
>>> Jeffrey Altman:
>>> A GPO was created to allow DES in Kerberos and linked to the Domain Controllers container.
>>>
>>> Andrew Deason:
>>> Bah, there was a DNS problem. I fixed that and I'm back to the first error. I made sure to use the principal afs/pitt.edu@PITT.EDU for the principal in the keytab which should be correct (user is afs,
>>> cell is pitt.edu, realm is PITT.EDU). This is on RHEL 6.1 x64 and should be using MIT's Kerberos implementation for the client as provided by RedHat.
>>>
>>> [root@afs-dev-03 ~]# rpm -qa | grep krb
>>> krb5-devel-1.9-22.el6_2.1.x86_64
>>> krb5-libs-1.9-22.el6_2.1.x86_64
>>> krb5-workstation-1.9-22.el6_2.1.x86_64
>>> openafs-krb5-1.6.0-1.el6.x86_64
>>> pam_krb5-2.3.11-6.el6.x86_64
>>>
>>> Douglas Engert:
>>> Yes, I can get a ticket.
>>>
>>> [root@afs-dev-03 ~]# kinit -V jaw171@PITT.EDU
>>> Using default cache: /tmp/krb5cc_0
>>> Using principal: jaw171@PITT.EDU
>>> Password for jaw171@PITT.EDU:
>>> Authenticated to Kerberos v5
>>>
>>> [root@afs-dev-03 ~]# klist
>>> Ticket cache: FILE:/tmp/krb5cc_0
>>> Default principal: jaw171@PITT.EDU
>>>
>>> Valid starting Expires Service principal
>>> 01/05/12 12:48:35 01/05/12 22:48:37 krbtgt/PITT.EDU@PITT.EDU
>>> renew until 01/12/12 12:48:35
>>>
>>> [root@afs-dev-03 ~]# aklog -d
>>> Authenticating to cell pitt.edu (server afs-dev-03.cssd.pitt.edu).
>>> Trying to authenticate to user's realm PITT.EDU.
>>> Getting tickets: afs/pitt.edu@PITT.EDU
>>> Kerberos error code returned by get_cred : -1765328370

That is:
#define KRB5KDC_ERR_ETYPE_NOSUPP                 (-1765328370L)

Look at the AD account for the afs/pit.edu@PIT.EDU principal.

W2008 introduces the attribute msDS-supportedEncryptionTypes
  http://msdn.microsoft.com/en-us/library/cc223853(v=prot.10).aspx
to give more flexibility is setting the enc-types for a principal.

It could be that this is allowing for AES, and RC4 but not DES
because ktpass set this attribute, or the ktpass did not set the
ADS_UF_DES_DES_ONLY bit in the userAccountControl attribute is
not set.

  http://msdn.microsoft.com/en-us/library/windows/desktop/ms680832(v=vs.85).aspx

Try setting msDS-supportedEncryptionTypes to 2.
i.e. DES_CBC_MD5

On our 2008 DCs, the afs account does not have the
msDS-supportedEncryptionTypes set at all, but the
ADS_UF_USE_DES_KEY_ONLY is set in the userAccountControl
and may have been grandfathered in as our AFS account was created
when we had W2000 DCs (We also use msktutil to add service accounts
and create keytabs rather then ktpass.)

>>> aklog: Couldn't get pitt.edu AFS tickets:
>>> aklog: unknown RPC error (-1765328370) while getting AFS tickets
>>>
>>> Yea, I shouldn't be getting user tickets/token as root but whatever, this is just a test box and a test principal.
>>>
>>> I was sent the URL http://openafs-wiki.stanford.edu/AFSLore/win2008r2adaskdc/ by Lars Schimmer but making the registry change it said was needed made it so I can no longer log into my DC at all, even
>>> on the console. Time to wipe out the DC and start everything over again.
>>> _______________________________________________
>>> OpenAFS-info mailing list
>>> OpenAFS-info@openafs.org
>>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>>
>>>
> aklog says it is using the realm PITT.EDU, not CSSD. PITT. EDU so that's not the issue. I tried several more time to export the key from AD and import it into AFS but I get the same error every time I
> try to aklog.
>
> The only other thing I have found talks about creating the key KdcUseRequestedEtypesForTickets in HKLM\SYSTEM\CurrentControlSet\services\kdc and setting the value to 1. When I do this I can no longer
> log into the DC at all, not even on the console. I don't have a clue why this is.
>
> I did notice that in a packet capture I see the server name field has the principal slash the cell name, but I don't know if that is normal. It obviously knows who the server is because I can see the
> traffic going between the KDC and AFS server.
>
> [root@afs-dev-03 ~]# kdestroy
> [root@afs-dev-03 ~]# klist
> klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
> [root@afs-dev-03 ~]# kinit jaw171
> Password for jaw171@PITT.EDU:
> [root@afs-dev-03 ~]# klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: jaw171@PITT.EDU
>
> Valid starting Expires Service principal
> 01/05/12 15:28:51 01/06/12 01:28:54 krbtgt/PITT.EDU@PITT.EDU
> renew until 01/12/12 15:28:51
> [root@afs-dev-03 ~]# aklog -d
> Authenticating to cell pitt.edu (server afs-dev-03.cssd.pitt.edu).
> Trying to authenticate to user's realm PITT.EDU.
> Getting tickets: afs/pitt.edu@PITT.EDU
> Kerberos error code returned by get_cred : -1765328370
> aklog: Couldn't get pitt.edu AFS tickets:
> aklog: unknown RPC error (-1765328370) while getting AFS tickets
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
>

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444