1NTLM_AUTH(1) User Commands NTLM_AUTH(1)
2
3
4
6 ntlm_auth - tool to allow external access to Winbind's NTLM
7 authentication function
8
10 ntlm_auth
11
13 This tool is part of the samba(7) suite.
14
15 ntlm_auth is a helper utility that authenticates users using NT/LM
16 authentication. It returns 0 if the users is authenticated successfully
17 and 1 if access was denied. ntlm_auth uses winbind to access the user
18 and authentication data for a domain. This utility is only intended to
19 be used by other programs (currently Squid and mod_ntlm_winbind)
20
22 The winbindd(8) daemon must be operational for many of these commands
23 to function.
24
25 Some of these commands also require access to the directory
26 winbindd_privileged in $LOCKDIR. This should be done either by running
27 this command as root or providing group access to the
28 winbindd_privileged directory. For security reasons, this directory
29 should not be world-accessable.
30
32 --helper-protocol=PROTO
33 Operate as a stdio-based helper. Valid helper protocols are:
34
35 squid-2.4-basic
36 Server-side helper for use with Squid 2.4's basic (plaintext)
37 authentication.
38
39 squid-2.5-basic
40 Server-side helper for use with Squid 2.5's basic (plaintext)
41 authentication.
42
43 squid-2.5-ntlmssp
44 Server-side helper for use with Squid 2.5's NTLMSSP
45 authentication.
46
47 Requires access to the directory winbindd_privileged in
48 $LOCKDIR. The protocol used is described here:
49 http://devel.squid-cache.org/ntlm/squid_helper_protocol.html.
50 This protocol has been extended to allow the NTLMSSP Negotiate
51 packet to be included as an argument to the YR command. (Thus
52 avoiding loss of information in the protocol exchange).
53
54 ntlmssp-client-1
55 Client-side helper for use with arbitrary external programs
56 that may wish to use Samba's NTLMSSP authentication knowledge.
57
58 This helper is a client, and as such may be run by any user.
59 The protocol used is effectively the reverse of the previous
60 protocol. A YR command (without any arguments) starts the
61 authentication exchange.
62
63 gss-spnego
64 Server-side helper that implements GSS-SPNEGO. This uses a
65 protocol that is almost the same as squid-2.5-ntlmssp, but has
66 some subtle differences that are undocumented outside the
67 source at this stage.
68
69 Requires access to the directory winbindd_privileged in
70 $LOCKDIR.
71
72 gss-spnego-client
73 Client-side helper that implements GSS-SPNEGO. This also uses a
74 protocol similar to the above helpers, but is currently
75 undocumented.
76
77 ntlm-server-1
78 Server-side helper protocol, intended for use by a RADIUS
79 server or the 'winbind' plugin for pppd, for the provision of
80 MSCHAP and MSCHAPv2 authentication.
81
82 This protocol consists of lines in the form: Parameter: value
83 and Parameter:: Base64-encode value. The presence of a single
84 period . indicates that one side has finished supplying data
85 to the other. (Which in turn could cause the helper to
86 authenticate the user).
87
88 Currently implemented parameters from the external program to
89 the helper are:
90
91 Username
92 The username, expected to be in Samba's unix charset.
93
94 Examples:
95 Username: bob
96
97 Username:: Ym9i
98
99 NT-Domain
100 The user's domain, expected to be in Samba's unix charset.
101
102 Examples:
103 NT-Domain: WORKGROUP
104
105 NT-Domain:: V09SS0dST1VQ
106
107 Full-Username
108 The fully qualified username, expected to be in Samba's
109 unix charset and qualified with the winbind separator.
110
111 Examples:
112 Full-Username: WORKGROUP\bob
113
114 Full-Username:: V09SS0dST1VQYm9i
115
116 LANMAN-Challenge
117 The 8 byte LANMAN Challenge value, generated randomly by
118 the server, or (in cases such as MSCHAPv2) generated in
119 some way by both the server and the client.
120
121 Examples:
122 LANMAN-Challenge: 0102030405060708
123
124 LANMAN-Response
125 The 24 byte LANMAN Response value, calculated from the
126 user's password and the supplied LANMAN Challenge.
127 Typically, this is provided over the network by a client
128 wishing to authenticate.
129
130 Examples:
131 LANMAN-Response:
132 0102030405060708090A0B0C0D0E0F101112131415161718
133
134 NT-Response
135 The >= 24 byte NT Response calculated from the user's
136 password and the supplied LANMAN Challenge. Typically, this
137 is provided over the network by a client wishing to
138 authenticate.
139
140 Examples:
141 NT-Response:
142 0102030405060708090A0B0C0D0E0F10111213141516171
143
144 Password
145 The user's password. This would be provided by a network
146 client, if the helper is being used in a legacy situation
147 that exposes plaintext passwords in this way.
148
149 Examples:
150 Password: samba2
151
152 Password:: c2FtYmEy
153
154 Request-User-Session-Key
155 Upon successful authentication, return the user session key
156 associated with the login.
157
158 Examples:
159 Request-User-Session-Key: Yes
160
161 Request-LanMan-Session-Key
162 Upon successful authentication, return the LANMAN session
163 key associated with the login.
164
165 Examples:
166 Request-LanMan-Session-Key: Yes
167
168
169 Warning
170 Implementers should take care to base64 encode any data (such
171 as usernames/passwords) that may contain malicious user data,
172 such as a newline. They may also need to decode strings from
173 the helper, which likewise may have been base64 encoded.
174
175 --username=USERNAME
176 Specify username of user to authenticate
177
178 --domain=DOMAIN
179 Specify domain of user to authenticate
180
181 --workstation=WORKSTATION
182 Specify the workstation the user authenticated from
183
184 --challenge=STRING
185 NTLM challenge (in HEXADECIMAL)
186
187 --lm-response=RESPONSE
188 LM Response to the challenge (in HEXADECIMAL)
189
190 --nt-response=RESPONSE
191 NT or NTLMv2 Response to the challenge (in HEXADECIMAL)
192
193 --password=PASSWORD
194 User's plaintext password
195
196 If not specified on the command line, this is prompted for when
197 required.
198
199 For the NTLMSSP based server roles, this parameter specifies the
200 expected password, allowing testing without winbindd operational.
201
202 --request-lm-key
203 Retrieve LM session key
204
205 --request-nt-key
206 Request NT key
207
208 --diagnostics
209 Perform Diagnostics on the authentication chain. Uses the password
210 from --password or prompts for one.
211
212 --require-membership-of={SID|Name}
213 Require that a user be a member of specified group (either name or
214 SID) for authentication to succeed.
215
216 --pam-winbind-conf=FILENAME
217 Define the path to the pam_winbind.conf file.
218
219 --target-hostname=HOSTNAME
220 Define the target hostname.
221
222 --target-service=SERVICE
223 Define the target service.
224
225 --use-cached-creds
226 Whether to use credentials cached by winbindd.
227
228 --allow-mschapv2
229 Explicitly allow MSCHAPv2.
230
231 --offline-logon
232 Allow offline logons for plain text auth.
233
234 -?|--help
235 Print a summary of command line options.
236
237 --usage
238 Display brief usage message.
239
240 -d|--debuglevel=DEBUGLEVEL
241 level is an integer from 0 to 10. The default value if this
242 parameter is not specified is 1 for client applications.
243
244 The higher this value, the more detail will be logged to the log
245 files about the activities of the server. At level 0, only critical
246 errors and serious warnings will be logged. Level 1 is a reasonable
247 level for day-to-day running - it generates a small amount of
248 information about operations carried out.
249
250 Levels above 1 will generate considerable amounts of log data, and
251 should only be used when investigating a problem. Levels above 3
252 are designed for use only by developers and generate HUGE amounts
253 of log data, most of which is extremely cryptic.
254
255 Note that specifying this parameter here will override the log
256 level parameter in the /etc/samba/smb.conf file.
257
258 --debug-stdout
259 This will redirect debug output to STDOUT. By default all clients
260 are logging to STDERR.
261
262 --configfile=<configuration file>
263 The file specified contains the configuration details required by
264 the client. The information in this file can be general for client
265 and server or only provide client specific like options such as
266 client smb encrypt. See /etc/samba/smb.conf for more information.
267 The default configuration file name is determined at compile time.
268
269 --option=<name>=<value>
270 Set the smb.conf(5) option "<name>" to value "<value>" from the
271 command line. This overrides compiled-in defaults and options read
272 from the configuration file. If a name or a value includes a space,
273 wrap whole --option=name=value into quotes.
274
275 -V|--version
276 Prints the program version number.
277
279 To setup ntlm_auth for use by squid 2.5, with both basic and NTLMSSP
280 authentication, the following should be placed in the squid.conf file.
281
282 auth_param ntlm program ntlm_auth --helper-protocol=squid-2.5-ntlmssp
283 auth_param basic program ntlm_auth --helper-protocol=squid-2.5-basic
284 auth_param basic children 5
285 auth_param basic realm Squid proxy-caching web server
286 auth_param basic credentialsttl 2 hours
287
288 Note
289 This example assumes that ntlm_auth has been installed into your
290 path, and that the group permissions on winbindd_privileged are as
291 described above.
292
293 To setup ntlm_auth for use by squid 2.5 with group limitation in
294 addition to the above example, the following should be added to the
295 squid.conf file.
296
297 auth_param ntlm program ntlm_auth --helper-protocol=squid-2.5-ntlmssp --require-membership-of='WORKGROUP\Domain Users'
298 auth_param basic program ntlm_auth --helper-protocol=squid-2.5-basic --require-membership-of='WORKGROUP\Domain Users'
299
301 If you're experiencing problems with authenticating Internet Explorer
302 running under MS Windows 9X or Millennium Edition against ntlm_auth's
303 NTLMSSP authentication helper (--helper-protocol=squid-2.5-ntlmssp),
304 then please read the Microsoft Knowledge Base article #239869 and
305 follow instructions described there.
306
308 This man page is part of version 4.17.5 of the Samba suite.
309
311 The original Samba software and related utilities were created by
312 Andrew Tridgell. Samba is now developed by the Samba Team as an Open
313 Source project similar to the way the Linux kernel is developed.
314
315 The ntlm_auth manpage was written by Jelmer Vernooij and Andrew
316 Bartlett.
317
318
319
320Samba 4.17.5 01/26/2023 NTLM_AUTH(1)