After NETH8 migration - SAMBA shares on Windows cannot be accessed via the usual domain name

Support
1

Dear community,

After migrating to NETH8, the SAMBA shares are not accessible on Windows – at least not for Windows clients connected via AD.

On MacOS (and iOS), the shares are accessible without any problems – using the last used SUB.DOMAIN name (example: mysrv.domain.tld) ​​AND any other domain name that points to the same IPv4 address (e.g., mysrv.domain.internal).

Only on Windows, this doesn’t work. A login window opens, but the credentials don’t work.

I found the following post in the Nethserver community that already described the problem:

There, they recommended trying to access them via the DC subdomain, i.e., ad.domain.tld. This works spontaneously, but of course it’s not a solution.

A reference was also made to the following post:

which explains that this problem will be resolved (in the future) by a “netbios aliases” entry in “include.conf.” This (old) entry is actually present in my case. But who will still use NETBIOS in 2025?

How do I explain to NETH8 (or presumably KERBEROS) that it also allows access to the shares via the usual, or rather, its own, domain name?

And another question:
How complete is the migration regarding access to the HOME shares, whose contents are included by the Windows clients during Windows login?

Regards, Yummiweb

Addendum:

The DNS resolutions are all correct, regardless of whether I use NETH8 directly as the DNS or via another local DNS mixed with NETH8 (ad.domain.tld and */ad.domain.tld addresses are resolved directly by the local DNS from NETH8).

Further addendum:
Since this morning, no connections from MacOS (users connected via LDAP) are possible (different NETH8 installations and environments). Nothing has changed since Thursday; access to all ports specified in “Settings > Firewall > Service” has been granted (and checked).

It’s possible that the LDAP integration was incomplete on Thursday, which is why the login was using a different method (perhaps not Kerberos). The shares are still accessible on iOS, as there is no LDAP connection.

Login via ad.domain.tld has not been tested yet.

Login once worked via username@domain.tld, which actually shouldn’t work anymore?

What would the current forms of usernames be?

username
username@domain.tld
username@DCDOMAIN
DCDOMAIN\username
???

Further addendum:

The SAMBA port lists in NETH8 are specified as follows:
TCP: 53, 88, 135, 139, 389, 445, 464, 636, 3268, 3269, 49152-65535
UDP: 53, 88, 123, 137, 138, 389, 464

I’ve restricted the ports to TCP: 53, 389, 445, and 636 for now, so you can at least log in from the Mac again.

As far as I can tell, the problem is due to some processing or rewriting of the shared addresses during login, or a restriction (Kerberos) to certain shared addresses.

What exactly has changed as a result of the migration, and how can I correct or add it? The migration (strictly speaking) had the sole purpose of saving me the AD fiddling.

2

Do you see any recurring error in samba-dc log?

journalctl -f -t samba-dc

As DNS aliases are ok, check also your DC names in LDAP:

runagent -m samba1 podman exec samba-dc samba-tool computer show dc1 | grep servicePrincipalName
1 Like
3

Thank you for your reply.

I need to analyze the log in a structured way because different errors occur with different actions. What seems to be common in general:

samba-dc[1234546]: TLS source4/lib/tls/tls_tstream.c:1449 - Decryption has failed.

I can already say the following. As described, this is a DC migration, so my prefix is ​​not “dc2” but “nsdc-mysrv”:

runagent -m samba1 podman exec samba-dc samba-tool computer show nsdc-mysrv | grep servicePrincipalName

