samba slackware15 domain join failure for slackware domain member server SPNEGO fail
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
samba slackware15 domain join failure for slackware domain member server SPNEGO fail
I have a win2k domain I continue to use ... I have been able to domain join on previous 14.2 . I can do a join with Mint21 . I have been trying to make this work for weeks with no success . I have tried many variations .
Vanilla install fails
I have also built the test version and the quicktest fails with one error on ads if built without ad-dc , quicktest is ok with no errors
If anyone knows the secret config for this let me know.
I am now trying slack15 current and from there I will work on samba from scratch .
I have compared mint21 success to slack15 failure .
mint21 seems to have ldap success which lead to validation
slack15 fails on both SPNEGO NTLMSSP
This is some of the slack15 failure points:
kinit administrator is ok
contact with DC is OK .
On DC machine is added and then disabled. log shows a successful logon but then fails to verify the added machine ...
ads_sasl_spnego_bind: kinit succeeded but SPNEGO bind with Kerberos failed for ldap/dc1.xxxx.loc - user[administrator], realm[XXXX.LOC]: The attempted logon is invalid. This is either due to a bad username or authentication information.
ads_sasl_spnego_bind: SASL bind with Kerberos failed for ldap/dc1.xxxx.loc - user[administrator], realm[XXXX.LOC]: The attempted logon is invalid. This is either due to a bad username or authentication information., try to fallback to NTLMSSP
ads_gen_mod: AD LDAP: Modifying CN=slack15m1,CN=Computers,DC=xxxx,DC=loc
ads_print_error: AD LDAP ERROR: 53 (Server is unwilling to perform): 00002077: SvcErr: DSID-031D0AAB, problem 5003 (WILL_NOT_PERFORM), data 0
NTLMSSP Sign/Seal - using NTLM1
SPNEGO login failed: An invalid parameter was passed to a service or function.
SPNEGO login failed: The attempted logon is invalid. This is either due to a bad username or authentication information
Yes, it is most likely the best solution to upgrade the DC, there is a reason that SMBv1 has been abandoned by Samba as well as Microsoft.
However, if it is not possible to upgrade the DC and your machines are in a network that you really know for sure that you cant trust, the disabling of SMBv1 in Samba is only a default setting which can be overridden.
In smb.conf you can set:
Code:
client min protocol = NT1
server min protocol = NT1
Setting the client min protocol as described above will probably allow you to connect to your old DC again. Setting the server min protocol will allow old Windows machines in your network to connect to your samba shares. For more information about those settings there is a man-page for smb.conf.
I have those same setting on my Mint21 install with similar up-to-date samba version and the join works ... ( I've tried the same working mint21 smb.conf) config ) . It seems to be a crypto failure with the ldap update ...
yes this is required:
client min protocol = NT1
server min protocol = NT1
my try with slack15-current gives the same failures.
"LDAP: error code 53 - Unwilling To Perform". The search users/groups operation uses the Server-Side Sort control feature of LDAP.
The LDAP Server must have a copy of all objects within the search scope, in order for the SSS (Server-side sort ) control to work. The LDAP server needs a copy of every replica, if the search scope started at the top of the tree. If it doesn't have a copy of all objects in the search scope, it will return LDAP error 53 when the SSS control is used in a search request.
...
The problem was resolved after replica type was changed to Read/Write
GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Message stream modified)
In this case it meant that the Kerberos key you obtained was rejected by the LDAP server because of an IP mismatch. Check your hosts file, your DNS and your conf files (sssd, samba, krb5, ldap etc.) to make sure your FQDN's are consistent.
At this point in time a Samba DC is more functional and secure than Win2k. There is no reason to persist with 2k.
Since this is the Slackware subforum, it's probably on topic to mention that you cannot create a working Samba DC using the standard Slackware Samba packages, as they are built against MIT Kerberos.
MIT-based Samba is broken and considered experimental. According to the Samba developers, it is unsupported. It will remain broken until certain fixes are implemented in MIT Kerberos, and there's no indication that this will happen anytime soon, if at all.
It you want to run a Samba AD DC, currently you must build Samba against Heimdal, which is included with the Samba source and was recently upgraded against upstream.
Since this is the Slackware subforum, it's probably on topic to mention that you cannot create a working Samba DC using the standard Slackware Samba packages, as they are built against MIT Kerberos.
MIT-based Samba is broken and considered experimental.
From the Slackware Changelog:
Quote:
Originally Posted by Slackware ChangeLog
Fri Jul 14 22:11:58 UTC 2017
...
n/samba-4.6.6-x86_64-1.txz: Upgraded.
This update fixes an authentication validation bypass security issue:
"Orpheus' Lyre mutual authentication validation bypass"
All versions of Samba from 4.0.0 onwards using embedded Heimdal
Kerberos are vulnerable to a man-in-the-middle attack impersonating
a trusted server, who may gain elevated access to the domain by
returning malicious replication or authorization data.
Samba binaries built against MIT Kerberos are not vulnerable.
For more information, see: https://www.samba.org/samba/security...017-11103.html https://cve.mitre.org/cgi-bin/cvenam...CVE-2017-11103
(* Security fix *)
...
I'll also mention that I run a small office and have been considering setting up a Samba DC for some time.
My own findings in experiments with setting up a Slackware 15 Samba DC are that the default build of Samba in Slackware 15 will give you a functional DC in minutes, which will allow W10 to join. I spent a couple of hours on it before Christmas, and was able to do things like set Group Policy. I stopped tinkering with it due to lack of time, but will get back to it one day soon.
Edit: For clarity, I'm still learning how Samba works... which is why I'm experimenting with it.
That log entry is more than five years old, and not relevant in the slightest. (FWIW, MIT KRB didn't work with Samba as a DC back then either.)
Quote:
Originally Posted by rkelsen
My own findings in experiments with setting up a Slackware 15 Samba DC are that the default build of Samba in Slackware 15 will give you a functional DC in minutes, which will allow W10 to join.
It's still broken, though. I wouldn't trust it with anything even remotely important. There's a reason Samba 4+ has always shipped with embedded Heimdal as the default option.
Quote:
Originally Posted by rkelsen
I spent a couple of hours on it before Christmas, and was able to do things like set Group Policy.
If you want an instant Samba-induced headache, apply Security Filtering to your GPOs. Unless you use RFC2307 mode and you've assigned all your computer accounts SIDs manually (which is a major chore), or you have only one DC (which is insane), things will fall apart really quickly.
I have gone an build a slack15-current with the latest samba version...
The tests seem to come out cleaner ... the build is different then 15.0
I agree I question the use of MIT Kerb .. but if you notice slack comes with sys mit kerb in the default install krb5-1.20.1-x86_64-1
pam-krb5-4.11-x86_64-1 ... so using heimdal introduces two kerbs ...
I've been make test samba builds with and without MIT kerb in the samba build ..
And yes I am in progress with just making a samba AD-DC to move forward in the future...
I was trying to keep things more as they are ... and so far I've been successful ...
Been going thru the Debug 10 failures ... Also turned off network manager to see if that was the problem .... nope...
One problem is getting winbind to run before i've joined a dc ... so that maybe the kicker of my fail ... I can't get it to run without being a dc or being joined ... I think Mint starts it as part of the join process ...
If you setup a samba AD-DC winbindd IS running
ads_sasl_spnego_bind: SASL bind with Kerberos failed for ldap/dc1.xxxx.loc - user[administrator], realm[XXXX]: The attempted logon is invalid. This is either due to a bad username or authentication information., try to fallback to NTLMSSP
,...
Found pdb backend tdbsam
pdb backend tdbsam has a valid init
Could not find map for sid S-1-5-32-544
create_builtin_administrators: Failed to create Administrators Unable to auto-add domain administrators to BUILTIN\Administrators duringjoin because winbindd must be running.
Could not find map for sid S-1-5-32-545
create_builtin_users: Failed to create Users
Unable to auto-add domain users to BUILTIN\users during join because winbindd must be running.
Could not find map for sid S-1-5-32-546
create_builtin_guests: Failed to create Guests
Unable to auto-add domain guests to BUILTIN\Guests during join because winbindd must be running.
...
This seems to be the bit .... falling over ....
...
smb_krb5_trace_cb: [2251] 1673677460.349889: Received error from KDC: -1765328359/Additional pre-authentication required
smb_krb5_trace_cb: [2251] 1673677460.349892: Preauthenticating using KDC method data
smb_krb5_trace_cb: [2251] 1673677460.349893: Processing preauth types: PA-PK-AS-REP_OLD (15), PA-ETYPE-INFO (11), PA-ENC-TIMESTAMP (2)
smb_krb5_trace_cb: [2251] 1673677460.349894: Selected etype info: etype rc4-hmac, salt "", params ""
smb_krb5_trace_cb: [2251] 1673677460.349895: AS key obtained for encrypted timestamp: rc4-hmac/6227
smb_krb5_trace_cb: [2251] 1673677460.349897: Encrypted timestamp (for 1673677460.658595): plain 301AA011180F32303233303131343036323432305AA10502030A0CA3, encrypted 0B817102EC8C36CEF5E77B4580915F2B4DDBA4DB29C4791CF6214DA378FE3D32C3E295D759AFA65DA5517EDC5EA6AC138196 6371
smb_krb5_trace_cb: [2251] 1673677460.349898: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
smb_krb5_trace_cb: [2251] 1673677460.349899: Produced preauth for next request: PA-ENC-TIMESTAMP (2)
smb_krb5_trace_cb: [2251] 1673677460.349900: Sending request (241 bytes) to XXXX.LOC
smb_krb5_trace_cb: [2251] 1673677460.349901: Resolving hostname 172.16.2.8
smb_krb5_trace_cb: [2251] 1673677460.349902: Sending initial UDP request to dgram 172.16.2.8:88
smb_krb5_trace_cb: [2251] 1673677460.349903: Received answer (1221 bytes) from dgram 172.16.2.8:88
smb_krb5_trace_cb: [2251] 1673677460.349904: Sending DNS URI query for _kerberos.XXXX.LOC.
smb_krb5_trace_cb: [2251] 1673677460.349905: No URI records found
smb_krb5_trace_cb: [2251] 1673677460.349906: Sending DNS SRV query for _kerberos-master._udp.XXXX.LOC.
smb_krb5_trace_cb: [2251] 1673677460.349907: Sending DNS SRV query for _kerberos-master._tcp.XXXX.LOC.
smb_krb5_trace_cb: [2251] 1673677460.349908: No SRV records found smb_krb5_trace_cb: [2251] 1673677460.349909: Response was not from primary KDC
smb_krb5_trace_cb: [2251] 1673677460.349910: AS key determined by preauth: rc4-hmac/6227
smb_krb5_trace_cb: [2251] 1673677460.349911: Decrypted AS reply; session key is: rc4-hmac/9717
smb_krb5_trace_cb: [2251] 1673677460.349912: FAST negotiation: unavailable
kerberos_kinit_password_ext: SLACK15T2$@XXXX.LOC mapped to slack15t2$@XXXX.LOC
smb_krb5_trace_cb: [2251] 1673677460.349913: Initializing MEMORY:cliconnect with default princ slack15t2$@XXXX.LOC
smb_krb5_trace_cb: [2251] 1673677460.349914: Storing slack15t2$@XXXX.LOC -> krbtgt/XXXX.LOC@XXXX.LOC in MEMORY:cliconnect
cli_session_creds_prepare_krb5: Successfully authenticated as SLACK15T2$@XXXX.LOC (slack15t2$@XXXX.LOC) to access DC1.xxxx.loc using Kerberos
cli_session_setup_spnego_send: Connect to DC1.xxxx.loc as slack15t2$@XXXX.LOC using SPNEGO
Starting GENSEC mechanism spnego
gensec_spnego_client_negTokenInit_start: Server claims it's principal name is DC1$@XXXX.LOC Starting GENSEC submechanism gse_krb5
gse_get_client_auth_token: gss_init_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: Message stream modified](2529638953)
gensec_update_send: gse_krb5[0x55ddefeda230]: subreq: 0x55ddefe86400
gensec_update_send: spnego[0x55ddefee4d30]: subreq: 0x55ddeff114c0
gensec_update_done: gse_krb5[0x55ddefeda230]: NT_STATUS_LOGON_FAILURE tevent_req[0x55ddefe86400/../../source3/librpc/crypto/gse.c:895]: state[3] error[-7963671676338569107 (0x917B5ACDC000006D)] state[struct gensec_gse_update_state (0x55ddefe865c0)] timer[(nil)] finish[../../source3/librpc/crypto/gse.c:909]
gensec_spnego_client_negTokenInit_step: gse_krb5: creating NEG_TOKEN_INIT for cifs/DC1.xxxx.loc failed (next[(null)]): NT_STATUS_LOGON_FAILURE
gensec_update_done: spnego[0x55ddefee4d30]: NT_STATUS_LOGON_FAILURE tevent_req[0x55ddeff114c0/../../auth/gensec/spnego.c:1631]: state[3] error[-7963671676338569107 (0x917B5ACDC000006D)] state[struct gensec_spnego_update_state (0x55ddeff11680)] timer[(nil)] finish[../../auth/gensec/spnego.c:2039] SPNEGO login failed: The attempted logon is invalid. This is either due to a bad username or authentication information.
There's a reason Samba 4+ has always shipped with embedded Heimdal as the default option.
Well, if you want to change this, it's not very difficult to modify the SlackBuild script in the Slackware sources. In under 10 minutes I got a new Slackware Samba package compiled using the bundled Heimdal.
Quote:
Originally Posted by Ser Olmy
If you want an instant Samba-induced headache, apply Security Filtering to your GPOs.
That seems like an advanced feature which may not be required in the environment where I'm considering this...
With that said, does Security Filtering work with Heimdal?
Well, if you want to change this, it's not very difficult to modify the SlackBuild script in the Slackware sources. In under 10 minutes I got a new Slackware Samba package compiled using the bundled Heimdal.
You're absolutely right, and that's indeed what you'll have to do if you want to run a Samba AD DC on Slackware. The same is true for Red Hat-based distributions, as Red Hat compiles Samba against MIT Kerberos with all AD DC functionality explicitly disabled as a matter of policy.
Quote:
Originally Posted by rkelsen
That seems like an advanced feature which may not be required in the environment where I'm considering this...
It's a pretty basic feature, and it's the only way to apply GPOs selectively to objects in the same OU when the GPO settings do not support item-level targeting, like most (if not all) of the security-related settings.
But sure, in some (probably very small) environments you could make do without GPO security filtering.
Quote:
Originally Posted by rkelsen
With that said, does Security Filtering work with Heimdal?
Kerberos does authentication/authorisation, while the GPO issue has to do with permissions on SYSVOL objects. And since Samba doesn't do SYSVOL replication at all but has to rely on workarounds, you run into problems regardless of the Kerberos implementation used.
Once you've made those changes, run the SlackBuild script as root and after approx 10 minutes there will be a package in /tmp/ which you can install with upgradepkg.
reject md5 clients = yes # the new default
server reject md5 schannel:TRICERATOPS$ = no
server reject md5 schannel:GREYWACKE$ = no
will allow only "TRICERATOPS$" and "GREYWACKE$" to use RC4 (HMAC-MD5)
cryptography.
If you really need to support legacy DES based clients, it is now
also possible to allow them explicitly:
allow nt4 crypto = no # the default
reject md5 clients = yes # the new default
allow nt4 crypto:NT4CLIENT$ = yes
....
====================
Workaround and notes
====================
Setting 'reject md5 clients = yes' (on DCs) and 'reject md5 servers = yes'
(on DCs and member servers) will avoid this vulnerable protocol,
but this will reject legacy clients which have worked before.
'winbind sealed pipes = yes' should also be kept at its default value!
Regarding the encryption requirement, thankfully Samba addressed
SamLogon NTLM session key disclosure issue in CVE-2016-2111.
In preparation of the update to the new Samba version on an AD DC
would could try to identify legacy clients from (JSON) audit logs
(if configured). You can find domain member servers that use
AES (HMAC-SHA256) vs RC4 (HMAC-MD5) via the passwordType
element.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
