Trust Relationship between two Samba4 DC

UCS - Univention Corporate Server
,
#1

Hello,

First of all, excuse my English, I am French …
I allow myself to write on your forum but I do not use UCS.

I need to create a trust relationship between two Samba4 domain controllers hosted on Ubuntu Server 16.04.2 LTS.

Overall, it works. But what disrupts me is that when I do my order to create the trust relationship, frequently I have these two errors that appear:

Smb_signing_good: BAD SIG: seq 1
ERROR: REMOTE_DC [pdc.sc.local]: failed to connect lsa server -
ERROR (0xC0000022) - Access denied

Smb_signing_good: BAD SIG: seq 1
ERROR: REMOTE_DC [pdc.sc.local]: failed to connect netlogon server -
ERROR (0xC0000022) - Access denied

This is how I do it:

  • on / etc / network / interfaces -> dns-nameservers

  • on the server A, I add ip address of the server B on forwarder
    /etc/bind/named.conf.options

  • and I make this command: / usr / local / samba / bin / samba-tool domain trust
    Create domainB -U Administrator @ domainB% password --type = external
    –direction = both --create-location = both --skip-validation

Do you have an idea to avoid this failures?

Thanks a lot!

#2

Hi Julien,

I’m not an expert about questions regarding Ubuntu, so I can only give you my 2¢ from the perspective of a practitioning Samba debugger. I’d recommend asking the samba users mailing list and supplying the smb.conf of both domain DCs. Without that basic info, people will have no way to give you qualified feedback. In my experience, the process of gathering the information required to precisely describe the environment and the steps to reproduce the issue is very helpful in suddenly recognizing the cause of the problem. But I’m sure you know that. Now, the first question, that providing the smb.conf would help answering, is, between what kind of domains your are trying to establish a trust: NT4 or AD? I could imagine that the samba-tool is more suited for AD domains and might have issues with NT4 domains (a quick search on the mailinglists suggest that). Next, I would have a very close look at the verbatim error messages. Usually, when I debug a problem and find the solution in the end I discover that the error message actually said it all, I just didn’t know the context to understand it. Let’s take the first line “Smb_signing_good: BAD SIG”. My educated guess is that SMB signing fails. So this is very basic connectivity stuff and that tells you, that the trust your tried to create probably is no where close to been properly set up. The next error messages “failed to connect las/netlogon server” tell you that authentication could not even be attempted and as a result you get “Access denied”. From the few information you provided, I’d check two things:

  1. Can both DCs resolve the FQDNs of the other? Also check that basic network stuff works, before creating the trust. Like: try an smbclient connection from one DC to the other (e.g. as Administrator), but without any trust. That stuff needs to work, otherwise trust will most probably not work either.

  2. The use of the option --skip-validation is tempting, I know, but it may also hide issues. Strictly speaking: If the trust cannot be validated, then it’s probably not working in the end either.

That’s all I can say currently. If you find out the solution, feel free to add a comment or a link here, that might help others too, regardless of the specific Linux distribution.

1 Like
Mastodon