servicePrincipalName: HOST/nsdc-mysrv.ad.mydomain.tld
servicePrincipalName: HOST/nsdc-mysrv.ad.mydomain.tld/MYDOMAIN
servicePrincipalName: ldap/nsdc-mysrv.ad.mydomain.tld/MYDOMAIN
servicePrincipalName: GC/nsdc-mysrv.ad.mydomain.tld/ad.mydomain.tld
servicePrincipalName: ldap/nsdc-mysrv.ad.mydomain.tld
servicePrincipalName: HOST/nsdc-mysrv.ad.mydomain.tld/ad.mydomain.tld
servicePrincipalName: ldap/nsdc-mysrv.ad.mydomain.tld/ad.mydomain.tld
servicePrincipalName: HOST/NSDC-MYSRV
servicePrincipalName: E1234567-1234-1234-ABCD-12AB12AB1ABC1/a1a1a123-12ab-1a1a-a1a1-1234a12abcd1/ad.mydomain.tld
servicePrincipalName: ldap/a1a1a123-12ab-1a1a-a1a1-1234a12abcd1._msdcs.ad.mydomain.tld
servicePrincipalName: ldap/NSDC-MYSRV
servicePrincipalName: RestrictedKrbHost/NSDC-MYSRV
servicePrincipalName: RestrictedKrbHost/nsdc-mysrv.ad.mydomain.tld
servicePrincipalName: ldap/nsdc-mysrv.ad.mydomain.tld/DomainDnsZones.ad.mydomain.tld
servicePrincipalName: ldap/nsdc-mysrv.ad.mydomain.tld/ForestDnsZones.ad.mydomain.tld

However, what else I’ve noticed (in summary):

Mac - without Kerberos connection (port 88 blocked):

“user.name” (without prefix or suffix)
Works almost normally, nothing unusual.

Mac - with Kerberos connection (port 88 open):

“user.name” (without prefix or suffix)
Sometimes works normally. Sometimes the connection takes a very long time and then drops. If you abort the connection attempt and then reconnect, it works.

“MYDOMAIN\user.name” (with prefix) works, and
“user.name@mydomain” (with suffix) also works.

Windows - without AD connection (local)
Works on another NETH8 as usual via “user.name”

Windows (with AD) - without Kerberos connection
I haven’t tested it; it doesn’t make sense due to the temporary login situation.

Windows (with AD) - with Kerberos connection

MYDOMAIN is automatically prepended to the username.

“user.name” ONLY works when connecting to the domain name “ad.mydomain.tld”.

If the shared domain is different, e.g. (as before) “mysrv.mydomain.tld” or “mysrv.mydomain.internal” (of course leading to the same IP address), the behavior is as follows:

(MYDOMAIN is automatically prepended to the username)
“user.name” DOES NOT work

But if “Use another account” is selected and the prepended domain prefix is ​​changed to “local” with .\ the following surprisingly works:
“.\user.name@mydomain”
Correction:
The login window will then simply disappear and an overview of the shares will appear. Access to the shares will no longer be possible.

Does anyone understand this?

4

Maybe it helps to add some samba options for Mac

See also Configure Samba to Work Better with Mac OS X - SambaWiki

Does it work with IP like \\192.168.0.1\share or name like \\nsdc-mysrv\share?

Are there dots in the usernames? Does it work with a username without a dot?

Which Windows version are you using? Did you try another Windows client?

A Windows client could get confused when connecting to the same share with different users so tests won’t work anymore.

5

This can easily be solved from the Windows Command line:

To delete all network authentication

C:\> net use * /d

To view the current network connection

C:\> net use

Disconnecting the IPC$ share often helps:

C:\> net use ipc$ /d

also

C:\> net use \\server\ipc$ /d

where server is either IP or NetBIOS Name.

My 2 cents
Andy

2 Likes
6

Recently, I asked whether it wouldn’t make sense to detach the DC from the Samba share so that you wouldn’t have to restore so much data in the event of a restore. One of the answers was that the DC wouldn’t cause much problems. Well, that may be true, but there are situations where you’d like to roll it back to an earlier state:

I took another look at the Windows domain client and thought it would be a good idea to roll the client back to a previous snapshot – from before the NETH8 migration. In fact, that was a bad idea because the trust relationship of the (old) machine was no longer valid. Since the machine (not the AD) is a test object anyway, I removed it from the domain as a test and tried to log back in to the domain after a reboot. The removal worked, but the first re-login didn’t, because that would have resulted in a duplicate host entry in the LDAP. The old entry was apparently not removed during the logoff. It may be that’s how it’s supposed to be, but I’m not sure. Anyway, I had to remove the old host entry (thanks to LAM!!!) before I could log the machine back in. But that only worked halfway because there were still trust issues; I couldn’t log any domain user onto the machine (not even a domain admin). So I left the domain again, deleted the host entry again, and rejoined the domain. This resulted in the following error during domain login:

“Error changing the DNS name for the computer’s primary domain to “”, retaining the name “ad.mydomain.tld”. Error: The PRC server is unavailable.”

After that, I was at least able to log in again (as a domain admin). But unfortunately, nothing else worked. And the desktop didn’t contain the elements located in the “Desktop” home share.

From here on, I can’t log in to either “ad.mydomain.tld” or “mysrv.mydomain.tld” - regardless of the prefix or suffix. The best thing that happens is that a list of shares appears, but nothing can be accessed. Not even the respective “home” share. The message always reads:

“Could not access \URL\SHARENAME. You may not have permission to use this network resource. If you log in, etc., etc.
Incorrect parameter.”

However, I can suddenly access “nsdc-mysrv.ad.mydomain.tld” – without any login (of course, after user login on the client). And while I can access these shares, no “net use” entry is listed.

Access also works via IP address, even then without any additional login and again without a “net use” entry. Only the share names are then all in lowercase.

By the way, the usernames here are “firstname.lastname,” with a period; the admin names don’t have a period in their names. Even if that had always worked for both Windows clients and other services (Mail, SOGo).

So, now we have a number of very different and strange behaviors when logging into NETH8 AD/Samba shares (migrated from Nethserver7):

  • MacOS clients with and without AD integration.
  • Windows clients without AD integration,
  • with old AD integration (with and without full communication),
  • and with new AD integration.

And each time, the options and behavior change as to whether and how access to domain resources is allowed.

During this time, nothing has changed in the AD except that the trust relationship with the old Windows client was removed (its snapshot was probably outdated compared to the AD), the machine was logged off twice, its hostname was removed from the AD twice, and logged back on twice.

Does anyone see a pattern here? Who or what is actually blocking access here? Is Kerberos because it’s too restrictive with URLs?

I’d like to understand what’s happening so I can manage it.

Regards, Yummiweb

Addendum:
I don’t want to change anything about the Samba options for Mac for now. I also assumed they would have been carried over during the migration?

Did the migration tool create a set of certain legacy configurations for comparison? Or do I have to fish them out from the old backups?

By the way, backing up these files during the migration would not only have been very useful but also typical Linux behavior. If package updates provide completely new configuration files, the previous configurations are also backed up (or the new configurations are marked as original).

Addendum 2:

I’ve captured all of the log entries, anonymized them, and removed any other user activity. However, there are still about 1,000 lines left from which I could quote excerpts.

7

net use lists network drives, if you just use explorer to connect to a share it’s not listed.

They didn’t exist in NS7.

The migration tool doesn’t change NS7 samba, it just disables it so config files should be still there.

8

Hi @yummiweb

I would just like to point out that in now over 20 NS8 migrations and new installations with AD, I have NOT seen any behaviour like this…

I myself am a Macbook user - my Macbook is NOT entered in any AD as member, although it does use the same “Workgroup” name.

My Macbook connects to shares in my Home Office (AD Shares!), but also to AD shares at my clients without issues.

My 2 cents
Andy

9

I still haven’t found the origin of that message. I suspect it’s an Ldapproxy connection. However, it seems harmless, just log noise. I have the same message on my server, and everything works correctly.

For the other issues, I can only say that I’ve also experienced a similar problem after a migration. Share access by hostname didn’t work, but using the IP did. However, in that case, the required hostname was not the DC name but the NS7 one (the name of the file server). What seemed to fix the issue was adding an alternative servicePrincipalName with:

samba-tool spn add ...
2 Likes
10

Dear Andy,

I don’t have this problem with my MacBook (no AD integration), neither with my home lab nor with any other NETH8.

Here I can connect to all addresses, regardless of IP, “ad.mysrv.tld”, “nsdc-mysrv.mydomain.tld”, “mysrv.mydomain.tld” (the previous file server name), or neth8.interndomain.internal (new; I somehow don’t see the point in using an externally resolvable name for this).

