After upgrade to UCS 5.0-2 System diagnostic gives me: "Warning: Validating the LDAP configuration and schema files"

UCS - Univention Corporate Server
, , ,
#1

Hi,

today I have upgraded my server from version 4.4-9 to 5.0-2.
The upgrade procces went trough quite smooth and without any major issues.

Nevertheless there is a minior issue left that I cant solve myself. When I run System Diagnostic on the upgraded system, I get this now:

image

This is the according block within the slapd.conf file (line 175 is the last line):

access to attrs=univentionFetchmailPasswd
    by group/univentionGroup/uniqueMember="cn=Domain Admins,cn=groups,dc=my_domain,dc=intranet" write
    by set="user/univentionService & [Fetchmail]" write
    by dn.base="cn=admin,dc=my_domain,dc=intranet" write
    by * +0 stop

Any hint for how to further troubleshoot or fix this, would be much appreciated.

Thx and best regards
Thomas

1 Like
Warning after upgrade to 5.0.2
#2

I am facing the same problem and found that this problem could also be the same: Warning after upgrade to 5.0.2

kind regards

Clemens

#3

Hi,

two more obeservations regarding to this topic here on my test-system:

This is what I get when I run system diagnosatic on a fresh installed UCS-Server (5.0-2):
Screenshot 2022-08-31 110540

And this is what I get right after I have installed “Fetchmail” from the App Center:
Screenshot 2022-08-31 111513

So for me it looks like that something is broken with the Fetchmail-package.

A simple removal (uninstall) of the Fetchmail-package does not fix the System diagnostic.
In order to get it fixed, I need to remove this block from /etc/ldap/slapd.conf:

access to attrs=univentionFetchmailPasswd
    by group/univentionGroup/uniqueMember="cn=Domain Admins,cn=groups,dc=my_domain,dc=intranet" write
    by set="user/univentionService & [Fetchmail]" write
    by dn.base="cn=admin,dc=my_domain,dc=intranet" write
    by * +0 stop

So I’am wondering now how I can get this fixed on my productive Server where Fetchmail is needed.

#4

[EDIT]
Reading it twice makes it more clear:
I guess this is a warning as the last statement (either +0 or none) should refuse access for anyone. And therefore a warning pops up telling you that the rootdn will have access anyways.
So I guess you should ignore this message.

I am absolutely NOT an expert in LDAP ACLs. Even if this line looks pretty fine by syntax I do not really understand meaning of the “+0”. I would try to replaye this by sone more understandable one (which looks like the same, even though I am not sure).

Use
by * none stop
and see if it helps…

In either case your should report it to the Univention team as I have the feeling this is a bug. Isn’t it @Schwardt ?

/KNEBB

#5

Thank you knebb for having a look and your provided feedback!

As advised I have tried to replace by * +0 stop with:

by * none stop and also tried:
by * +0 break

Saddly System diagnostic still fails.

#6

As written in my update:

This is a warning only. Read above why I guess this happens.

You might ignore it.
/KNEBB

#7

Hi!

    by * +0 stop

The LDAP ACLs can define absolute permissions like read, write or none and they can also specify “incremental” permissions, so if a previous ACL specified permissions for accessing an object/attribute, a +r would add read access and keeps all other permissions like write or delete flags. +0 means that no change is done to the permissions…
In this case no previous ACL specified any permissions for the attribute univentionFetchmailPasswd. Therefore the +0 doesn’t do anything and the resulting permission is still none. And now the LDAP server prints a warning^w hint that even if the ACL says none the LDAP superuser still has full access to this attribute.

Currently I would interprete this as a false positive.

Greetings,

Sönke

1 Like
#8

Schwardt, thank you for your detailed explanation!
So what is your proposal for a potential fix?

#9

Moin!

I haven’t investigated here further. It is also possible, that the line before is the culprit:

    by dn.base="cn=admin,dc=my_domain,dc=intranet" write

So that the LDAP server informs us, that even if we define permissions here, the rootdn user (→ cn=admin,dc=my_domain,dc=intranet) will always have unlimited access.

In any case: there is currently no security problem. It’s “only” a false/annoying warning by the diagnostic module.

If you want to experiment (on a test system!):
Try to remove the mentioned line above in /etc/ldap/slapd.conf and restart the LDAP server. If the diagnostics module does not complain any longer, the reason was the superfluous definition of permissions for the rootdn.
To regain the old state of the config file, simply call ucr commit /etc/ldap/slapd.conf and restart the LDAP server.

Greetings,

Sönke

#10

Moin,

Very good analysis :wink:
I have commented out this line on my productive system and now System diagnostic is “green” again.
Can I leave my slapd.conf file like this or will there be any side effects?

#11

I’m not aware of any sideeffects since the LDAP server is effectively ignoring this line.
You can leave your slapd.conf like this but if any UCR variable is updated or a new schema (version) is installed, your slapd.conf gets overwritten and the problematic line is back.

#12

Okay, I will leave slapd.conf as it is now. Thank you for your analysis and feedback!
Is there a chance that someone from the UCS-Staff will fix the Fetchmail-package? That would be great …

#13

I created Bug 55159 – Diagnostic module complains about univention-fetchmail ACLs for this. So you can keep track what the current status is.

1 Like
#14

Great - much appreciated!

#15

Hello,
after Security and bugfix errata for Univention Corporate Server the fix is to manually start:

univention-run-join-scripts --run-scripts --force 92univention-fetchmail-schema

BR,
TP

Warning after upgrade to 5.0.2
#16

Hi,
I can confirm that running the below command is resolving the issue. Thx for the fix!

1 Like
Mastodon