@stephdl
Do you have a solution?
Thanks
@transocean what do you think
I have had no more problems to date. My suspicion that the problem could be related to the Proxmox server restarting every morning has also proved to be unreal. However, if you want to implement something new, I would be happy to test it.
A restart of proxmox or a restart of a vm is the same for me
If you have no issue it is good for me
No logs no issues no bugs no jobs
@stephdl I would like to know have you made progress in solving the problem?
It would be good to solve the problem because I can’t continue testing the NS8.
Virtual server (VPS) provides a virtualized server to users with various virtualization solutions (KVM, etc.). In the current situation, it is not possible to know when and which service provider can solve the problem.
For the time being, it turned out that everything works properly on a non-virtualized server but I can’t try it because I don’t have a server and the solution would be using VPS.
How can problems be solved?
Thanks for help.
@stephdl I’m still trying to find the cause of the problems, but I can’t fix them because I’m not a developer.
I experienced the following after the last LAM update: when entering LAM configuration, Edit server profiles, the LAM password was reset to the default “lam” and at the same time, after entering, I experienced the following change under Edit server profiles:
The image shows that the Server Address has changed during the update. The previous, correct entry was ldap://accountprovider:20001.
The List of valid users has also changed, the previously specified administrator user has disappeared. However, the entry is missing the CN=Users entry. The correct entry was the following:
By manually changing the settings, both the admin and administrator users can log in to LAM with the password set before the update. This setting and the default LAM password are reset every time the NS8 is restarted.
When I logged into the LDAP Account Manager and checked the domain users, the configured username and email address (ilus.bac@diakont.lan) did not change, but it is still not possible to log in to SOGo with the custom settings, but only with the default username (bacilus).
The reason for this is that the /home/sogo1/.config/templates/sogo.conf.local file was created during the updates to manage the custom configuration, but despite the changes made to this file, the contents of the /home/sogo1/.config/state/sogo.conf file are generated from the default /home/sogo1/.config/templates/sogo.conf and the settings in the /home/sogo1/.config/templates/sogo.conf.local file are ignored when SOGo or NS8 is restarted.
How can the above problems be solved? With such problems, Nethserver 8 cannot be reliably operated as a virtual server on a server farm…
Thanks for your help
I tried many time to reproduce you issues, no clues, sorry
reinstall a new VM and prove with logs what you find, or convince other to test also
@transocean does a restart of the VM make you lost the settings of the LAM ?
Not for me, in my clients or my Home setup.
LAM is on about 10 NS8 clusters.
No issues with LAM.
Works with the set user.
I always use admin for AD. Those using administrator make a fuss about changing the SSH Port, but leave AD to default? Not really consequent! I have not being using administrator on Windows for 24+ years now!
Mes deux centimes
Andy
1 Like
Hi,
in January I installed a new NS8 based on Debian and running on Proxmox.
I configured LAM and SOGo so that the main users can log in with their email address.
It worked until now but today I updated SOGo and from now on no user can log in with either email address or username.
The LAM Server configuration has been overwritten as shown in the image.
Az eredeti beállítások az alábbiak voltak:
I changed the LAM Server settings and checked the LADP settings, but users still can’t log in.
Why is this setting being overwritten and will it ever be fixed or will it remain like this?
Thanks
Any solution?
It’s possible to use custom config files for example for sogo.conf, see also ns8-sogo/README.md at main · NethServer/ns8-sogo · GitHub
Enter as sogo instance user:
runagent -m sogo1
Copy the sogo.conf to the templates dir:
cp ../templates/sogo.conf templates/sogo.conf.local
Edit the sogo.conf.local and adapt it as you explained in NS8 SOGo force login with email address - #47 by steve
nano templates/sogo.conf.local
Restart sogo:
systemctl --user restart sogo
I think the issue was that you had overwritten the sogo.conf file with cron.conf:
@mrmarkuz
Thank you for your answer. Unfortunately, this is not the problem. This was previously fixed by @stephdl and the sogo config files are in fine.
The current problem occurs after every SOGo update. After an update, the LAM module loses its LDAP settings and changes to some unknown default value. This can be seen in the image in the post above, and in the one below, the parameters I previously set.
The current problem occurs after every SOGo update. After the update, the LAM module loses the LDAP settings and changes to some unknown default value. This can be seen in the image in the post above, and in the one below with the parameters I previously set.
I don’t understand why after the SOGo update the Server address in the image is set to ldap://ldap:389, when in the case of NS8 it is Server address ldap://accountprovider:2001.
In this case, only uninstalling and reinstalling the LAM module helps, but then you have to reconfigure it.
Couldn’t this error be fixed? Thanks for the help, I hope someone can solve it…
Unfortunately, I cannot proceed with testing NS8 due to this issue and therefore cannot safely migrate to NS8…
I tried to reproduce the issue without success.
No matter if I update sogo or lam, the config stays the same, the configured lam login users are the same, I can login to lam and to sogo using mail address from mail AD field without issues.
I suspect that you have installed the “latest” version of lam and therefore you don’t get updates, you could check the version in software center.
Please execute the following to update lam to the current 1.0.5 version: (replace lam1 with your lam instance name)
api-cli run update-module --data '{"module_url":"ghcr.io/stephdl/lam:1.0.5","instances":["lam1"],"force":true}'
Unfortunately, I haven’t been able to reproduce this error for anyone else lately.
I have LAM version 1.0.5 installed, it was previously installed with Software Center updates.
I ran the command, it worked for a long time but nothing happened and it ended like this. Still no user can log in to SOGo.
Can you login using the username or isn’t login possible at all?
Please check in LAM if the correct mail address is entered in the correct AD field “mail”.
Please check if sogo.conf.local is correct:
runagent -m sogo1 cat templates/sogo.conf.local
Maybe you also need to update sogo to the current version 2.0.6:
api-cli run update-module --data '{"module_url":"ghcr.io/nethserver/sogo:2.0.6","instances":["sogo1"],"force":true}'
Maybe you misconfigured LAM or added some custom config in the past and never fully removed it.
Remove lam:
remove-module --no-preserve lam1
Install lam:
add-module ghcr.io/stephdl/lam:1.0.5
Is the mail server running and working, can you login for example using Roundcubemail?
@mrmarkuz
Users cannot log in to SOGo or Roundcubemail with either a username or email address.
The sogo.conf.local contains the settings required for logging in with the email address that I configured earlier:
{% if ldap_schema == 'ad' %}
/* 45 AD authentication */
SOGoUserSources =(
{
id = AD_Users;
type = ldap;
CNFieldName = displayName;
IDFieldName = mail;
UIDFieldName = sAMAccountName ;
IMAPLoginFieldName = sAMAccountName;
canAuthenticate = YES;
bindDN = "{{ldap_user}}";
bindPassword = "{{ldap_password}}";
baseDN = "{{ldap_base}}";
bindFields = (
mail
);
hostname = ldap://accountprovider:{{ldap_port}};
filter = "(objectClass='user') AND (sAMAccountType=805306368)";
//MailFieldNames = ("userPrincipalName");
scope = SUB;
displayName = "{{mail_domain}} users";
isAddressBook = NO;
},
/* 50 Web Interface */
SOGoVacationEnabled = YES;
SOGoForwardEnabled = YES;
SOGoSieveScriptsEnabled = YES;
SOGoMailAuxiliaryUserAccountsEnabled = {{auxiliary_account}};
SOGoMailCustomFromEnabled = YES;
SOGoForceIMAPLoginWithEmail = YES;
I ran the SOGo update script but users still can’t log in.
I uninstalled and reinstalled the LAM module from the command line. The LDAP settings are unchanged, but users are still unable to log in to SOGo or Roundcubemail with either their username or email address.
This is what an LDAP entry for one user looks like:
Did you customize Roundcube?
I think there’s an issue with the user domain.
Does it show users?
Let’s check samba status:
runagent -m samba1 systemctl --user status samba-dc --no-pager -l
Please check and share the logs at the times when you try to login with sogo or roundcube. You can do it on the logs page or on CLI as root you can use
journalctl -f
to follow the logs and then try to login to sogo or roundcube.
@mrmarkuz
I did not customize Roundcubemail.
The users are listed under Domain and Users under Users and Groups as shown in the image.
I checked the samba status:
root@debian-ns8:~# runagent -m samba1 systemctl --user status samba-dc --no-pager -l
● samba-dc.service - Samba AD Domain Controller
Loaded: loaded (/home/samba1/.config/systemd/user/samba-dc.service; enabled; preset: enabled)
Active: active (running) since Fri 2025-02-21 23:35:51 CET; 12h ago
Process: 588035 ExecStartPre=/bin/rm -f /run/user/1004/samba-dc.pid /run/user/1004/samba-dc.cid (code=exited, status=0/SUCCESS)
Process: 588036 ExecStartPre=runagent bash -c (echo -n DNS_FORWARDER= ; print-nameservers) > dns_forwarder.env (code=exited, status=0/SUCCESS)
Process: 588040 ExecStart=/usr/bin/podman run --dns=none --no-hosts --detach --conmon-pidfile /run/user/1004/samba-dc.pid --cidfile /run/user/1004/samba-dc.cid --cgroups=no-conmon --network=host --hostname=${HOSTNAME} --replace --name=samba-dc --env=REALM --env=IPADDRESS --env=PREFIXLEN --env=NBDOMAIN --env=SAMBA_LOGLEVEL --env-file=dns_forwarder.env --volume=data:/var/lib/samba:z --volume=config:/etc/samba:z --volume=shares:/srv/shares:z --volume=homes:/srv/homes:z --init ${SAMBA_DC_IMAGE} (code=exited, status=0/SUCCESS)
Process: 588056 ExecStartPost=/usr/bin/bash -c while ! exec 3<>/dev/tcp/${IPADDRESS}/53; do sleep 5 ; done (code=exited, status=0/SUCCESS)
Process: 588140 ExecStartPost=/usr/bin/bash -c while ! exec 3<>/dev/tcp/${IPADDRESS}/88; do sleep 5 ; done (code=exited, status=0/SUCCESS)
Process: 588141 ExecStartPost=/usr/bin/bash -c while ! exec 3<>/dev/tcp/${IPADDRESS}/389; do sleep 5 ; done (code=exited, status=0/SUCCESS)
Process: 588142 ExecStartPost=/usr/bin/bash -c while ! exec 3<>/dev/tcp/${IPADDRESS}/3268; do sleep 5 ; done (code=exited, status=0/SUCCESS)
Main PID: 588052 (conmon)
Tasks: 1 (limit: 4642)
Memory: 11.6M
CPU: 3.888s
CGroup: /user.slice/user-1004.slice/user@1004.service/app.slice/samba-dc.service
└─588052 /usr/bin/conmon --api-version 1 -c 535637441bd349b9b99d14a4509b26c23c6c6b8f2110b883cc88237a6513b991 -u 535637441bd349b9b99d14a4509b26c23c6c6b8f2110b883cc88237a6513b991 -r /usr/bin/crun -b /home/samba1/.local/share/containers/storage/vfs-containers/535637441bd349b9b99d14a4509b26c23c6c6b8f2110b883cc88237a6513b991/userdata -p /run/user/1004/containers/vfs-containers/535637441bd349b9b99d14a4509b26c23c6c6b8f2110b883cc88237a6513b991/userdata/pidfile -n samba-dc --exit-dir /run/user/1004/libpod/tmp/exits --full-attach -s -l journald --log-level warning --runtime-arg --log-format=json --runtime-arg --log --runtime-arg=/run/user/1004/containers/vfs-containers/535637441bd349b9b99d14a4509b26c23c6c6b8f2110b883cc88237a6513b991/userdata/oci-log --conmon-pidfile /run/user/1004/samba-dc.pid --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /home/samba1/.local/share/containers/storage --exit-command-arg --runroot --exit-command-arg /run/user/1004/containers --exit-command-arg --log-level --exit-command-arg warning --exit-command-arg --cgroup-manager --exit-command-arg systemd --exit-command-arg --tmpdir --exit-command-arg /run/user/1004/libpod/tmp --exit-command-arg --network-config-dir --exit-command-arg "" --exit-command-arg --network-backend --exit-command-arg netavark --exit-command-arg --volumepath --exit-command-arg /home/samba1/.local/share/containers/storage/volumes --exit-command-arg --runtime --exit-command-arg crun --exit-command-arg --storage-driver --exit-command-arg vfs --exit-command-arg --events-backend --exit-command-arg journald --exit-command-arg container --exit-command-arg cleanup --exit-command-arg 535637441bd349b9b99d14a4509b26c23c6c6b8f2110b883cc88237a6513b991
Feb 22 11:00:00 debian-ns8 samba-dc[588052]: Auth: [LDAP,simple bind/TLS] user [DIAKONT]\[ldapservice@ad.diakont.lan] at [Sat, 22 Feb 2025 10:00:00.963857 UTC] with [Plaintext] status [NT_STATUS_OK] workstation [DC1] remote host [ipv4:192.168.1.227:58614] became [DIAKONT]\[ldapservice] [S-1-5-21-1555687100-132393895-307515553-1103]. local host [ipv4:192.168.1.227:636]
Feb 22 11:00:01 debian-ns8 samba-dc[588052]: Auth: [LDAP,simple bind/TLS] user [DIAKONT]\[ldapservice@ad.diakont.lan] at [Sat, 22 Feb 2025 10:00:01.031212 UTC] with [Plaintext] status [NT_STATUS_OK] workstation [DC1] remote host [ipv4:192.168.1.227:58630] became [DIAKONT]\[ldapservice] [S-1-5-21-1555687100-132393895-307515553-1103]. local host [ipv4:192.168.1.227:636]
Feb 22 11:10:00 debian-ns8 samba-dc[588052]: Auth: [LDAP,simple bind/TLS] user [DIAKONT]\[ldapservice@ad.diakont.lan] at [Sat, 22 Feb 2025 10:10:00.986307 UTC] with [Plaintext] status [NT_STATUS_OK] workstation [DC1] remote host [ipv4:192.168.1.227:33488] became [DIAKONT]\[ldapservice] [S-1-5-21-1555687100-132393895-307515553-1103]. local host [ipv4:192.168.1.227:636]
Feb 22 11:30:01 debian-ns8 samba-dc[588052]: Auth: [LDAP,simple bind/TLS] user [DIAKONT]\[ldapservice@ad.diakont.lan] at [Sat, 22 Feb 2025 10:30:01.087244 UTC] with [Plaintext] status [NT_STATUS_OK] workstation [DC1] remote host [ipv4:192.168.1.227:60094] became [DIAKONT]\[ldapservice] [S-1-5-21-1555687100-132393895-307515553-1103]. local host [ipv4:192.168.1.227:636]
Feb 22 11:30:01 debian-ns8 samba-dc[588052]: Auth: [LDAP,simple bind/TLS] user [DIAKONT]\[ldapservice@ad.diakont.lan] at [Sat, 22 Feb 2025 10:30:01.419860 UTC] with [Plaintext] status [NT_STATUS_OK] workstation [DC1] remote host [ipv4:192.168.1.227:60098] became [DIAKONT]\[ldapservice] [S-1-5-21-1555687100-132393895-307515553-1103]. local host [ipv4:192.168.1.227:636]
Feb 22 11:45:01 debian-ns8 samba-dc[588052]: Auth: [LDAP,simple bind/TLS] user [DIAKONT]\[ldapservice@ad.diakont.lan] at [Sat, 22 Feb 2025 10:45:01.196751 UTC] with [Plaintext] status [NT_STATUS_OK] workstation [DC1] remote host [ipv4:192.168.1.227:44394] became [DIAKONT]\[ldapservice] [S-1-5-21-1555687100-132393895-307515553-1103]. local host [ipv4:192.168.1.227:636]
Feb 22 12:05:01 debian-ns8 samba-dc[588052]: Auth: [LDAP,simple bind/TLS] user [DIAKONT]\[ldapservice@ad.diakont.lan] at [Sat, 22 Feb 2025 11:05:01.085362 UTC] with [Plaintext] status [NT_STATUS_OK] workstation [DC1] remote host [ipv4:192.168.1.227:46060] became [DIAKONT]\[ldapservice] [S-1-5-21-1555687100-132393895-307515553-1103]. local host [ipv4:192.168.1.227:636]
Feb 22 12:05:01 debian-ns8 samba-dc[588052]: Auth: [LDAP,simple bind/TLS] user [DIAKONT]\[ldapservice@ad.diakont.lan] at [Sat, 22 Feb 2025 11:05:01.492081 UTC] with [Plaintext] status [NT_STATUS_OK] workstation [DC1] remote host [ipv4:192.168.1.227:46064] became [DIAKONT]\[ldapservice] [S-1-5-21-1555687100-132393895-307515553-1103]. local host [ipv4:192.168.1.227:636]
Feb 22 12:09:10 debian-ns8 samba-dc[588052]: Auth: [LDAP,simple bind/TLS] user [DIAKONT]\[ldapservice@ad.diakont.lan] at [Sat, 22 Feb 2025 11:09:10.991584 UTC] with [Plaintext] status [NT_STATUS_OK] workstation [DC1] remote host [ipv4:192.168.1.227:38124] became [DIAKONT]\[ldapservice] [S-1-5-21-1555687100-132393895-307515553-1103]. local host [ipv4:192.168.1.227:636]
Feb 22 12:09:14 debian-ns8 samba-dc[588052]: Auth: [LDAP,simple bind/TLS] user [DIAKONT]\[ldapservice@ad.diakont.lan] at [Sat, 22 Feb 2025 11:09:14.271012 UTC] with [Plaintext] status [NT_STATUS_OK] workstation [DC1] remote host [ipv4:192.168.1.227:38128] became [DIAKONT]\[ldapservice] [S-1-5-21-1555687100-132393895-307515553-1103]. local host [ipv4:192.168.1.227:636]
The following entries appear in the log when the user tries to log in to SOGo:
root@debian-ns8:~# journalctl -f
febr 22 12:16:28 debian-ns8 samba-dc[588052]: Auth: [LDAP,simple bind/TLS] user [DIAKONT]\[ldapservice@ad.diakont.lan] at [Sat, 22 Feb 2025 11:16:28.432118 UTC] with [Plaintext] status [NT_STATUS_OK] workstation [DC1] remote host [ipv4:192.168.1.227:35104] became [DIAKONT]\[ldapservice] [S-1-5-21-1555687100-132393895-307515553-1103]. local host [ipv4:192.168.1.227:636]
febr 22 12:16:28 debian-ns8 ldapproxy[1683]: 2025/02/22 11:16:28 [info] 28#28: *2321 client 127.0.0.1:42268 connected to 127.0.0.1:20001
febr 22 12:16:28 debian-ns8 ldapproxy[1683]: 2025/02/22 11:16:28 [info] 28#28: *2321 proxy 192.168.1.227:35112 connected to 192.168.1.227:636
febr 22 12:16:28 debian-ns8 samba-dc[588052]: Auth: [LDAP,simple bind/TLS] user [DIAKONT]\[cn=bacilus,cn=users,dc=ad,dc=diakont,dc=lan] at [Sat, 22 Feb 2025 11:16:28.480419 UTC] with [Plaintext] status [NT_STATUS_PASSWORD_EXPIRED] workstation [DC1] remote host [ipv4:192.168.1.227:35112] mapped to [DIAKONT]\[bacilus]. local host [ipv4:192.168.1.227:636]
febr 22 12:16:28 debian-ns8 sogo-app[600982]: Feb 22 12:16:28 sogod [103]: <0x0x560e85b5df60[LDAPSource]> <NSException: 0x560e85f6b150> NAME:LDAPException REASON:operation bind failed: Invalid credentials (0x31) INFO:{"error_code" = 49; login = "cn=bacilus,cn=users,dc=ad,dc=diakont,dc=lan"; }
febr 22 12:16:28 debian-ns8 sogo-app[600982]: Feb 22 12:16:28 sogod [103]: SOGoRootPage Login from '192.168.1.2, 10.0.2.100' for user 'ilus.bac@diakont.lan' might not have worked - password policy: 65535 grace: -1 expire: -1 bound: 0
febr 22 12:16:28 debian-ns8 ldapproxy[1683]: 2025/02/22 11:16:28 [info] 28#28: *2321 client disconnected, bytes from/to client:71/101, bytes from/to upstream:101/71
febr 22 12:16:28 debian-ns8 ldapproxy[1683]: 2025/02/22 11:16:28 [info] 28#28: *2319 client disconnected, bytes from/to client:216/300, bytes from/to upstream:300/216
febr 22 12:16:28 debian-ns8 sogo-app[600982]: Feb 22 12:16:28 sogod [103]: 192.168.1.2, 10.0.2.100 "POST /SOGo/connect HTTP/1.1" 403 33/88 0.137 - - 0 - 11
febr 22 12:16:28 debian-ns8 traefik[1661]: 192.168.1.2 - - [22/Feb/2025:11:16:28 +0000] "POST /SOGo/connect HTTP/2.0" 403 33 "-" "-" 3143 "sogo1-https@file" "http://127.0.0.1:20006" 140ms
I’m really glad you’re trying to help, I really appreciate it.
Thank you for your help.
1 Like
I think you missed the samaccountname:
But this doesn’t explain the roundcube issues.
EDIT:
And it seems the password is expired:
@mrmarkuz
Unbelievable! The user’s password has expired. Fortunately, this is a test environment and does not cause any other problems…
The default password policy played a trick on me. I turned it off, it is no longer needed.
Unfortunately, the user cannot log in to Roundcubemail. Maybe Roundcubemail should be customized as well?
In principle, the samaccountname is not necessary, it was not there under NS7 either. I copied that config under NS8 SOGo. Is this necessary?
I hope the world order is restored, I’ll start testing just in case. I’ll write later if everything is okay.
I am very grateful for your patience and help.
Thank you very much for your help.
1 Like