1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
|
Building & Running Kerberos 5 on Windows
----------------------------------------
Kerberos 5 builds on Windows with MSVC++ 6.0, MSVS.NET, and
MSVS.NET 2003. You will need the November 2001 platform SDK or
later; this SDK is required to define getaddrinfo. It may or
may not build with other compilers or make utilities.
These build instructions assume that you have the standalone source
distribution of Kerberos 5 rather than the MIT Kerberos for Windows
distribution (which includes a working Kerberos 4).
There are two methods for building a Windows version of Kerberos 5.
The traditional method involves starting on a Unix machine and
creating a distribution that can be built on Windows. The second
method works from the sources that come from the Unix distribution if
you have certain Unix-type utilities (see below).
IMPORTANT NOTE: By default, the sources are built with debug
information and linked against the debug version of the Microsoft C
Runtime library, which is not found on most Windows systems unless
they have development tools. To build a release version, you need to
define NODEBUG either in the environment or the nmake command-line.
To configuring the build environment execute first the compiler
batch file, vcvars32.bat or vsvars32.bat, followed by the SDK
batch file, setenv.bat. For example,
"c:\program files\microsoft visual studio .net 2003\common7\tools\vsvars32.bat"
"c:\program files\microsoft sdk\setenv.bat" /2000 /RETAIL
or
"c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat"
"c:\program files\microsoft sdk\setenv.bat" /2000 /DEBUG
DNS Support: To support DNS lookups, you will need to define
KRB5_DNS_LOOKUP, KRB5_DNS_LOOKUP_KDC, or KRB5_DNS_LOOKUP_REALMS. When
any of the KRB5_DNS_LOOKUP definitions are used, the default build will use
the WSHelper library which is part of the Kerberos for Windows (Kfw)
distribution. If you are building outside of KfW and wish to build Krb5
with DNS support, you must provide a resolver library whose include files
match the Unix resolver library. You will need to define KRB5_NO_WSHELPER,
define DNS_INC to point to the include directory for the library and DNS_LIB
to library itself. The default is not to support DNS because the build
cannot know whether there is a DNS resolver library around for it to use.
Traditional Build Method:
------------------------
On the Unix side
1) cd xxx/src # Go to where the source lives
2) make -f Makefile.in kerbsrc.zip # Do some Unix-side configuring
# ...and create kerbsrc.zip
3) <transfer kerbsrc.zip to the PC>
On the PC side
1) md \krb5 # Create dir where we'll put the tree
2) cd \krb5
3) unzip kerbsrc.zip
- or -
pkunzip -d kerbsrc.zip
4) nmake [NODEBUG=1] [DNS-options] # Build the sources
5) nmake install [NODEBUG=1] [options] # Copy headers, libs, executables
All-Windows Build Method:
------------------------
First, make sure you have sed, gawk, cat, and cp.
1) cd xxx/src # Go to where the source lives
2) nmake -f Makefile.in prep-windows # Create Makefile for Windows
3) nmake [NODEBUG=1] [DNS-options] # Build the sources
4) nmake install [NODEBUG=1] [options] # Copy headers, libs, executables
Notes on the install Target:
---------------------------
For the install target, you will need to define KRB_INSTALL_DIR to
point to the directory where the header, library, and executable files
will be installed. You can either define this in the environment or
at the nmake command-line. For example:
nmake install [NODEBUG=1] KRB_INSTALL_DIR=c:\sdk\krb5
Make sure you create the directory first. Otherwise, nmake will
complain. The files will get installed into include, lib, and bin
subdirectories. You can then copy the binaries to where ever you want
have them (probably somewhere in your path).
Running Kerberos 5 Apps:
-----------------------
Make sure you have a valid krb5.ini file. That will look just like a
Unix krb5.conf file. You can place this file in the same directory as
your krb5_32.dll or in your Windows directory. You should then be
able to run the applications that are built. Note that Kerberos 5
will not look for the krb5.ini file in your path.
krb5.ini File:
-------------
WARNING: Despite its name, this is not a Windows .ini file.
Therefore, do not try to use any .ini tools, including the Windows API
or any installer tools to manipulate this file. Its format is subtly
different from Windows .ini files!
Controlling the Kerberos 5 Run-Time Environment:
-----------------------------------------------
The Kerberos 5 configuration file and credentials cache can be
controlled with environment variables and registry settings. The
environment variable for a particular setting always takes precedence.
Next in precedence comes the setting in the registry under
HKEY_CURRENT_USER\Software\MIT\Kerberos5. Then comes the registry
setting under HKEY_LOCAL_MACHINE\Software\MIT\Kerberos5. If none of
those are found, a default value is used.
Configuration File:
- Environment: KRB5_CONFIG
- Registry Value: config
- Default: looks in krb5_32.dll's dir and Windows directory
Default Credentials Cache:
- Environment: KRB5CCNAME
- Registry Value: ccname
- Default: API:krb5cc or FILE:%TEMP%\krb5cc or FILE:<windows dir>\krb5cc
Credentials Cache:
-----------------
In addition to standard FILE: (disk file) and MEMORY: (in-process
non-shared memory) Windows supports the API: cache type, which is a
shared memory cache. This is implemented by krbcc32.dll, which is not
included the the krb5-only distribution. Rather, it is part of MIT's
Kerberos for Win32 suite.
As of the 1.3.2 release, a new cache type, MSLSA:, has been added for
use in accessing the Microsoft Kerberos Logon Session credentials
cache. The MSLSA: cache is available when the user logon is performed
using Kerberos either to an Active Directory Domain or a non-Microsoft
KDC.
A user is able to logon to Windows using the Kerberos LSA if the machine
is part of a Windows 2000 or Windows 2003 Active Directory domain or
if the machine has been configured to authenticate to a non-Microsoft KDC
such as MIT. The instructions for configuring a Windows 2000 XP
workstation to authenticate to a non-Microsoft KDC are documented
in TechNet somewhere. In brief:
1. Install the Windows 2000 or XP support tools in order to obtain
the tools: KSETUP.EXE and KTPASS.EXE.
2. Install the Windows 2000 or XP Resource Kit to obtain the tools
KERBTRAY.EXE and KLIST.EXE
3. Add Realms and associated KDCs with: *KSETUP /AddKdc <realm>
[<kdcname>]*. If you leave off the <kdcname> DNS SRV records will
be used.
4. Specify the password change service host for the realm with:
*KSETUP /AddKpasswd <realm> <Kpwdhost>*
5. Assign the realm of the local machine with: *KSETUP /SetRealm
<realm>* where realm must be all upper case.
6. Assign the local machine's password with: *KSETUP
/SetComputerPassword <Password>
*
7. Specify the capabilities of the Realm KDC with: *KSETUP
/SetRealmFlags <realm> <flag> [<flag> ...]* where flags may be
*None, SendAddress, TcpSupported, Delegate, *and *NcSupported*,
8. Map principal names to local accounts with: *KSETUP /MapUser
<principal> <account>*
On the MIT KDC, you must then create service principals using the "Password"
assigned to the machine. So far the minimum list of principals required appear
to be for a machine named "mymachine" in the realm "EXAMPLE.COM" with a
domain name of "example.com":
* host/mymachine@EXAMPLE.COM
* host/mymachine.example.com@EXAMPLE.COM
* cifs/mymachine@EXAMPLE.COM
* cifs/mymachine.example.com@EXAMPLE.COM
There may very well be other serivces for which principals must be created depending
on what services are being executed on the machine.
It is very important to note that while you can successfully log into a Windows
workstation by authenticating to the KDC without creating a host key; the logon
session you receive will not be a Kerberos Logon Session. There will be no Kerberos
principal and no LSA cache to access.
The result of a real KSETUP configuration looks like this:
[C:\4\4NT]ksetup
default realm = KRB5.COLUMBIA.EDU (external)
ATHENA.MIT.EDU:
kdc = kerberos.mit.edu
kdc = kerberos-1.mit.edu
kdc = kerberos-2.mit.edu
kdc = kerberos-3.mit.edu
Realm Flags = 0x0 none
CC.COLUMBIA.EDU:
kdc = kerberos.cc.columbia.edu
Realm Flags = 0x0 none
GRAND.CENTRAL.ORG:
kdc = penn.central.org
kdc = grand-opening.mit.edu
Realm Flags = 0x0 none
KRB5.COLUMBIA.EDU:
kdc = yclept.kermit.columbia.edu
Realm Flags = 0x0 none
OPENAFS.ORG:
kdc = virtue.openafs.org
Realm Flags = 0x0 none
Mapping jaltman@KRB5.COLUMBIA.EDU to jaltman.
Mapping jaltman@CC.COLUMBIA.EDU to jaltman.
Mapping jaltman@ATHENA.MIT.EDU to jaltman.
Mapping all users (*) to a local account by the same name (*).
Other Issues:
------------
The krb4_32.dll that is built (but not installed) is not supported.
If you need Kerberos 4, you can use the krbv4w32.dll that MIT
distributes as part of the MIT Kerberos for Windows distribution.
More Information:
----------------
For more information, please read the Kerberos 5 documentation in
the doc directory of the distribution.
|
