Server Authorization

The following urlcp settings control authorization/authentication information sent to the web server (e.g. for restricted-access pages):

• authschemes [add|del|set] [$schemes ...]  

  Sets which authentication schemes to use. $schemes can be one or more of anonymous (i.e. none), FTP, Basic, file, NTLM, NTLMv1 or NTLMv2. (Authentication via SSL client certificates is handled at the SSL not HTTP level; see the sslcertificatefile setting, here.) NTLM is an alias for both NTLMv1 and NTLMv2 together. Returns previous list. The default is all of the above, except for NTLMv1. If the first value of the first argument is add, the given list will be added to the allowed list; if del, deleted from; if set, cleared and set (the default). Added in version 5.1. NTLMv2 support was added in version 5.01.1213917000 20080619; previously, NTLM meant NTLMv1 only, and the NTLMv1 and NTLMv2 settings did not exist.

  If both NTLMv1 and NTLMv2 are enabled, NTLMv2 will be attempted first, then NTLMv1 if that fails. NTLMv2 is more secure than NTLMv1, and is supported by servers running Windows NT4 SP4 or later OSes. Note: Windows servers or domain controllers which have the Local Security policy Network security: LAN Manager authentication level set to "Send NTLMv2 response only/refuse LM & NTLM" (or the registry setting lmCompatibilityLevel set to 5) will only accept NTLMv2, and will thus require NTLMv2 to be enabled. With NTLMv2 disabled via <urlcp>, such servers will reject a <fetch> (even with proper credentials) with 401 Unauthorized or 500 Internal Server Error.

  Similarly, certain Samba implementations or configurations (as servers or domain controllers) may only understand NTLMv1, and may return 401 Unauthorized unless NTLMv1 is specifically enabled via this setting.

• ntlm128bitencryption (string or integer) Sets whether to negotiate 128-bit encryption during NTLM session security, for NTLMv1 and NTLMv2 authentication. The value is one of:

  • ignore Do not request or do 128-bit encryption

  • accept Do not request 128-bit encryption, but accept if peer offers

  • request Request 128-bit encryption, but optionally

  • require Request 128-bit encryption, and fail with error if peer refuses to do 128-bit

  Returns previous setting, as an integer 0-15 (bits 0-1 apply to NTLMv1, bits 2-3 apply to NTLMv2). Added in version 5.01.1222370000 20080925. Note that only flag negotiation is currently supported, as full NTLM session security is not used in NTLM over HTTP. The default is ignore.

• ntlmntlmv2sessionsecurity (string or integer) Sets whether to negotiate NTLMv2 session security during NTLMv1 and NTLMv2 authentication. Same values accepted and returned as for ntlm128bitencryption. Added in version 5.01.1222370000 20080925.

  Enabling NTLMv2 session security can prevent a 500 Internal Server Error response when accessing Windows servers whose Local Security policy for Network security: Minimum session security for NTLM SSP based (including secure RPC) servers is set to include "Require NTLMv2 session security". Thus, the default for this setting is request.

• ntlmsealing (string or integer) Sets whether to negotiate NTLM sealing (message confidentiality) during NTLMv1 and NTLMv2 authentication. Same values accepted and returned as for ntlm128bitencryption. Added in version 5.01.1222370000 20080925. Note that only flag negotiation is currently supported, as NTLM sealing is not used in NTLM over HTTP. The default is ignore.

• ntlmsigning (string or integer) Sets whether to negotiate NTLM signing (message integrity) during NTLMv1 and NTLMv2 authentication. Same values accepted and returned as for ntlm128bitencryption. Added in version 5.01.1222370000 20080925. Note that only flag negotiation is currently supported, as NTLM signing is not used in NTLM over HTTP. The default is ignore.

• ntlmv1128bitencryption (string or integer) ntlmv1ntlmv2sessionsecurity (string or integer) ntlmv1sealing (string or integer) ntlmv1signing (string or integer) Same as ntlm... settings, but only affecting NTLMv1 transactions, not NTLMv2. Return value is previous setting, as integer 0-7. Added in version 5.01.1222370000 20080925.

• ntlmv2128bitencryption (string or integer) ntlmv2ntlmv2sessionsecurity (string or integer) ntlmv2sealing (string or integer) ntlmv2signing (string or integer) Same as ntlm... settings, but only affecting NTLMv2 transactions, not NTLMv1. Return value is previous setting, as integer 0-7. Added in version 5.01.1222370000 20080925.

• pass (string) Sets the password to use when accessing documents. The default is "user@host" for FTP, none for other protocols.

• proxypass (string) Sets the proxy password to use when accessing documents via a proxy. The default is none. Added in version 4.01.1031169922 20020904.

• proxyuser (string) Sets the proxy user to use when accessing documents via a proxy (the Proxy-Authorization: Basic header). The default is none. Added in version 4.01.1031169922 20020904.

• sendlmresponse (boolean) Whether to send the LM response in NTLM authentication responses. The LM response is used for backwards-compatibility with older Windows servers and domain controllers, but is considered less secure if the NTLMv1 protocol is used (NTLMv2 is used by default). On by default. Added in version 5.01.1213740000 20080617.

• sendntlmresponse (boolean) Whether to send the NTLM response in NTLM authentication responses. On by default. Added in version 5.01.1213740000 20080617.

• user (string) Sets the user to use when accessing documents (e.g. Basic or NTLM authentication for HTTP pages, login user for FTP documents, LogonUser() for file:// documents). The default is "anonymous" for FTP, none for other protocols.

  Windows file:// user/pass support was added in version 5.01.1123050000 20050803. For file:// URLs, the Windows operating system requires that the user specified must have Log on as a batch job permission, and the source user (the user running the Vortex script and calling <fetch>, typically I_USR if from a web server) must have Act as part of the operating system permission. Note: before changing these permissions, discuss the security implications with your system administrator. Lack of the former permission may result in Win32 error 1385 ("Logon failure: the user has not been granted the requested logon type at this computer"), whereas lack of the latter permission may result in Win32 error 1314 ("A required privilege is not held by the client").