RE: LDAP olcAccess for auth_bind
> >> > >> I really got your point, but how you will implement aliases > > has nothing to do with dovecot, sendmail can get those from ldap. > > > >> or domain > > sendmail gets these from ldap (but requires a restart) > > > >> query or maybe quota? You still need to access ldap directly for > other > >> info's. > > quotas can be/are distributed to the os by ldap. But it depends a bit > on your setup, and if you have multiple file systems. > > > >> 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. > >> > > I have on different servers cron jobs running, getting every 5?min > modified/created records and then do a restart or something else. All > these processes have own entity in ldap with own acls. > > sendmail can get anything you want from ldap. For outgoing mail auth, > I have sendmail use os users (which come from ldap) > > > So in the end you still access ldap from another program but not from > dovecot :) I don't get your point. The goal for using ldap is having a centralized database that distributes information. How you choose to implement this, is depending on your requirements. > You avoid to authenticate users directly only to send the credentials of > some privilleged user from postfix/sendmail/whatever script... > Not to avoid. Other applications have different needs and thus different acl's. Dovecot does not need to know a users email address or alias. Only the MTA needs to know. The relaying MTA does not need to know the user etc. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: LDAP olcAccess for auth_bind
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-le...@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). ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: LDAP olcAccess for auth_bind
Le 28/05/2023 à 21:36, Marc a écrit : 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 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. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
RE: LDAP olcAccess for auth_bind
> > 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. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: LDAP olcAccess for auth_bind
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
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.milew...@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=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
Re: LDAP olcAccess for auth_bind
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
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
>
--
Andrzej Milewski
andrzej.milew...@gmail.com
tel. 0603957324
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: LDAP olcAccess for auth_bind
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 ... ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
RE: LDAP olcAccess for auth_bind
> > 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. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: LDAP olcAccess for auth_bind
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 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 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 (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=
> 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 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"
>>
Re: LDAP olcAccess for auth_bind
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 (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=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 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"
Re: LDAP olcAccess for auth_bind
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 (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=
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 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
RE: LDAP olcAccess for auth_bind
> 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.
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: LDAP olcAccess for auth_bind
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
