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<[email protected]> 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/[email protected] -mapuser afs -pass * -crypto
DES-CBC-MD5 -out afs-keytab
4. Imported the keytab with: asetkey add 3 /etc/afs.keytab
afs/[email protected]

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/[email protected]' 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/[email protected] 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/[email protected]
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/[email protected] 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 [email protected]
Using default cache: /tmp/krb5cc_0
Using principal: [email protected]
Password for [email protected]:
Authenticated to Kerberos v5

[root@afs-dev-03 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]

Valid starting Expires Service principal
01/05/12 12:48:35 01/05/12 22:48:37 krbtgt/[email protected]
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/[email protected]
Kerberos error code returned by get_cred : -1765328370

That is:
#define KRB5KDC_ERR_ETYPE_NOSUPP                 (-1765328370L)

Look at the AD account for the afs/[email protected] 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
[email protected]
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 [email protected]:
[root@afs-dev-03 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]

Valid starting Expires Service principal
01/05/12 15:28:51 01/06/12 01:28:54 krbtgt/[email protected]
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/[email protected]
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
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info



--

 Douglas E. Engert  <[email protected]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to