Login fails when VPN connection could not established

Hey everyone,

In our environment we have a UCS-Slave server (IMAP, Postfix eg.), that is connected to the UCS-DC via VPN. Users used to login via IMAP or webinterface. Every now an then, users complain that they could not connect to that server, while the VPN connection isn’t active.

The DC slaves local LDAP is running, and every other daemon seems to be up, except replication fails (of course).

What daemons have to run on such a DC-slave, to make sure that users still can login, even if the VPN connection stalls?

Cheers

Sebastian

Hey,

well, that depends on which service they fail to log in with. You only said that they “cannot connect to that server”. What does that actually mean? Does e.g. Thunderbird show an error message? Can they not open the web interface in their browser? Is logging in to Windows what fails? What’s the actual error message?

Kind regards,
mosu

Hey Mosu,

they simply cannot login via imap clients (lets say: Thunderbird) nor OX Web UI

Cheers
Sebastian

Hey,

again, what does that mean? What is the actual error message?

Kind regards,
mosu

Hey Mosu,

In thunderbird it’s something like “Password is incorrect”. In OX GUI they just can’t see their mails in mail-module anymore. (I don’t want to force this szenario in productive environment, therefore I don’t have the exact error code.)
Afaik the authentification to the imap server is against the ldap, isn’t it?

Cheers

Hey,

okay, thanks. So the users can reach the server, but the server doesn’t seem to be able to reach its LDAP server, which I find somewhat strange. A DC Slave brings its own LDAP server just for situations such as the connection to the DC Master being unavailable. Therefore the applications on the DC Slave should be configured to contact the DC Slave itself.

There are several possibilities that come to mind:

  1. The DNS settings require contacting the DC Master.
  2. The IMAP server is configured to query LDAP server on the DC Master.
  3. The firewall settings only allow connections to the LDAP server on the DC Slave via the VPN interface or something like that.

I consider 2 to be unlikely (BTW: did you install OX from the App Center, or is this a manual installation?).

Can you please verify that 1 isn’t the case? On your DC Slave /etc/resolv.conf should only include the IP of the DC Slave itself, not of the DC Master.

Please also verify that 3 isn’t the case. A starting point would be to disconnect the VPN and look through iptables -L -nv.

Kind regards,
mosu

Hey,

some more things to think about and check:

  1. Do your users use NFS-mounted home directories?
  2. Did you modify the Dovecot configuration on your DC Slave in any way?
  3. Check the uris setting in the file /etc/dovecot/dovecot-ldap.conf.ext. Do they contain anything that isn’t your DC Slave?

Kind regards,
mosu

Hey Mosu,

