How to control the BIND operation using ACI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

   Thank you very much for the URLs. This will help me to control users of
which group can authenticate using ldap and go through proxy. I will
follow this approach.

   Still there is the case where if the squid proxy server is administered
by some other people, they can bypass this restriction as instead of
defining filters for ldap operation, they can simply use BIND operation
to get authenticated. This can never be controlled at the LDAP server
level. For that matter this can be used by any application to bypass
group level control.

regards
murthy
> As far as i can see making a quick google search squid can do
> authorisation using ldap filters and groups; for example, look at this
> page :
> http://linux.com.hk/penguin/man/8/squid_ldap_group.html
>
> or here :
> http://linux.die.net/man/8/squid_ldap_auth
>
>
> 2008/5/10  <murthy at barc.gov.in>:
>> Hi,
>>  Thanks for the confirmation. . Applications like squid are not doing
>> any
>>  read/search/compare to verify authentication, but simply doing BIND
>>  operation.I think the directory server may incorporate some form of
>> BIND
>>  control feature
>>
>>  regards
>>  murthy
>>
>>
>> > Yes, i think that there is no way to deny a BIND depending on the
>>  > group and originating IP condition. You can however deny any other
>>  > access (read/compare/search). Depending on the filter you define for
>>  > squid/sendmail/php web page (even the simplest objectClass=*)  these
>>  > conditions are equivalent (the ldapsearch will bind but it will
>> always
>>  > return an empty set)...
>>  >
>>  >
>>  > 2008/5/9 C.S.R.C.Murthy <murthy at barc.gov.in>:
>>  >> Hi Andrey,
>>  >>   As I first step, according to your  suggestion, I have removed the
>>  >> default
>>  >> ACIs for anonymous and authenticated users. With this I expected
>> that
>>  >> squid
>>  >> will not be able to BIND to the directory server as the default ACI
>>  >> action
>>  >> should be DENY in case there is no matching rule. But it is able to
>>  >> successfully BIND when I give proper login/password. If I am not
>> able to
>>  >> deny BIND operation when there are no anonymous/authenticated ACI,
>> then
>>  >> I
>>  >> will never be able to control BIND access, I assume. Please clarify.
>>  >>
>>  >>
>>  >>
>>  >>  regards
>>  >>  murthy
>>  >>
>>  >>  Andrey Ivanov wrote:
>>  >>
>>  >> > Anyway it is better to make the "allow" ACIs, not "deny" ACIs.
>>  >> >
>>  >> > As for your problem, here is what the ACIs should look like
>> (supposing
>>  >> > that your groups are cn=INTERNET,ou=Groups,dc=example,dc=com and
>>  >> > cn=EMAIL,ou=Groups,dc=example,dc=com, ip adresses of your squid
>> server
>>  >> > are 192.168.0.66 and 172.16.191.66, adresses of your email servers
>>  >> > 192.168.1.100 and 192.168.1.101)
>>  >> >
>>  >> > Delete all the default ACIs (for anonymous/authentified users) and
>>  >> > choose the attributes that you want to expose (attr1,  attr2...)
>>  >> >
>>  >> > For INTERNET group :
>>  >> > aci: (targetattr = "attr1 || attr2")(version 3.0; acl "Enable
>>  >> > attributes to read for a certain ip adresses and to authentified
>>  >> > users";allow (read,search,compare)(((ip="192.168.0.66") or
>>  >> > (ip="172.16.191.66")) and (groupdn =
>>  >> > "ldap:///cn=INTERNET,ou=Groups,dc=example,dc=com";));)
>>  >> >
>>  >> >
>>  >> > For EMAIL group :
>>  >> > aci: (targetattr = "attr1 || attr2")(version 3.0; acl "Enable
>>  >> > attributes to read for a certain ip adresses and to authentified
>>  >> > users";allow (read,search,compare)(((ip="192.168.1.100") or
>>  >> > (ip="192.168.1.101")) and (groupdn =
>>  >> > "ldap:///cn=EMAIL,ou=Groups,dc=example,dc=com";));)
>>  >> >
>>  >> > 2008/5/9 C.S.R.C.Murthy <murthy at barc.gov.in>:
>>  >> >
>>  >> >
>>  >> > > Dear Andrey,
>>  >> > >  I did not make clear one point here. My exact ACI requirement
>> is
>>  >> like
>>  >> > > this, I need to deny bind operation when the connecting DN
>> belongs
>>  >> to
>>  >> > > certain group and the request is coming from certain ip address.
>> How
>>  >> to
>>  >> do
>>  >> > > it in ACI?. More specifically we have one INTERNET group and one
>>  >> EMAIL
>>  >> > > group. If a person is in INTERNET group he will be allowed to
>>  >> authenticate
>>  >> > > (BIND) only from squid proxy server  Simillarly if a person
>> belongs
>>  >> to
>>  >> EMAIL
>>  >> > > grooup he will be allowed to authenticate (BIND) only from email
>>  >> server.
>>  >> We
>>  >> > > are unable to acheive this type of control using ACI. Please
>> help.
>>  >> > >
>>  >> > > regards
>>  >> > > murthy
>>  >> > >
>>  >> > > Andrey Ivanov wrote:
>>  >> > >
>>  >> > >
>>  >> > > > You can do it like this, for example :
>>  >> > > >
>>  >> > > > ----------------------------------
>>  >> > > > aci: (targetattr = "uniqueMember || uidNumber || gidNumber ||
>>  >> > > > homeDirectory ||  loginShell || gecos")(version 3.0; acl
>> "Enable
>>  >> > > > attributes to read for certain ip adresses and to authentified
>>  >> users";
>>  >> > > > allow (read,search,compare)(((ip="192.168.0.*") or
>>  >> (ip="172.16.191.*
>>  >> > > > ") or (ip="192.168.1.15") or (ip="172.16.126.1")) and
>>  >> > > > (userdn="ldap:///all";));)
>>  >> > > > ------------------------------------
>>  >> > > > Or you can simply use iptables...
>>  >> > > >
>>  >> > > >
>>  >> > > > 2008/5/8 C.S.R.C.Murthy <murthy at barc.gov.in>:
>>  >> > > >
>>  >> > > >
>>  >> > > >
>>  >> > > > > Hello all,
>>  >> > > > >  Iam using directory server for squid ldap authentication.
>> Squid
>>  >> takes
>>  >> > > > > username/password, binds the directory server and if the
>> BIND
>>  >> operation
>>  >> > > > > is
>>  >> > > > > successful it allows the user through proxy. My problem is
>> how
>>  >> to
>>  >> specify
>>  >> > > > > an
>>  >> > > > > ACI so that BIND operation is allowed only from certain IP
>>  >> address?.
>>  >> ACI
>>  >> > > > > allows me to restrict READ/SEARCH/WRITE operations but not
>> BIND
>>  >> > > > > operation.
>>  >
>>
>>
>> > --
>>  > Fedora-directory-users mailing list
>>  > Fedora-directory-users at redhat.com
>>  > https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>  >
>>
>>
>>  --
>>  Fedora-directory-users mailing list
>>  Fedora-directory-users at redhat.com
>>  https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>





[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux