[OpenAFS] Re: OpenAFS 1.6.0 with Microsoft Active Directory 2008 -
Questions about DES
Thu, 05 Jan 2012 15:49:32 -0500
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<firstname.lastname@example.org> 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
>>>> 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
>> 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
>> 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
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
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