thank you very much for all the tips.

  1. There are no dns entries pointing to dcmaster
  2. I don’t see any parts in cyrus’s configuration querying dcmaster
  3. There are no specific firewall settings; except that the mandatory ports for the ucs-replication are open
  4. we don’t have any NFS shares
  5. and 6. Unfortunately it’s not a dovecot system ;( it’s a cyrus.

Having Cyrus here brings me to ask: what about cyrus-sasl? Because that is, what the imap users authenticate, isn’t it? I am asking this, because, stopping cyrus-sasl leads to the same error message.

Cheers
Sebastian

Hey,

oh, a Cyrus system? You should really migrate that to Dovecot. I seem to remember from the Univention summit a couple of weeks ago Univention announcing they’d drop support for Cyrus in the upcoming 4.3 release due in March. This may mean that you won’t even be able to upgrade existing systems with Cyrus to 4.3 (though don’t quote me on that — my memory of the exact wording in their announcement is somewhat fuzzy).

Back to the original problem. What’s the output of the following commands:

grep -E '^ldap|sasl' /etc/imapd/imapd.conf
grep -Ev '^#|^$' /etc/default/saslauthd
cat /etc/pam.d/imap
grep uri /etc/pam_ldap.conf

Kind regards,
mosu

Hey Mosu,

on a first glance, everything looks fine to me here:

root@groupware:~# grep -E '^ldap|sasl' /etc/imapd/imapd.conf
sasl_mech_list: PLAIN
sasl_pwcheck_method: saslauthd
sasl_auxprop_plugin: sasldb
sasl_auto_transition: no
ldap_base: dc=some,dc=thing
ldap_host: groupware.some.thing
ldap_port: 7389
ldap_bindpwfile: /etc/cyrus-ldap.secret
ldap_binddn: cn=groupware,cn=dc,cn=computers,dc=some,dc=thing
ldap_to_attr: uid
ldap_from_attr: mailPrimaryAddress
root@groupware:~# grep -Ev '^#|^$' /etc/default/saslauthd
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="pam"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -r -m /var/run/saslauthd -t 1800"
root@groupware:~# cat /etc/pam.d/imap
auth sufficient pam_unix.so
auth requisite pam_univentionmailcyrus.so ldap_host=groupware.some.thing ldap_base=dc=some,dc=thing from_attr=mailPrimaryAddress to_attr=uid binddn=cn=groupware,cn=dc,cn=computers,dc=some,dc=thing  pwfile=/etc/machine.secret ldap_port=7389
auth [success=1 default=ignore] pam_ldap.so use_first_pass
auth [success=ok default=die] pam_krb5.so use_first_pass
auth required pam_runasroot.so program=/usr/sbin/univention-cyrus-set-quota


account sufficient pam_unix.so
account required pam_ldap.so
root@groupware:~# grep uri /etc/pam_ldap.conf
uri ldap://groupware.some.thing:7389

On cyrus, yes, I know! We’d really like get rid of it. There has been an issue migrating shared folders in our test environment, prevents us form dovecot-migration.

Cheers

Sebastian

Hey,

yeah, all of those files look OK to me (assuming that groupware.some.thing is your DC Slave).

The problem might be Kerberos in this case (via PAM: pam_krb5.so). What does the following show:

ucr search --brief '^kerberos'
grep -ri  $(ucr get ldap/master) /etc

My guess is that /etc/krb5.conf is configured to connect to your DC Master. In order to have your local server provide Kerberos, you may have to install the "Active Directory compatible domain controllerand re-configure Kerberos to usegroupware.some.thing` as the KDC (via UCR variables).

Kind regards,
mosu

Yesss. You’ve been right! The kerberos config is the problem. And yes, groupware.some.thing is the slave :slight_smile:

kerberos/kdc: groupware.some.thing
kerberos/kpasswdserver: ucsmaster.some.thing
/etc/ldap/slapd.conf:updateref	ldap://ucsmaster.some.thing:7389
/etc/ldap/sasl2/slapd.conf:saml_trusted_sp6: https://ucsmaster.some.thing/univention/saml/metadata
/etc/ldap/slapd.conf.debian:updateref	ldap://ucsmaster.some.thing:389
/etc/ntp.conf:server ucsmaster.some.thing
/etc/default/ntpdate:NTPSERVERS="ucsmaster.some.thing dcbackup.some.thing ntp1.ptb.de"
/etc/univention/base.conf:hosts/static/192.168.0.11: ucsmaster.some.thing ucsmaster
/etc/univention/base.conf:kerberos/adminserver: ucsmaster.some.thing
/etc/univention/base.conf:kerberos/kpasswdserver: ucsmaster.some.thing
/etc/univention/base.conf:ldap/master: ucsmaster.some.thing
/etc/univention/base.conf:ucs/server/saml-idp-server/ucsmaster.some.thing: ucsmaster.some.thing
/etc/univention/base.conf:umc/saml/trusted/sp/ucsmaster.some.thing: ucsmaster.some.thing
/etc/krb5.conf:	admin_server = ucsmaster.some.thing
/etc/krb5.conf:	kpasswd_server = ucsmaster.some.thing
/etc/hosts:192.168.0.11	ucsmaster.some.thing ucsmaster

So, it is not enough/possible to just set the ucr variable kerberos/kpasswdserver to groupware.some.thing? I am asking, because we still have a samba4 based NT4 Domain in our environment. Means, that we don’t have an active directory compatible domain controller.

Cheers
Sebastian

Hey,

Oink, that’s… Huh… Well… :slight_smile: I actually cannot answer that as I don’t know how Kerberos works wrt. an NT-style domain. I highly suggest you migrate your setup to an AD domain — not just due to Kerberos, but also because the upcoming 4.3 release will drop support for NT-style domains, too, if I remember correctly. What’s stopping you, if I may ask?

Kind regards,
mosu

Well, what’s stopping us I described here:

https://help.univention.com/t/idmap-in-samba3-samba4-environment/7360

Cheers
Sebastian

Hey,

I see. However, you won’t be able to keep using your NT-style domain indefinitely, and problems such as this one make it all the more urgent.

About your idmap issue: do the files have correct owners & groups at the moment? If so you could look into using getfacl before the migration for dumping the ACLs & owner information into a text file and using setfacl after the migration for restoring the owner. That might work as getfacl stores the user/group names instead of their numeric IDs. if the IDs change but the names stay stable during the migration, using the information from getfacl afterwards should work.

However, let’s discuss that in a separate thread.

Kind regards,
mosu

Hey Mosu,

thank you very much for your message. I suggest, we go on to the original idmap thread.

Cheers Sebastian

Mastodon