LDAP olcAccess for auth_bind
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=user@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 olcAccess: {4}to dn.children="ou=Users,dc=example,dc=com"
- read
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
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=user@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-leave@dovecot.org
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 user@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 (IP=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= user@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= user@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=user@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 user@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 <mihai@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=user@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 olcAccess: {4}to dn.children="ou=Users,dc=example,dc=com"
- read
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 to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
-- Andrzej
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 user@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=user@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=user@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=user@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 user@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 <mihai@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=user@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-leave@dovecot.org_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org-- Andrzej
dovecot mailing list --dovecot@dovecot.org To unsubscribe send an email todovecot-leave@dovecot.org
Hi,
My LDAP server is installed on a Proxmox container using the TurnKey Linux template. I always thought it was a clean Debian installation. I tried it on a fresh Debian installation, and both olcAccess and the LDAP tree differ significantly from what is provided in the template.
I need to practice olcAccess permissions.
Thank you for the tips on configuring the Dovecot bind.
-- Andrzej
On Wed, May 17, 2023 at 11:01 AM Mihai Badici <mihai@badici.ro> wrote:
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 user@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 (IP=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= user@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= user@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=user@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 user@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 <mihai@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=user@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 olcAccess: {4}to dn.children="ou=Users,dc=example,dc=com"
- read
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 to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
-- Andrzej
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
My LDAP server is installed on a Proxmox container using the TurnKey Linux template. I always thought it was a clean Debian installation. I tried it on a fresh Debian installation, and both olcAccess and the LDAP tree differ significantly from what is provided in the template.
I need to practice olcAccess permissions.
Maybe forget about the debian/distro stuff, if you are working with containers anyway. If you use alpine your openldap docker image is (without db) 16MB. My image with el7 was already 305MB.
On 5/21/23 12:42, Marc wrote:
My LDAP server is installed on a Proxmox container using the TurnKey Linux template. I always thought it was a clean Debian installation. I tried it on a fresh Debian installation, and both olcAccess and the LDAP tree differ significantly from what is provided in the template.
I need to practice olcAccess permissions.
Maybe forget about the debian/distro stuff, if you are working with containers anyway. If you use alpine your openldap docker image is (without db) 16MB. My image with el7 was already 305MB.
Proxmox is based on debian and is using LXC containers . But anyway the default ldap install contains only the configuration database, all other databases and organizational units ( and olc's ) are to be added by the admin.
I have some containers with no databases or large files (like proxy or vpn ) on proxmox with 8G disks - using ubuntu ( not my choice :) ) . So the distribution is not so important. and when you talk about few gigs it's peanuts ...
Here are my default olcAccess settings after installation:
don't put samba stuff here, just focus on one application's access.
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.
Is this the default when you install? Pretty terrible still, no wonder everyones data is everywhere. So make sure you firewall your ldap.
But indeed, you should work the other way around start with something no one can access
olcAccess: {0} to dn.exact="" by * read olcAccess: {1} to dn.exact="cn=Subschema" by * read olcAccess: {2} to attrs=userPassword,shadowLastChange by ssf=256 self read by ssf=256 anonymous auth by * none olcAccess: {3} to * by * none
check also these ssf=256, otherwise your data can go over plain connections.
Then test if you can authenticate only over ssl with your ldap entries. Make sure your commandlines work first, does not make sense to look at dovecot at this stage.
ldapsearch -W -s sub -b "uid=test,dc=local" -D "uid=test,dc=local" -H ldap://ldap.local:389/
make sure to increase logging so you can see what dovecot is trying to query on the ldap. Create ldifs to increase/decrease logging and update your acls like this.
ldapadd -D "cn=admin,cn=config" -W -H ldapi:/// -f /home/scripts/inclogging.ldif
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.
If you are not doing this acl stuf to often, it is really annoying
What should be the correct configuration?
Can't remember exactly, this is what I have from trying to create a stateless container with docker. It also depends on your use case. I can't really remember why I have the auth_bind = no, I think it was related to reducing the amount of queries to ldap.
Hi,
I reviewed your guidelines and focused only on how olcAccess works to block anonymous users. I installed a blank native Debian and interestingly, the default Debian rules also allow anonymous reading of the LDAP directory.
olcAccess by Debian olcAccess: {0} to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1} to attrs=shadowLastChange by self write by * read olcAccess: {2} to * by * read
After analyzing everything and testing, I started with two rules that block anonymous users and at the same time grant access to logged-in users. I realize that this is probably not enough and I should include some permissions in this, but this is the initial setting on which I can continue to work.
olcAccess by me olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by anonymous auth by * none olcAccess: {1} to * by self write by users read by anonymous auth by * none
Thank you for your help.
On Wed, May 17, 2023 at 7:57 AM Andrzej Milewski <andrzej.milewski@gmail.com> 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=user@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 olcAccess: {4}to dn.children="ou=Users,dc=example,dc=com"
- read
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
-- Andrzej Milewski andrzej.milewski@gmail.com tel. 0603957324
Hi,
I would like to ask about one more thing regarding LDAP server authentication.
Am I understanding correctly that the auth_bind option, regardless of whether it is set to yes or no, and even if anonymous access to the LDAP directory is blocked, must be used with dn=cn=manager,dc=example,dc=com and dnpass=password to enable authentication?
It seems to me that there are no other cases where Dovecot can query the LDAP server directly using the login and password provided by the client. To perform authentication, it must execute a BIND by an intermediate user, regardless of where the password check takes place - in LDAP or in Dovecot.
Are there any other ways for the client to log in directly with their credentials on the Dovecot server?
On Mon, May 22, 2023 at 1:17 PM Andrzej Milewski <andrzej.milewski@gmail.com> wrote:
Hi,
I reviewed your guidelines and focused only on how olcAccess works to block anonymous users. I installed a blank native Debian and interestingly, the default Debian rules also allow anonymous reading of the LDAP directory.
olcAccess by Debian olcAccess: {0} to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1} to attrs=shadowLastChange by self write by * read olcAccess: {2} to * by * read
After analyzing everything and testing, I started with two rules that block anonymous users and at the same time grant access to logged-in users. I realize that this is probably not enough and I should include some permissions in this, but this is the initial setting on which I can continue to work.
olcAccess by me olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by anonymous auth by * none olcAccess: {1} to * by self write by users read by anonymous auth by * none
Thank you for your help.
On Wed, May 17, 2023 at 7:57 AM Andrzej Milewski < andrzej.milewski@gmail.com> 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=user@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 olcAccess: {4}to dn.children="ou=Users,dc=example,dc=com"
- read
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
-- Andrzej Milewski andrzej.milewski@gmail.com tel. 0603957324
-- Andrzej Milewski andrzej.milewski@gmail.com tel. 0603957324
Am I understanding correctly that the auth_bind option, regardless of whether it is set to yes or no, and even if anonymous access to the LDAP directory is blocked, must be used with dn=cn=manager,dc=example,dc=com and dnpass=password to enable authentication?
Forget about using manager, always create a different entity so you can create acl's specific for this entity and change passwords etc.
cn=dovecot,cn=mail,ou=hosts,dc=example,dc=com
It seems to me that there are no other cases where Dovecot can query the
I think it queries to get file locations (home dir) and maybe searches for uid's so you need something like this
to dn.subtree="ou=mailaccounts,ou=mail,dc=example,dc=com" by ssf=256 dn.exact="cn=dovecot,cn=mail,ou=hosts,dc=example,dc=com" read by ssf=256 self read by anonymous auth by * none
But this is something old that I had and am not using. This allows the cn=dovecot to also access the password field. I am not sure if that is necessary/wanted.
LDAP server directly using the login and password provided by the client. To perform authentication, it must execute a BIND by an intermediate user, regardless of where the password check takes place - in LDAP or in Dovecot.
Are there any other ways for the client to log in directly with their credentials on the Dovecot server?
Yes forget about using ldap in dovecot, and configure ldap for the os and let dovecot authenticate against the os.
Am I understanding correctly that the auth_bind option, regardless of whether it is set to yes or no, and even if anonymous access to the LDAP directory is blocked, must be used with dn=cn=manager,dc=example,dc=com and dnpass=password to enable authentication? Forget about using manager, always create a different entity so you can create acl's specific for this entity and change passwords etc.
cn=dovecot,cn=mail,ou=hosts,dc=example,dc=com
It seems to me that there are no other cases where Dovecot can query the I think it queries to get file locations (home dir) and maybe searches for uid's so you need something like this
to dn.subtree="ou=mailaccounts,ou=mail,dc=example,dc=com" by ssf=256 dn.exact="cn=dovecot,cn=mail,ou=hosts,dc=example,dc=com" read by ssf=256 self read by anonymous auth by * none
But this is something old that I had and am not using. This allows the cn=dovecot to also access the password field. I am not sure if that is necessary/wanted. No it is not necessary and dangerous. That is a setup from the past which mimic the limitations of SQL databases.
LDAP server directly using the login and password provided by the client. To perform authentication, it must execute a BIND by an intermediate user, regardless of where the password check takes place - in LDAP or in Dovecot. No, you're mixing things. You could use flat file user database, or no user database at all with fixed parameters. In this case for the
Le 28/05/2023 à 21:36, Marc a écrit : password database on the LDAP server, the password check will be a simple bind. Yes you should use double bind for the user/password database case and the most flexibility. But you should never directly access or have read access to the password attribute with the dovecot or with the user credential. Not using LDAP bind to check the password defeat most of the LDAP advantages and security. You loose lots of openldap functionality like sasl password forwarding, change password extended operation and others. The double bind will never cause performance problems in your case, and for extreme ops scenario in very very huge setups, you could use Unix socket to locally replicated ldap database and SASL EXTERNAL mechanism for the dovecot bind and normal bind for user password checks.
Are there any other ways for the client to log in directly with their credentials on the Dovecot server?
Yes forget about using ldap in dovecot, and configure ldap for the os and let dovecot authenticate against the os. Don't do that if the users have no shell access to the system, you're opening a worm hole ... And dovecot is more flexible with a LDAP native user and password database. Learn how to properly use LDAP in any case or don't use it. Emmanuel.
But this is something old that I had and am not using. This allows the cn=dovecot to also access the password field. I am not sure if that is necessary/wanted.
LDAP server directly using the login and password provided by the client. To perform authentication, it must execute a BIND by an intermediate user, regardless of where the password check takes place - in LDAP or in Dovecot.
Are there any other ways for the client to log in directly with their credentials on the Dovecot server? Yes forget about using ldap in dovecot, and configure ldap for the os and let dovecot authenticate against the os.
dovecot mailing list --dovecot@dovecot.org To unsubscribe send an email todovecot-leave@dovecot.org
I really got your point, but how you will implement aliases or domain query or maybe quota? You still need to access ldap directly for other info's.
I mean, dovecot can probably use linux login but i'm not sure about the MTA. Unless you have a fixed list of domains added manually.
Anyway, it is not required to use the manager credentials for retrieving users. Can be an user who only have rights to read users ( you need to retrieve the dn for the next bind with this dn and the password provided by user).
participants (4)
-
Andrzej Milewski
-
Emmanuel Fusté
-
Marc
-
Mihai Badici