You can check if the acl's are correct using ldapsearch  .

This second bind without dn is weird so you need to check from where it come.

Anyway I think is better to have a special user for binding because you can't use the %u if you have multiple organisational units which will occur in the near future for sure :) If somebody have one server will not be happy with only one domain and you will not be happy to put all in the same container.


May 17 07:37:11 ldap0 slapd[262]: conn=1069 op=2 BIND dn="" method=128


On 5/17/23 11:24, Andrzej Milewski wrote:
Hi,
Thank you for your response. What you wrote makes sense, and it was definitely my mistake.
I have made the necessary changes in the settings.
auth_bind_userdn = cn=%u,ou=Users,dc=example,dc=com

I changed the user's cn to u...@example.com.

It appears that there is indeed a specific BIND attempt for this user. However, it does not resolve the issues with olcAccess. If I change the last olcAccess entry from "olcAccess: {10} to * by * read" to "olcAccess: {10} to * by anonymous auth," the anonymous user cannot browse LDAP, but the mail client user also cannot log in.

The LDAP server logs contain the following entries:
May 17 07:37:11 ldap0 slapd[262]: conn=1069 fd=14 ACCEPT from IP=192.168.204.94:45490 <http://192.168.204.94:45490> (IP=0.0.0.0:389 <http://0.0.0.0:389>)
May 17 07:37:11 ldap0 slapd[262]: conn=1069 op=0 BIND dn="" method=128
May 17 07:37:11 ldap0 slapd[262]: conn=1069 op=0 RESULT tag=97 err=0 text=
May 17 07:37:11 ldap0 slapd[262]: conn=1069 op=1 BIND dn="cn=u...@example.com,ou=Users,dc=example,dc=com" method=128 May 17 07:37:11 ldap0 slapd[262]: conn=1069 op=1 BIND dn="cn=u...@example.com,ou=Users,dc=example,dc=com" mech=SIMPLE ssf=0
May 17 07:37:11 ldap0 slapd[262]: conn=1069 op=1 RESULT tag=97 err=0 text=
May 17 07:37:11 ldap0 slapd[262]: conn=1069 op=2 BIND anonymous mech=implicit ssf=0
May 17 07:37:11 ldap0 slapd[262]: conn=1069 op=2 BIND dn="" method=128
May 17 07:37:11 ldap0 slapd[262]: conn=1069 op=2 RESULT tag=97 err=0 text=
May 17 07:37:11 ldap0 slapd[262]: conn=1069 op=3 SRCH base="ou=Users,dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=u...@example.com))" May 17 07:37:11 ldap0 slapd[262]: conn=1069 op=3 SRCH attr=mail homeDirectory uidNumber gidNumber May 17 07:37:11 ldap0 slapd[262]: conn=1069 op=3 SEARCH RESULT tag=101 err=50 nentries=0 text=

The tag 101 corresponds to the search request response operation, and err=50 indicates insufficient access rights. In the logs, we can see the event "BIND anonymous mech=implicit ssf=0," which suggests that Dovecot is attempting to connect anonymously. The same thing happens when I perform such a query using ldapsearch and using the user u...@example.com on the LDAP server console.
In the logs, there is SEARCH RESULT tag=101 err=32 nentries=0 text=.

On Wed, May 17, 2023 at 8:12 AM Mihai Badici <mi...@badici.ro> wrote:

    I think you need also add "by users read" but the problem in this
    setup is to find the user you have a filter so you need to search
    for this .

    So you need either specify a special binding account or the format
    of the biding user

    This is from the default config on debian :


    # For example:
    #   auth_bind_userdn = cn=%u,ou=people,o=org
    #

    On 5/17/23 08:57, Andrzej Milewski wrote:
    Hi,
    I'm trying to set up a production mail server. I have installed
    Dovecot on Debian from the package. For authentication, I have
    another machine running OpenLDAP, also installed on Debian. I
    would like the end mail client to authenticate with Dovecot using
    the login and password set in LDAP.

    In the LDAP-related configuration, I have:
    auth_bind=yes
    base = ou=Users,dc=example,dc=com
    user_attrs =
    
