[Solved, Solved] If a linux computer is not in Active Directory, is it not considered a domain computer?

Question

linux

Hello.
If the question is too short, then the situation is this: there is a windows domain with Active Directory. There is a Linux computer with a suffix like a domain. I configure apache/php/*.keytab web server authentication for linux kerberos. Apache does not want to recognize domain users in any way. There are very strong suspicions that the windows client does not consider the linux computer to be a domain computer, despite the fact that the suffixes are the same (if ASN.1 tells you something, it is from it that you learned that the computer is not recognized as a domain computer) . Once upon a time I "heard" that in the settings of Active Directory policies you can specify what is "considered" as domain computers (maybe only those that are in AD). Do not tell me what this setting could be?
PS
There is a separate test domain (clean), so there are no such problems with kerberos authentication. Do the suffixes match? - means domain!
PPS
IE security zones are set to domain suffix.
UPDATE:
See my answer below for the solution.

Answer 1

Problem solved.
Here is a little investigation.
There are two servers. test-0001 /apache,php/Centos 7.2 (authenticates normally with kerberos) and test-0002 /apache,php/OracleLinux 7.2 (kerberos authentication fails).
An analysis of the HTTP exchange protocol showed that "for some reason" the web client (IE, FF, Chrome) as one distinguishes the computer test-0002 from test-0001 . The difference is that the authentication key that the web client sends as user authorization is very different in "size":
Request to test-0002 (Kerberos authentication failed):
Request to test-0001 (Kerberos authentication works fine):
Let's still find out why the key from test-0002 is shorter than test-0001 ??? To begin with, the key format is ASN.1 (if you are interested, take a look at https://ru.wikipedia.org/wiki/ASN.1 ). There is a viewer of this format on the Internet:
https://lapo.it/asn1js
Key analysis in the request from test-0002 :
1. NEGOEX - as far as I understand, this format provides for the “combination” of several authenticators of the same user in different protocols. Only the NTLM protocol is nested in this key
. Data for the NTLM protocol (which is not supported by the apache mod_auth_gssapi component).
Key analysis in the request to test-0001 :
As you can see, the Kerberos protocol is already present in the second key !!! Interesting! Those. the problem for test-0002 is not on the server side, since the client does not immediately give him the key of the correct format!
Hm. Let's take a look at the windows log, shall we?
0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
0x19 KDC_ERR_PREAUTH_REQUIRED
Wow! What is it??? Is there a problem with the principal? And why only with test-0002 ? (Entries pointing to another computer, e.g. test-0001not found). It turns out that the browser, before responding to the request to the server, already “suspects” something, since it does not give it the necessary key (VERY BIG REQUEST: IF SOMEONE UNDERSTANDS THE PROCESS HOW THE BROWSER DECIDES HOW TO CREATE THE AUTHENTICATION KEY - TELL ME A LITTLE ABOUT THIS !!!).
If you rummage around the Internet, there are many questions about this error ( https://www.google.ru/search?q=KDC_ERR_S_PRINCIPAL... ), but mostly they are unanswered. Dead end? Nothing like this! Let's take a look at Microsoft's SPN documentation: https://msdn.microsoft.com/en-us/library/ms677949%
... spn of my service should be registered in only one account. REMEMBER THIS!!! And here is another interesting point: https://msdn.microsoft.com/en-us/library/ms677601%...
It says here that the SPN must be unique. If it is not unique, then authentication will fail.
But let's check if the SPN for the test-0002 server is really unique? A simple powershell script was found on the Internet , which, after a slight modification, shows the SPNs we are interested in: social.technet.microsoft.com/wiki/contents/article...

#Set Search
cls
$search = New-Object DirectoryServices.DirectorySearcher([ADSI]“”)
$search.filter = “(servicePrincipalName=HTTP/test-*)”
$results = $search.Findall()

#list results
foreach($result in $results)
{
       $userEntry = $result.GetDirectoryEntry()
       Write-host "Object Name = " $userEntry.name -backgroundcolor "yellow" -foregroundcolor "black"
       Write-host "DN      =      "  $userEntry.distinguishedName
       Write-host "Object Cat. = "  $userEntry.objectCategory
       Write-host "servicePrincipalNames"
       $i=1
       foreach($SPN in $userEntry.servicePrincipalName)
       {
           Write-host "SPN(" $i ")   =      " $SPN       $i+=1
       }
       Write-host ""
}

Result:
WHY TWO DIFFERENT ACCOUNTS HAVE THE SAME SPN??? (Remember, just above, I asked you to remember the rule that spn must be unique and assigned to only one account?) Or maybe I misunderstood something? Let's go ahead and see the attributes for test-0002 and test-0001 accounts , but not through the AD snap-in, but through the ADSI snap-in:
test-0002 - OK.
But for test-0001 we are in for a SURPRISE (surprisingly, the surprise is connected with the server account on which EVERYTHING WORKS!!!):
So, so!!! It turns out that spn for the test-0002 server is available in AD in two copies - in the test-0002_httpd account and in the test-0001_httpd account! What according to the documentation should not be ! That was the root of the problem! Duplicate SPN.
After removing the duplicate, everything worked!!!
Thank you all for your attention.)))
PS
Recommendation for SPN. You must use the setspn -S command , not servspn -A , as setspn -S checks for duplicates. I highly recommend reading the article https://social.technet.microsoft.com/wiki/contents... .

Answer 2

Doesn't count. To be considered, it must be entered into the domain - i.e. create a computer account in the domain, assign a password and log in kerberos there (the kinit command, if my memory serves me right).
Otherwise, any outsider who joined the network and set himself the appropriate domain name could gain access to the infrastructure of the AD domain.

Answer 3

A "domain" computer is one that has an account in the domain. An account in the domain is needed so that at least authentication takes place through Kerberos, without entering a password. It is this fact - without entering a password - that is the sign - "domain" or "foreign".
"Alien" can also get a list of users and even authenticate users, but for this he himself first needs to be authenticated in the domain. This is usually done by creating a fake user with no rights and a plain text password. The password of this user is specified in the config in the openform. This is how Apache authentication works (AuthBasicProvider ldap), this is how the PAM module pam_ldap.so and the NSS module nss_ldap.so work, this is how the squid authenticator can work. This is how any Perl/PHP script that needs to authenticate users in AD works - redmine, horde, any bike that uses Net::LDAP.
Of course, this is inconvenient and unsafe. Therefore, they create accounts for computers in AD, configure kerberos via ktpass and reset the resulting keytab to linux - for example, they do it for squid.
You can authenticate in the domain without having an account. But the login and password of at least some user from the domain of the computer that is being authenticated must know.