Hey,
so far this looks fine to me. Some more tests, please:
lsof -PniTCP:88 -sTCP:LISTENiptables -L INPUT -nv | grep -E ':88|policy'host popmail.t-online.deAnother thing: does fetchmail always output this message? Or was that maybe a one-off error?
Kind regards,
mosu
@Moritz_Bunkus can the problem be related with trustdom?
I’m digging some errors and in event viewer and some google let me to this command
root@CCMDC01:~# net rpc trustdom list
Unable to find a suitable server for domain CCM
Couldn't connect to domain controller: NT_STATUS_UNSUCCESSFUL
root@CCMDC01:~# net -d3 rpc trustdom establish ccmdc01
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[global]"
Registered MSG_REQ_POOL_USAGE
Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[global]"
added interface lo ip=::1 bcast= netmask=ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
added interface lo ip=127.0.0.1 bcast=127.255.255.255 netmask=255.0.0.0
added interface eth0 ip=192.168.120.2 bcast=192.168.120.255 netmask=255.255.255.0
interpret_string_addr_internal: getaddrinfo failed for name eth0_0 (flags 32) [Name or service not known]
interpret_interface: Can't find address for eth0_0
interpret_string_addr_internal: getaddrinfo failed for name eth0_1 (flags 32) [Name or service not known]
interpret_interface: Can't find address for eth0_1
name_resolve_bcast: Attempting broadcast lookup for name CCMDC01<0x1b>
Couldn't find domain controller for domain CCMDC01
return code = -1
root@CCMDC01:~#
@Jochen77 can you run the same commands to check the outputs?
Here is the output:
sudo lsof -PniTCP:88 -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
samba 21873 root 24u IPv6 144071 0t0 TCP [::1]:88 (LISTEN)
samba 21873 root 34u IPv4 144075 0t0 TCP 127.0.0.1:88 (LISTEN)
samba 21873 root 38u IPv4 144079 0t0 TCP 192.168.76.200:88 (LISTEN)
sudo iptables -L INPUT -nv | grep -E ':88|policy'
Chain INPUT (policy DROP 0 packets, 0 bytes)
589 30960 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:88
13 3315 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:88
host popmail.t-online.de
popmail.t-online.de has address 194.25.134.51
popmail.t-online.de has address 194.25.134.114
popmail.t-online.de has address 194.25.134.115
popmail.t-online.de has address 194.25.134.50
net rpc trustdom list
Enter Administrator's password:
Trusted domains list:
none
Trusting domains list:
none
@Moritz_Bunkus but i also cannot connect to RDP server members…
I’m able to connect to one server (windows 2008) but i cannot connect to other server (windows 2016), both in same network, and same domain…
The fetchmail problem might be on/off:
now i found the following line in mail.err:
Apr 5 11:01:29 ucs fetchmail[17292]: Authentifikationsfehlschlag bei buero@xxx.de@popmail.t-online.de (vormals autorisiert)
Apr 5 11:01:32 ucs fetchmail[17292]: Authentifikationsfehlschlag bei werkstatt@xxx.de@popmail.t-online.de (vormals autorisiert)
Here is the screenshot form the webgui:
It is strange.
Because the W7 Client wasn’t reachable by RDP i powered it down this morning. Then i looked after the file right issue in the picture above and chaned the folder to the expected 750. To run the Systemdiagnose again i started the client and now i could login local and with RDP. Nothing else changed. I will test it again in a few hours and give a report.
Kind regards
Jochen
O.K. just a short pleasure.
The second time i tried to log in the same behaviour. “Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar.”
And after ater a few minutes the RDP session closes.
Kind regrads
Jochen
Hi there,
I’ve had exactly the same issue. Solved reproducably by the following steps for anyone who is interested:
cat /etc/samba/local.conf
[global]
map untrusted to domain = yes
Side note: Running on 4.3-0 errata11, was a 4.2 before.
Side note 2: This also solved in this forum reported Windows Server 2012 issues with upgraded 4.3 instances which could not access shares correctly anymore.
And you will be a happy puppy with uber-fast connections to RDP and CIFS shares again.
Have fun.
- mike
Hey,
reading the smb.conf man page for map untrusted to domain explains very well why this may help. However, the last paragraphs also state that this is not a long-term solution:
“map untrusted to domain = auto” was added and become the default with Samba 4.7.0. As the option is marked as deprecated it will be removed in a future release, while the behavior of “map untrusted to domain = auto” will be kept.
“auto” is what seems to be slow in Samba 4.7. So here’s to hoping the Samba developers can either do something about the big delays with “auto”, or they reconsider removing the option altogether.
Kind regards,
mosu
Hello,
I trieded these solutien and it works fine.
Thank you very much.
I’m sorry but i have to come back to you because the problem is here again.
The solution “map untrusted to daomain = yes” worked for a while but the problem is back again. This moring the same issue: LSA is not available.
When i restart the samba-ac-dc service a login is possible for a while but not stady.
Any other ideas?
Kind regards Jochen
@Moritz_Bunkus: Totally agree.
@Jochen77: The only other difference I’ve made was setting ucr set samba/ntlm/auth=yes which effectively sets NTLM1 to be permitted as well. Maybe worth a try?
@Moritz_Bunkus: What I find quite disturbing as of yet is still though that there seems to be close to 0 from Univention directly and by the mere number of posts regarding this special topic I think there really should be at least some sort of reaction. While it is true that samba made this changes I personally would have expected a bit more QA or at least reaction in this topic. Not wanting to rant at all, I know a lot of Univention guys and they’re really great (I mean it with every word) I still find it a bit disturbing nothing happens in these cases for weeks now. 
… Well, whatever it be: Let’s hope they’ll find a solution to these problems as well.
ref: UCS 4.3 Samba 4.7 - Probleme beim Authentizieren (war: Änderungen bei NTLM?)
ref: Windows Fileserveranmeldung nach UCS Update auf 4.3 nicht möglich
I’m just happy I could at least solve my issues by the solutions I’ve posted. Wish you good luck alltogether!
100% agreement!
And the worst part about it, they messed things up with the upgrade and want me to pay for support to fix it. 
Comparing the Kopano support with the Univention support is like comparing black to white.
It is more than embarrassing that a Kopano employee is now taking care of possible bug fixes for a Univention product.
But, tyvm, @mkromer . Way to go!
Maybe Univention can learn from it.
We are currently checking the issue and will report our results.
Hello,
just a short feedback. I run the
ucr set samba/ntlm/auth=yes
2 days ago. Now it seems to run clear now.
Kind regards.
Jochen
Ok, it looks like the firewall of the UCS 4.3 Samba/AD DCs is blocking TCP ports dynamically allocated by Samba 4.7. In our lab we found that the following adjustment fixed the issue:
ucr set \
security/packetfilter/package/univention-samba4/tcp/49152:65535/all="ACCEPT" \
security/packetfilter/package/univention-samba4/tcp/49152:65535/all/en="Dynamic RPC Ports (Samba)"
ucr unset \
security/packetfilter/package/univention-samba4/tcp/49152/all \
security/packetfilter/package/univention-samba4/tcp/49152/all/en
service univention-firewall restart
Please note that this needs to be adjusted on all UCS 4.3 Samba/AD DCs.
We will also prepare an errata update to address this.