<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .emailquote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>Thanks Amos for your comprehensive reply.. open SSH requires lower case host/ and as you say windows doesn't seem to care so they solved it for that case but seems that uppercase is the convention for HTTP.
<div> Do you have an official reference for HTTP/. As the official uppercase format of SPN for http protocol.i will then file a bug on the adcli repo.</div>
</div>
<div class="x_gmail_extra"><br>
<div class="x_gmail_quote">On 27 Jun 2018 7:11 pm, Amos Jeffries <squid3@treenet.co.nz> wrote:<br>
</div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On 27/06/18 06:53, Mike Surcouf wrote:<br>
> Correction<br>
> <br>
>> supports lowercases all SPNs<br>
> <br>
> should read <br>
> <br>
> lowercases all SPNs (you don’t have an option)<br>
> <br>
> so it always produces http/hostname@REALM.COM<br>
> <br>
> This is a conscious decision by the adcli team<br>
> <br>
> <a href="https://bugs.freedesktop.org/show_bug.cgi?id=84749">https://bugs.freedesktop.org/show_bug.cgi?id=84749</a><br>
> <br>
<br>
I don't see any explicit decision by them to use only lower-case. Just<br>
statements that AD accepts case-insensitive inputs so they don't care to<br>
do anything special.<br>
<br>
<br>
Case insensitivity is a Microsoft custom extension. It cannot be relied<br>
on in non-MS software :<br>
"<br>
Service Principal Names (SPNs) are not case sensitive when used by<br>
Microsoft Windows-based computers. However, an SPN can be used by any<br>
type of computer system. Many of these computer systems, especially<br>
UNIX-based systems, are case-sensitive and require the proper case to<br>
function properly. Care should be taken to use the proper case<br>
particularly when an SPN can be used by a non-Windows-based computer.<br>
<br>
Refer this: <a href="http://technet.microsoft.com/en-us/library/cc731241(WS.10).aspx">
http://technet.microsoft.com/en-us/library/cc731241(WS.10).aspx</a><br>
"<br>
<br>
<br>
Squid also does not parse these details itself. The library being used<br>
by the helper is responsible for all processing of the local machines<br>
keytab. Squid only parses a token of opaque bytes from HTTP message<br>
headers and passes it as opaque string it to the auth helpers. Our<br>
Kerberos helpers use several libraries, and the one which you are using<br>
apparently has case sensitivity for the SPN.<br>
<br>
<br>
<br>
On the technical side:<br>
<br>
Kerberos documents just defer to the protocols where the elements of SPN<br>
are sourced. So some segments in the SPN are case sensitive and others<br>
are not, depending on what type of use the SPN is put.<br>
eg DNS defines hostname as insensitive, so that part is. Some auth<br>
systems define realm as insensitive, others as case-sensitive - so that<br>
part *might be* (or not. ouch!).<br>
<br>
<br>
FWIW, following that deferrance style - the HTTP protocol defines its<br>
protocol name as case-sensitive and has a significant difference between<br>
"HTTP" (transport / messaging syntax) and "http" (URL scheme/syntax,<br>
possibly used over non-HTTP transports).<br>
<br>
So technically / in theory:<br>
* if the SPN is for access to HTTP transport (as Squid SPN are)<br>
- then the "HTTP/" portion should be upper case only.<br>
<br>
* if the SPN is for use of http:// resource URLs (eg, as opposed to<br>
ftp:// URLs fetched with HTTP)<br>
- it can be any case.<br>
<br>
<br>
Squid does not go to that second URL-specific level of detail with<br>
authentication and SPNs. Also, since one is required upper case, and the<br>
other doesn't matter going upper case would be the best choice for us if<br>
we did normalize rather than handle as opaque strings anyway.<br>
<br>
<br>
HTH<br>
Amos<br>
_______________________________________________<br>
squid-dev mailing list<br>
squid-dev@lists.squid-cache.org<br>
<a href="http://lists.squid-cache.org/listinfo/squid-dev">http://lists.squid-cache.org/listinfo/squid-dev</a><br>
</div>
</span></font>
</body>
</html>