mail=couriermaildir:~/Maildir,homeDirectory=/home/%d/%uid/,uidNumber=uid,gidNumber=gid
    user_filter = (&(objectClass=posixAccount)(uid=%u))
    pass_attrs = uid=user,userPassword=password,\
    pass_filter = (&(objectClass=posixAccount)(uid=%u))

    The LDAP user is entered as uid=u...@example.com. With the
    default olcAccess permissions, it works and logs in correctly.

    Here are my default olcAccess settings after installation:
    # {1}mdb, config
    dn: olcDatabase={1}mdb,cn=config
    objectClass: olcDatabaseConfig
    objectClass: olcMdbConfig
    olcDatabase: {1}mdb
    olcDbDirectory: /var/lib/ldap
    olcSuffix: dc=example,dc=com
    olcAccess: {0}to dn.children="ou=Idmaps,dc=example,dc=com"
    attrs=userPassword,
     shadowLastChange,SambaLMPassword,SambaNTPassword by self write
    by anonymous a
     uth by dn="cn=samba,dc=example,dc=com" write by
    dn="cn=admin,dc=laktopol,dc=p
     l" write by * none
    olcAccess: {1}to dn.subtree="ou=Idmaps,dc=example,dc=com" by self
    write by dn=
     "cn=samba,dc=example,dc=com" write by
    dn="cn=admin,dc=example,dc=com" write b
     y * read
    olcAccess: {2}to dn.children="ou=Hosts,dc=example,dc=com"
    attrs=userPassword,s
     hadowLastChange,SambaLMPassword,SambaNTPassword by self write by
    anonymous au
     th by dn="cn=samba,dc=example,dc=com" write by
    dn="cn=admin,dc=example,dc=com
     " write by * none
    olcAccess: {3}to dn.subtree="ou=Hosts,dc=example,dc=com" by self
    write by dn="
     cn=samba,dc=example,dc=com" write by
    dn="cn=admin,dc=example,dc=com" write by
      * read
    olcAccess: {4}to dn.children="ou=Users,dc=example,dc=com"
    attrs=userPassword,s
     hadowLastChange,SambaLMPassword,SambaNTPassword by self write by
    anonymous au
     th by dn="cn=samba,dc=example,dc=com" write by
    dn="cn=nsspam,dc=laktopol,dc=p
     l" write by dn="cn=admin,dc=example,dc=com" write by * none
    olcAccess: {5}to dn.children="ou=Users,dc=example,dc=com" by self
    write by dn=
     "cn=samba,dc=example,dc=com" write by
    dn="cn=nsspam,dc=example,dc=com" write
     by dn="cn=admin,dc=example,dc=com" write by * read
    olcAccess: {6}to filter=(objectClass=sambaDomain) by
    dn="cn=samba,dc=laktopol,
     dc=pl" write by dn="cn=admin,dc=example,dc=com" write by * read
    olcAccess: {7}to dn.base="dc=example,dc=com" attrs=children by
    dn="cn=samba,dc
     =laktopol,dc=pl" write by dn="cn=admin,dc=example,dc=com" write
    by * read
    olcAccess: {8}to
    attrs=userPassword,shadowLastChange,SambaLMPassword,SambaNTPa
     ssword by self write by anonymous auth by
    dn="cn=nsspam,dc=example,dc=com" wr
     ite by dn="cn=admin,dc=example,dc=com" write by * none
    olcAccess: {9}to attrs=shadowLastChange by self write by * read
    olcAccess: {10} to * by * read

    However, I am not satisfied with these settings because using the
    anonymous user, anyone can browse the entire LDAP tree. While
    passwords are not visible with anonymous login, user data in the
    LDAP domain is exposed.

    If I change the last olcAccess entry from "olcAccess: {10} to *
    by * read" to "olcAccess: {10} to * by anonymous auth," the
    anonymous user cannot browse LDAP, but the mail client user also
    cannot log in.

    What should be the correct configuration?
    --
    Andrzej

    _______________________________________________
    dovecot mailing list --dovecot@dovecot.org
    To unsubscribe send an email todovecot-le...@dovecot.org
    _______________________________________________
    dovecot mailing list -- dovecot@dovecot.org
    To unsubscribe send an email to dovecot-le...@dovecot.org



--
Andrzej

_______________________________________________
dovecot mailing list --dovecot@dovecot.org
To unsubscribe send an email todovecot-le...@dovecot.org
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Reply via email to