[OpenAFS] MSKLOG - Acquiring AFS tokens on Windows using Microsoft
Security
Douglas E. Engert
deengert@anl.gov
Thu, 22 Jan 2004 18:41:53 -0600
Chris McClimans wrote:
>
> On Jan 22, 2004, at 4:26 PM, Douglas E. Engert wrote:
> > Yes it should work. You will want to have different key version nombers
> > for the afs/cs.ttu.edu@CS.TTU.EDU and afs/cs.ttu.edu@TTU.EDU as the K5
> > ticket created by each will be encryt in different keys. By the time
> > AFS look these up in the /usr/afs/etc/KeyFile it only has the knvo,
> > and does not know what principal was actually used.
>
> MS keytabs apparently always use kvno 0, and MIT starts with 1, so we
> should be safe.
The W2K always uses 0. Windows 2003 AD will use a kvno.
>
> > But the client principal is user@TTU,EDU,and may then appear to
> > AFS as a foreign user.
>
> I'm currently using gssklog[d] which works with manually entered MIT
> credentials. ms2mit and gssklog however fail.
Try "gssklog -ms" This will tell it to try the SSPI before trying
a gssapi32.dll. Can you send any output of a failure?
>
> > Our situation is a little differnet, in the users are in a ANL.GOV
> > (a MS AD realm) and our AFS cell is also named anl.gov.
> >
> > Micrsoft is still working on the NO-PAC hotfix, which is really needed
> > to get this to work with AD.
>
> I thought that getting rid of the cross-realm trust might clear up a
> few issues for us,
Yes it might. Note that the gssklog can may user@realm to user@cell
where realm != cell because the gssklogd can rebuilda ticket. The msklog
can not do this as there is no translation service.
but using an MS AD for the afs key is looking like
> it may be unusable for now.
Especially if the realm != cell. You then get into AFS cross cell
issues.
>
> >
> >
> >> -chris
> >>
> >> On Jan 8, 2004, at 2:11 PM, Douglas E. Engert wrote:
> >>
> >>>
> >>> Acquiring AFS tokens on Windows using Microsoft Security
> >>> I would like to submit to the OpenAFS community a simplified
> >>> method of obtaining AFS tokens on Windows using the built in
> >>> Microsoft security.
> >>>
> >>> The readme is attached and at:
> >>> ftp://achilles.ctd.anl.gov/pub/DEE/README.MSKLOG
> >>> The source is at:
> >>> ftp://achilles.ctd.anl.gov/pub/DEE/msklog-0.1.tar
> >>>
> >>> There are many sites that have run AFS on Windows and would like to
> >>> use AD authentication for AFS but don't want to have to run any
> >>> additional Kerberos set of tools. I know there is a lot of work going
> >>> on improving the MIT KfW packages, but in many situations this may be
> >>> more then a user or site wants to run. Some site may be using Hiemdal
> >>> or other Kerberos on Windows and don't want to switch.
> >>>
> >>> Msklog does not use any of these Kerberos packages, but uses the SSPI
> >>> and LSA code of W2K and XP which allow the msklog program to get a
> >>> Kerberos V5 ticket without having any additional Kerberos code on
> >>> the Windows machine.
> >>>
> >>> I am sending this note today, as Microsoft is close to releasing
> >>> a Hotfix for AD which will allow for much smaller tickets to be
> >>> produced, which has been a problem in the past with AFS on all
> >>> platforms.
> >>> The msklog can take advantage of this Hotfix when it becomes
> >>> available
> >>> but
> >>> can also be used today if built with the -DNO_MS_PAC option.
> >>>
> >>> I would like to see the mslog_ms.c added to OpenAFS and callable
> >>> from afscreds.exe. I am willing to do this if there is interest.
> >>>
> >>>
> >>> --------------------README------------------------
> >>>
> >>> MSKLOG - Get an AFS Token on Windows OpenAFS Client - release 0.1
> >>>
> >>>
> >>> INTRODUCTION
> >>>
> >>> AFS has evolved over the years, and recent capabilities have been
> >>> added to OpenAFS to allow it to use Kerberos V5 tickets in the AFS
> >>> token.
> >>> The MSKLOG program takes advantage of this, and is designed to use
> >>> as much of the Microsoft built in Kerberos code as possible. When
> >>> run on a machine as part of a domain the User's login credentials can
> >>> be used to obtain the AFS token.
> >>>
> >>> Unlike aklog or gssklog, no additional Kerberos libraries are needed
> >>> on the client, and no additional daemons like krb524d or gssklogd are
> >>> needed.
> >>>
> >>> The program relies only on the Microsoft DLLs and OpenAFS libraries.
> >>> No changes are needed to the AFS servers. (The servers need to be at
> >>> 1.2.8
> >>> at least.) So the program can easily be used in a Microsoft only
> >>> environment,
> >>> as well as a mixed environment.
> >>>
> >>> Current assumptions are that the AFS user name matches the Kerberos
> >>> principal, and the cell name matches the Kerberos Realm name.
> >>>
> >>> GETTING AN AFS TOKEN
> >>>
> >>> Msklog can be used in two modes. If you have use the integrated
> >>> login,
> >>> to login to the workstation, you can just run msklog, and it will use
> >>> your login credentials.
> >>>
> >>> If you did not login, you can use the msklog -principal and -password
> >>> options. See: msklog -help for the options.
> >>>
> >>>
> >>> BUILDING
> >>>
> >>> Unzip, and edit the msklog.mak to change the locations of some
> >>> directories.
> >>>
> >>> SRC_D - source (default .)
> >>> BIN_D - output file of msklog.exe
> >>> OBJ_D - output object files
> >>>
> >>> MSSDK_INC_D - Microsoft SDK include
> >>> AFS_INC_D - AFS includes
> >>> AFS_LIB_D - AFS libs
> >>> FIX_KVNO_INC_D - the AFS src\rxkad (See Below)
> >>>
> >>> Then do:
> >>>
> >>> nmake -f msklog.mak
> >>>
> >>> DEBUG NOTE
> >>>
> >>> As a testing and debugging aid, the code can be compiled with a
> >>> -DFIX_KVNO
> >>> to allow the -fixkvno n option to be used to set the key version
> >>> number.
> >>> I needed this for testing, as the OpenAFS-1.2.8 would not accept a
> >>> ticket with
> >>> default/missing kvno=0, and I had set the kvno to a different number,
> >>> but the
> >>> Microsoft KDC always returns kvno=0.
> >>>
> >>>
> >>> HOTFIX FOR DOMAIN CONTROLLER
> >>>
> >>> Microsoft is working on hotfix xxxxxxxx for the Windows Domain
> >>> controllers
> >>> to allow tickets to be issued without a PAC. This greatly reduces
> >>> the
> >>> size of the ticket, so it can be used by AFS. (AFS does not use the
> >>> PAC information anyway.)
> >>>
> >>> See: http://......
> >>>
> >>> Until this hotfix is available, msklog can be used without this
> >>> hotfix, if
> >>> it is compiled with the -DNO_MS_PAC option. But this uses an MS only
> >>> feature
> >>> and will not work against an MIT KDC.
> >>>
> >>> USING MSKLOG with an MIT KDC
> >>>
> >>> See
> >>> http://www.microsoft.com/windows2000/techinfo/planning/security/
> >>> kerbsteps.asp
> >>> Section: "Using an MIT KDC with a Standalone Windows 2000
> >>> Workstation"
> >>>
> >>> You will need to run the ktsetup command to define the Realm and
> >>> location of
> >>> the KDCs at least. If you want to use the integrated login, you will
> >>> need to
> >>> follow the other steps as well.
> >>>
> >>> SETTING UP THE KEYS
> >>>
> >>> The Kerberos KDC will need a principal, key and kvno for "afs/<cell>"
> >>> and the AFS servers will need this key and kvno entered into the
> >>> /usr/afs/etc/KeyFile
> >>>
> >>> I will only describe adding a key when using the Windows Domain
> >>> controller as the KDC. Similar command can be used with MIT based
> >>> KDC.
> >>>
> >>> The Kerberos realm name is the same as the Windows Domain name.
> >>>
> >>> The domain admin would use the Active Directory Management tools to
> >>> create
> >>> a user account for the AFS service. Then would use the ktpass tool to
> >>> set an identity mapping to afs/<cell> and to set the key.
> >>>
> >>> See:
> >>> http://www.microsoft.com/windows2000/techinfo/planning/security/
> >>> kerbsteps.asp
> >>> Section "Support for Kerberos Services"
> >>> "To create a service instance account in the Active Directory"
> >>>
> >>> This will create a user account and service principal and enter a key
> >>> based on the password provided into the Windows Domain.
> >>>
> >>> To add a matching key to the AFS KeyFile, the OpenAFS "bos_util
> >>> adddes"
> >>> command can be used. There may be other ways to add this key, but I
> >>> will describe one.
> >>>
> >>> There are some restrictions:
> >>>
> >>> o Microsoft always wants to use a key version number of 0.
> >>>
> >>> o You must use a password to generate the key. But you can view the
> >>> keys generated by the ktpass and the bos_util adddes command to
> >>> verify that that they match.
> >>>
> >>> o Since ktpass is using a salt with the password, and adddes is not,
> >>> you will need to use <password> with ktpass and
> >>> <password><realm>afs<cell> with the adddes
> >>>
> >>> For example, the cell is named anl.gov and the W2K Domain is ANL.GOV
> >>> and we will use a password of @#wsRbv3 as an example.
> >>>
> >>> On Windows:
> >>> Create the account serviceAFS
> >>> Set the xxxxxxxxx flag (See Hotfix comments above)
> >>> then run:
> >>> ktpass -princ afs/anl.gov@ANL.GOV -mapuser serviceAFS -pass
> >>> "@#wsRbv3"
> >>>
> >>> This will list key in hex. Remember this hex value and the
> >>> password
> >>> used.
> >>>
> >>> On AFS:
> >>> /usr/afs/bin/bos_util adddes 0
> >>> Then when prompted for a password enter:
> >>> @#wsRbv3ANL.GOVafsanl.gov
> >>>
> >>> You can verify the keys with the unix "od -x /usr/afs/KeyFile"
> >>> command. You should see the same key in hex in the file.
> >>>
> >>>
> >>> COMMENTS
> >>>
> >>> This is the second release, and I am looking for comments. If the
> >>> program
> >>> of the main function is useful, I would like to submit this to
> >>> OpenAFS.
> >>>
> >>> The program is a modified version of the cklog.c program found in
> >>> OpenAFS,
> >>> and it calls the msklog_ms.c routines. The MIT ms2mit program was
> >>> helpful
> >>> in understanding the workings of SSPI and LSA. The long term intent
> >>> is
> >>> the
> >>> msklog_ms.c routines could be called from the OpenAFS afscreds.exe
> >>> directly,
> >>> making its use transparent to the user.
> >>>
> >>> Doug Engert <deengert@anl.gov> 8/6/2003
> >>> 1/8/2004
> >>> --
> >>>
> >>> Douglas E. Engert <DEEngert@anl.gov>
> >>> Argonne National Laboratory
> >>> 9700 South Cass Avenue
> >>> Argonne, Illinois 60439
> >>> (630) 252-5444
> >>> _______________________________________________
> >>> OpenAFS-info mailing list
> >>> OpenAFS-info@openafs.org
> >>> https://lists.openafs.org/mailman/listinfo/openafs-info
> >>>
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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