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
--
John W. Sopko Jr. University of North Carolina
email: sopko AT cs.unc.edu Computer Science Dept., CB 3175
Phone: 919-962-1844 Sitterson Hall; Room 044
Fax: 919-962-1799 Chapel Hill, NC 27599-3175
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
