John W. Sopko Jr. wrote:
I really did not think it would be this complex to
generate a Windows service principal and corresponding
/usr/afs/etc/KeyFile.
No it should not be, but then again Microsoft did some
things early on that did not follow the Kerberos
conversions, including not using kvnos. We are living with
thuse early decisions.
think the best route is to
try windows ktpass again. The thing I do not understand
is; you create a Windows domain account and then use
setspn to add the afs/cs.unc.edu service principal.
(Or I found the service principal gets added if you
use the "-mapuser" option to ktpass). Then if I use
ktpass to set the password, kvno and generate a
keytab, neither the password or the kvno change for
afs/cs.unc.edu service principal. I thought ktpass was
supposed to do what MIT "kadmin ktadd" does, change the
principals password and dump the key to a keytab so
they matched. Maybe this is the problem with the "bad"
ktpass version.
You have to have admin privilages in AD to change the
enties, although a user can change thier own password,
but I don't thin ktpass is doing that.
At this point I am confused with ktpass, I read the microsoft
docs:
http://technet2.microsoft.com/WindowsServer/en/library/a412a943-4567-4674-9015-fe1b7bf0228c1033.mspx?mfr=true
The only comment on this is the statememt:
"You cannot map multiple service instances to the same user
account."
You can have multiple SPNs, but ktpass appearently can not
handle it.
For example I re-created my domain account as AFS.CS.UNC.EDU
and the ran ktpass like this:
ktpass -out keytab -princ afs/[EMAIL PROTECTED] -kvno
7 -crypto DES-CBC-CRC -DesOnly -pass * -mapuser AFS.CS.UNC.EDU
the -mapuser option adds the afs/cs.unc.edu service to the
user account.
You can verify this with setspn -L AFS.CS.UNC.EDU, I did not
need to run the Windows "setspn -A afs/cs.unc.edu
AFS.CS.UNC.EDU"
command, (FYI).
The kvno will always default to 1 if you do not specify it.
But after I run this I run "kvno afs/cs.unc.edu @MSE.UNCCS.TEST"
and the kvno is not 7. The kvno only increments if you change
the password for the domain user, in this case AFS.CS.UNC.EDU.
Yes, one password per account, and the kvno is stored in the
account
as msDS-KeyVersionNumber with ( mmc and the ADSI plugin you
can look
at the AD entries.)
At this point I am not sure if there is one password for
the user accunt and one for the service principal or if they
are one and the same.
They are the same.
I do not know where to get a "good" version of ktpass. I will
ask our Windows guy, I searched Microsoft and they only have
the SP1 version.
Asw I said there is the other way, to avoid ktpass and asetkey.
Another way is to create the AD account, and add the SPN,
and set the password to something known. The salt can then
be determened from the UPN,
I can try this for fun but we really need simpler solution.
msktutil we used this for unix hosts too.
What do I run to determine this?
You AD dmin can look at te entry. You as a user can run
on the mmc command, then use the ADSI Edit plugin to look at your
domain.
of to *really* be sure, do a network
trace of the KRB5_ERROR packet returned when you do a
kinit afs/[EMAIL PROTECTED] Then drill down in the e-data
till you find the salt for DES.
Here it is, don't know how to decode the salt info, I got
this using the command:
/usr/sbin/tshark -V host eagle or host madison-cs and port 88
host eagle is the afs server, host madison-cs the Windows AD
server.
e-data
padata: PA-ENCTYPE-INFO
Type: PA-ENCTYPE-INFO (11)
Value:
304E3025A003020103A11E041C4D53452E554E4343532E54...
des-cbc-md5 des-cbc-crc
Encryption type: des-cbc-md5 (3)
Salt:
4D53452E554E4343532E544553544146532E43532E554E43...
OK this is the salt! Its in asci, so:
4D 53 45 2E 55 4E 43 43 53 2E 54 45 53 54 41 46 53 2E 43 53
2E 55 4E 43...
M S E . U N C C S . T E S T A F S . C S
. U N C ...
So this look like it is taking the realm(MSE.UNCCS.TEST) and the
SamAccountName AFS.CS.UNC... and using these as the salt. (I
assume the ...
would be .EDU from uyourother messages.
Encryption type: des-cbc-crc (1)
Salt:
4D53452E554E4343532E544553544146532E43532E554E43...
Then forget about asetkey, and use the AFS "bos_util adddes"
command instead, to add the key to the keytab. Since bos_util
was designed for Krb4 where no salt was used for DES we can in
effect concatenate the password and the salt used in AD and use
this as the password to bos_util adddes!
Best to test this first on a non-server machine as bos_util
wants to update the /usr/afs/etc/KeyTab file.
If you can give me the password string to give
bos_util I will try it, that is I will enter my known password
I just need the other string/salt info.
From the above message it looks like you would concatenate to
the
known password MSE.UNCCS.TESTAFS.CS.UNC.EDU
I am not sure what the kvno is, but you can find that with the
mmc ADSI Edit and look in the entry for the msDS-KeyVersionNumber
Make sure the knvo does not match any existing keys in the
KeyTable file.
If so change the passwrod in AD again, and it will increment the
kvno.
Thanks for all the input.
John W. Sopko Jr. wrote:
Getting close, I can feel it:
Verify Windows service account:
-------------------------------
C:\temp>setspn -L afs
Registered ServicePrincipalNames for CN=afs service
principal,CN=Users,DC=mse,DC
=unccs,DC=test:
afs/cs.unc.edu
Change the Windows afs domain user password to a known
password, this
increments the kvno from 4 to 5. This is verified below.
Create /usr/afs/etc/KeyFile with kvno 5:
----------------------------------------
ktutil: add_entry -password -p afs/cs.unc.edu -k 5 -e
des-cbc-crc
Password for afs/[EMAIL PROTECTED]:
ktutil: wkt keytab.ktutil
eagle/root [/usr/afs/etc] # asetkey add 5 keytab.ktutil
afs/[EMAIL PROTECTED]
eagle/root [/usr/afs/etc] # bos listkeys eagle -localauth
key 5 has cksum 509175897
Keys last changed on Wed Jan 10 08:53:50 2007.
All done.
Get afs token and try afs access:
---------------------------------
[EMAIL PROTECTED] /]$ klist
klist: No credentials cache found (ticket cache
FILE:/tmp/krb5cc_3903_015mRF)
Kerberos 4 ticket cache: /tmp/tkt3903
klist: You have no tickets cached
[EMAIL PROTECTED] /]$ kinit
Password for [EMAIL PROTECTED]:
[EMAIL PROTECTED] /]$ klist
Ticket cache: FILE:/tmp/krb5cc_3903_015mRF
Default principal: [EMAIL PROTECTED]
Valid starting Expires Service principal
01/10/07 08:56:02 01/10/07 18:56:06
krbtgt/[EMAIL PROTECTED]
renew until 01/17/07 08:56:02
Kerberos 4 ticket cache: /tmp/tkt3903
klist: You have no tickets cached
[EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED]
afs/[EMAIL PROTECTED]: kvno = 5
[EMAIL PROTECTED] /]$ klist
Ticket cache: FILE:/tmp/krb5cc_3903_015mRF
Default principal: [EMAIL PROTECTED]
Valid starting Expires Service principal
01/10/07 08:56:02 01/10/07 18:56:06
krbtgt/[EMAIL PROTECTED]
renew until 01/17/07 08:56:02
01/10/07 08:56:28 01/10/07 18:56:06
afs/[EMAIL PROTECTED]
renew until 01/17/07 08:56:02
Kerberos 4 ticket cache: /tmp/tkt3903
klist: You have no tickets cached
[EMAIL PROTECTED] /]$ aklog -d
Authenticating to cell cs.unc.edu (server eagle.cs.unc.edu).
We've deduced that we need to authenticate to realm
MSE.UNCCS.TEST.
Getting tickets: afs/[EMAIL PROTECTED]
Using Kerberos V5 ticket natively
About to resolve name sopko to id in cell cs.unc.edu.
Id 3903
Set username to AFS ID 3903
Setting tokens. AFS ID 3903 / @ MSE.UNCCS.TEST
[EMAIL PROTECTED] /]$ tokens
Tokens held by the Cache Manager:
User's (AFS ID 3903) tokens for [EMAIL PROTECTED] [Expires Jan
10 18:56]
--End of list--
[EMAIL PROTECTED] /]$ ls /afs/cs.unc.edu/home
ls: /afs/cs.unc.edu/home: Permission denied
Jan 10 08:56:39 eagle kernel: afs: Tokens for user of AFS
id 3903 for cell cs.unc.edu are discarded (rxkad
error=19270407)
eagle/root [/usr/afs/etc] # translate_et 19270407
19270407 (rxk).7 = security object was passed a bad ticket
Jeffrey Altman wrote:
Even assuming you wanted to kinit to your service principal
you would have to so with the correct principal name
afs/[EMAIL PROTECTED] != afs/[EMAIL PROTECTED]
Your default realm name is CSX.UNC.EDU, not MSE.UNCCS.TEST.
However, you don't want to be able to kinit to that service
principal. What you want is to be able to obtain a service
ticket for it using a client principal
kvno afs/[EMAIL PROTECTED]
obtains a service ticket for the specified principal name.
Assuming the kvno is still 4 after you set the service
principal
name. You should try to authenticate to your AFS servers
again.
John W. Sopko Jr. wrote:
Jeffrey Altman wrote:
[EMAIL PROTECTED] != afs/[EMAIL PROTECTED]
choose one and stick with it.
I am confused with Windows principals:
[EMAIL PROTECTED] /]$ kinit afs/[EMAIL PROTECTED]
kinit(v5): Client not found in Kerberos database while
getting initial
credentials
That is why I did:
[EMAIL PROTECTED] /]$ kinit afs
Password for [EMAIL PROTECTED]:
So I have a Windows "afs" user account that I ran:
setspn -A afs/cs.unc.edu afs
To Add/Associate a service principal to the Windows login
name.
But I cannot kinit to afs/cs.unc.edu like I can
under MIT KRB5, (my CSX.UNC.EDU linux server):
|[EMAIL PROTECTED]:19% kinit afs/cs.unc.edu
Password for afs/[EMAIL PROTECTED]:
John W. Sopko Jr. wrote:
Jeffrey Altman wrote:
John W. Sopko Jr. wrote:
In C:\Program Files\Support Tools\ktpass
right click properties "version tab" shows 5.2.3790.1830
So use ktutil on the linux openafs server, setting the
password the same as the afs users Windows password:
eagle/root [/usr/afs/etc] # ktutil
ktutil: add_entry -password -p
afs/[EMAIL PROTECTED] -k 1 -e
des-cbc-crc
Where did you get the key version number of 1 from?
When I ran the "bad" ktpass command on windows it
always generates
kvno 1
by default. The ktpass /? (help) says:
kvno : Override Key Version Number
Default: query DC for kvno. Use /kvno 1 for
Win2K compat.
Since this Windows 2003 server is running in 2000 mixed
mode I thought
it forced/kept the kvno at 1 for w2k compatability.
Below is the
output of
the ktpass, no matter how many times I run it it keeps
the "vno"
at 1. I check the keytab.mse file with ktutil and it is
at 1.
But you are right I do not know what is in the server.
I did not
think hard enough about this.
The key version number must match the number that is
actually
issued by the KDC. You can identify the version
number using
the MIT Kerberos utility
kvno <principal>
I tried this to get the kvno:
eagle/root [/usr/afs/etc] # kinit afs
Password for [EMAIL PROTECTED]:
eagle/root [/usr/afs/etc] # kvno afs
[EMAIL PROTECTED]: kvno = 4
I then ran:
ktutil> add_entry -password -p
afs/[EMAIL PROTECTED] -k 4 -e
des-cbc-crc
ktutil> write_kt keytab.ktutil_generated
/usr/sbin/asetkey add 4 keytab.ktutil_generated
afs/cs.unc.edu
/etc/init.d/openafs-server restart
I now get the same error as Eric had:
Jan 9 17:14:27 eagle kernel: afs: Tokens for user of
AFS id 3903 for
cell cs.unc.edu are discarded (rxkad error=19270407)
Do I need to map an account like Eric did with the
"mapuser" option
to ktpass?
The key version number must match the number that is
actually
issued by the KDC. You can identify the version
number using
the MIT Kerberos utility
kvno <principal>
cell cs.unc.edu are discarded (rxkad error=19270408)
The OpenAFS translate_et <error_code> command will
tell you this
is because
19270408 = ticket contained unknown key version number
Windows Event Viewer, System log shows this, sometimes:
While processing a TGS request for the target server
afs/cs.unc.edu, the
account [EMAIL PROTECTED] did not have a suitable
key for
generating
a Kerberos ticket (the missing key has an ID of 8).
The requested
etypes
were 2. The accounts available etypes were 3 1.
What in the world is requesting a ticket with
DES-CBC-MD4 ?
AM I CRAZY?
-----------
Once I get Windows AD working can I run both our
current kaserver and
Windows AD authentication against our production
cs.unc.edu openafs
cell
at the same time? If I can generate afs/cs.unc.edu
service pincipals
with the same password on the kaserver and the AD
server will this
work?
This may be a good migration path for us. We
currently have 2 password
databases, kaserver and Windows AD. When we create
accounts we use the
same user login name for both wndows and linux. Most
users keep their
passwords the same so logging into Windows gives them
an afs token.
Even if they don't we just tell them to use their
Windows password
as we migrate machine configurations.
This way we can migrate machines to authenticate to
"Windows AD only"
over a short period of time and start testing real
live systems.
First I have to get Windows AD afs service pricnipal
working.
AFS only stores DES keys by key version number.
Ensure that your
kaserver key and your AD key have different version
numbers and
you will be just fine.
Jeffrey Altman