The problem always seems to occur when Kerberos comes into play – if the client tries to use it because it’s connected or is looking for it (printer/scanner).

But let’s see what the additional entry “alternative servicePrincipalName” brings. A “netbios alias” with the previous name was already created by the migration tool.

11

Can you possibly tell me how I can temporarily get Nethserver7 Samba running again (after the migration)? I would like to read its active parameters using “samba-tool” to compare the new and old parameters.

“systemctl -M nsdc start samba” unfortunately fails, even when I enable “nmb” and “winbind.”

Or do I have to revert to an old snapshot to do this?

12

Thank you for the tip.

The existing “servicePrincipalName” shows that there are apparently different ways to create it.

For example, with the prefixes:
“HOST/”
“ldap/”
“GC/”
“RestrictedKrbHost/”
and with quite different suffixes:
“/MYDOMAIN”
“/DomainDnsZones.ad.mydomain.tld”
“/ForestDnsZones.ad.mydomain.tld”
as well as combinations of prefixes and suffixes.

What prefixes/suffixes should I use to create my “servicePrincipalName” mysrv.mydomain.tld so that the behavior is identical to the migrated Nehserver7 (+fileshare)?

On NEthserver7, the domain was: “ad.mydomain.tld”, “MYDOMAIN”
The Nethserver7 file server was: “mysrv.mydomain.tld” or MYSRV.

My guess for the entries to be created would be:
HOST/mysrv.mydomain.tld/ad.mydomain.tld
RestrictedKrbHost/mysrv.mydomain.tld

Correct?

13

I’d like to add something:

I’ve now checked what the “servicePrincipalNames” look like on a very similarly configured and similarly “old” Nethserver 7 AD (not yet migrated).

These are essentially no different from the migrated “servicePrincipalNames” on NETH8 (apart from the different domain name).

The structure is the same, and only “NSDC-MYSRV” and “nsdc-mysrv.ad.mydomain.tld” are present as “RestrictedKrbHosts.”

Accordingly, Nethserver 7 should already deny access via “mysrv.mydomain.tld”?

Why is it only with NETH8 that you have to add additional names?

Is this due to the slightly more recent Samba version, or are there other configuration settings that activate this check?

14

I think you need those with HOST/ prefix, that for your NS7 file server alias become (without nsdc- prefix, IIUC):

servicePrincipalName: HOST/mysrv.ad.mydomain.tld
servicePrincipalName: HOST/mysrv.ad.mydomain.tld/MYDOMAIN
servicePrincipalName: HOST/mysrv.ad.mydomain.tld/ad.mydomain.tld
servicePrincipalName: HOST/MYSRV
15

If you mean that only shares registered by drive letter are listed, that’s not true. Because:

Status       Lokal     Remote                    Netzwerk
OK            \\mysrv.mydomain.tld\SHARENAME     Microsoft Windows
16

It’s explained in nethserver-ns8-migration — NethServer 7 documentation

No, I meant that if you just browse to a share via explorer, it’s not listed. If you for example open a word file on a share, it’s listed.

My intention was to say that Windows could be confused by it’s own connections (listed ones and unlisted ones) to shares which can lead to wrong share tests (they may work after a restart)

17

There are new observations:

When I set the entry for “servicePrincipalName: HOST/MYSRV,” an error message appeared because this entry still existed in AD. After all, this previously belonged to the Nethserver7 file server.

So, I first deleted the MYSRV host entry in the LAM.

This alone changed things: since then, the list of shares opens without a separate login prompt when I access “\mysrv.mydomain.tld” via Explorer.

I still don’t have access to the shares, not even to my own “home.”

After that, I set the entries you recommended, but unfortunately, that didn’t solve the problem.

Furthermore, access is only successful via “nsdc-mysrv.ad.mydomain.tld.”

Even setting entries (which you didn’t mention) for “RestrictedKrbHost/mysrv.mydomain.tld” didn’t work, even after using Samba and restarting Windows.

Setting additional “servicePrincipalName” didn’t solve the problem.

Do you have any other ideas?