Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Apply network restrictions to LDAP Proxy user

24 views
Skip to first unread message

Peter Kuo

unread,
Nov 21, 2009, 12:52:38 AM11/21/09
to
Since the restriction specifies what address(es) the object CAN log into,
whatever is not listed are disallowed. Since its an LDAP proxy user, you
need to let it have access to all servers' IP addresses that use the same
proxy user.

The restriction applies to the selected object and not service; but of
course if you have other services using that same object ...


--


Peter
eDirectory Rules!
http://www.DreamLAN.com

a...@novell.com

unread,
Nov 21, 2009, 1:09:39 AM11/21/09
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I must be completely missing something. You have a user with a blank
password which is used in your environment as eDirectory's LDAP proxy
user. As a result this user's rights are the ones given to anybody who
connects to LDAP anonymously. While you are okay with completely
anonymous access getting the rights of this user you are not okay with
somebody actually "logging in" with this user and getting the exact same
rights? I just do not understand this.

Good luck.

gmarsh wrote:
> (re-post from OES Client forum)
>
> Implemented LDAP contextless login using an LDAP Proxy user, and that
> is working fine.
>
> Since the LDAP Proxy user has null password, I wish to lock it down in
> some way since anyone who knows or guesses the username can login to the
> directory (not a huge concern but still, want to be thorough).
>
> As far as I can tell from the docs, the only thing I can really do is
> impose network address restrictions on it ("You can limit the locations
> that the user can log in from by setting address restrictions for the
> Proxy User object.")
>
> However, exactly what addr restrictions can / should I impose (such as
> are just the server IPs of the LDAP servers enough?) and especially,
> will imposing the address restriction have impact on any other services?
> Using OES2SP1-Linux and also using NSS clustering if it matters.
>
> Thanks
> GM
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJLB4QjAAoJEF+XTK08PnB5oZ4QALm4CtHQd1F4dNfyAH3ZTjVP
3IWUGwxBHH4pPs+Amegwkl4p/88rMXwj3Tb56AcHrjYu+3FlDbqxVYiZkkcUBfLK
LMRGEE1TRM9imM6xOnKyYxl02UwTcnMUFkmpyAdjO4i0V1ImrD+QHZDrgh+dDQ/4
AsRrhVSTzh+Ml3H9czGpNp/r/c97HQOeZJ7Q06RTqf7CV4CTHhWiWclLM/sWBq4f
ibfpsZPNhh/xEvizGkmnumJ4pStUGzKm4PMenfUm7NujpPl3HwGqu7GVIAgYFxGG
wuX3l7sVIySSc2xBH4d5d06pjvxdn884dtE0dwH0zAUZ/tSIjSNcFXdmoluBg1de
EeDGerBXKSYRzItZ/RwV32RtcfeB1HsqFnAwTNdEHQGoROwOaCXDLlIMpYRKVCrq
X/8bp/swTgGUVzx8t8a0GsSEnfwTMb5rWicN7KFRzj9PdIfIxDKxKNYcn4tD8sg4
uY1f7PLFHybuBcKrqK3zXWq2m77B3glIS3Z6NkByb6kuq/tccx065gj0HxNBe0m6
6bM3O/VafOOr9giprHYbQpAmxzJD/Ww9CeLPsk4XA4//QM6w4uhmblaXqc3jvKNp
BZk7Folv1NBfc5t2SmZNsHjQgrp80Q8FDE3l54/gB5U2lrjJ0j1N9Ovn2EuSe7v1
24ZPOgypaq3pX+Y0p7MU
=NS1Z
-----END PGP SIGNATURE-----

David Gersic

unread,
Nov 21, 2009, 6:07:12 PM11/21/09
to
On Sat, 21 Nov 2009 04:16:01 +0000, gmarsh wrote:

> However, exactly what addr restrictions can / should I impose (such as
> are just the server IPs of the LDAP servers enough?)

That's about all you can do, yes.

> will imposing the address restriction have impact on any other services?
> Using OES2SP1-Linux and also using NSS clustering if it matters.

No idea. I wouldn't think so, but I don't know the OES services well
enough to say for sure.

--
---------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Novell Knowledge Partner http://forums.novell.com

Please post questions in the newsgroups. No support provided via email.

a...@novell.com

unread,
Nov 22, 2009, 11:19:52 PM11/22/09
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As long as you understand the situation, and it sounds like you do, it
sounds okay I suppose. As usual Peter answered the actual question so go
with that. That assumes users will not be able to login via NCP from the
servers themselves as they would then not be affected by the restriction.
You could also just assign [Public] the same rights at the tree root and
bypass the need for a proxy user at all and maybe that is a viable solution.

Sorry for coming across a bit harsh. If I really think you're doing
something really dumb I'll tell it with more than a bit of sarcasm or
disbelief... I have a whole jar of angst for those types of things. :-)

Good luck.

gmarsh wrote:


> a...@novell.com;1893297 Wrote:
>>
>> I must be completely missing something. You have a user with a blank
>> password which is used in your environment as eDirectory's LDAP proxy
>> user. As a result this user's rights are the ones given to anybody
>> who
>> connects to LDAP anonymously. While you are okay with completely
>> anonymous access getting the rights of this user you are not okay with
>> somebody actually "logging in" with this user and getting the exact
>> same
>> rights? I just do not understand this.
>>
>

> Yes you have a great point; however, it's not really about being "ok
> with this" and "not ok with that". I just think it's better to try to
> lock down the "logging in via novell client" than to do nothing at all.
> Customers may query why a user account has to have a null password and
> may complain; better to set the address restrictions on it **as stated
> in the docs** rather than try to explain that a user connecting via LDAP
> can get the same rights, they may scream security hole.
>
> Once address restrictions have been set, at least you can tell the
> customer that NCP login cannot occur with this account! And can also
> point to the docs. Just don't mention the LDAP capability at all.
>
> I think you were being a bit harsh with me there ab; but I thank you
> for your excellent point.


>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJLCg1nAAoJEF+XTK08PnB5bKIP/2bIicLn7TKl56vIqflJtj1Q
BaNPV4tOx8ntT4NqTDuBXDAq+aYcAcnl4jkjTJQywmNk9KarZPeNAb4dcI/mZOY+
ClbHv0DxZ/LfyBBiDkBCHq+cSoTd4ROcaeZhOhs9I1/Q46fwhF8bhCLI9ztkuSGa
AvUwYWXnpODrde/C0c+vXxDBMfbiwri/suzD1kI9+VoHtjfAk9t7J5VgrUj8blfT
Az9Af5eKmHAGKb4WLCPfkP1SGxLkCx47U5EbGhQ6ZDDZuAyUQcJOJDINK0BfJkT8
9+UAhlweJ+aihkMn1z+V8Dr0laBmWZy/OlqiI7Pr8Qi+ifSxotKCCXtro5MPazdg
cuSByCfXundY9+gqtgP7Sx1Vx/oqF5HmxI2QnuWkO3zR4+Be+Vv1pZcghgnYBT2a
KVpnbRCEtCHHX1YnVR6J3M2y38wysoFo1EqAynNptOMBtuylr0reK7uRXmnHT/4C
bBeG22revxG69SlrQPRJk5TrxuKX7JqMiUBhc0NEnP/1yyn75a519tmaRWd+CxnM
+8ddiP2sRBSP11+zN5ZnkBBybdie2in3I7WHg3ARHINjxMbsz086yFEPxvT2I6cE
h9vSAXP5lLNJM3AGE8b8ZgKrbvT8VA/BbncnLvEg4u9EJYPymad4DM7L5rAtbxzR
AxMTnzR1urAdDpmsPvI4
=uDpK
-----END PGP SIGNATURE-----

Peter Kuo

unread,
Nov 23, 2009, 12:53:28 AM11/23/09
to
a...@novell.com wrote:

> I have a whole jar of angst for those types of things.

A jar? JUST A JAR? C'mon ... call a truckload a truckload! <g>

Peter Kuo

unread,
Nov 23, 2009, 12:57:07 AM11/23/09
to
a...@novell.com wrote:

> You could also just assign [Public] the same rights at the tree root and
> bypass the need for a proxy user at all and maybe that is a viable
solution.

Actually, wouldn't you open up a bigger can of worms /if/ the proxy user
has more rights than [Public]?

Peter Kuo

unread,
Nov 23, 2009, 6:18:00 PM11/23/09
to
let's say the proxy user was given additional rights to read the
"IWannebe" attribute of User objects, and if instead of using a proxy but
grant rights to [Public], that means all users (authenticated or not) via
NCP connections will have access to that attribute, plus any object
binding via LDAP (again, anonymous or not) ... if the proxy user is in
place, and if one binds as a non-anonymous user, that binding user will
NOT have access to the "IWannaBe" attribute. Clear as mud? <g>

Peter Kuo

unread,
Nov 23, 2009, 10:49:42 PM11/23/09
to
gmarsh wrote:

> When granting rights to a proxy user, there is a risk that attributes
> can be exposed to non-authenticated connections which would not normally
> be exposed even to authenticated connections.

Exactly, since the bind DNs are different and would result in different
access rights.

And if you forgo the proxy user and assign the same rights to [Public],
then ALL users (either via NCP or LDAP) would gain the same rights; wheres
with the proxy user in place, you only get those rights if you do an
anonymous bind.

David Gersic

unread,
Nov 24, 2009, 9:29:26 AM11/24/09
to
On Sat, 21 Nov 2009 06:09:39 +0000, a...@novell.com wrote:

> I must be completely missing something.

You are. I have this too, and I've _never_ liked it.


> You have a user with a blank
> password which is used in your environment as eDirectory's LDAP proxy
> user. As a result this user's rights are the ones given to anybody who
> connects to LDAP anonymously.

Right. I need this, so that I can control the rights that are given to
eDirectory objects for anonymous LDAP binds. I don't actually want this
user to be used for anything else, like file system access to NetWare (or
OES) servers in the tree. But, because this user has a blank password,
any Windows workstation with Client32 installed could potentially use
this user to log in with, gaining access to file systems.


> While you are okay with completely
> anonymous access getting the rights of this user you are not okay with
> somebody actually "logging in" with this user and getting the exact same
> rights? I just do not understand this.

From the eDirectory only point of view, I'd agree with you. It's the
other Novell services in the tree, like OES file system services, that
can (but should not) be used as well.

I'd be happier if I could put a password on this object, which would then
prevent any random user (I have 20K+ students here...) from using this
User object to log in. That would require a way for the server to read
the password from somewhere (could be done, see how Condrey's stuff works
for examples) so that it could log in with the LDAP Proxy user. Or, if
the proxy user could be defined with _no_ password, then it wouldn't be
allowed to log in, but eDirectory could still use the object to calculate
effective ACL rights in eDirectory.

a...@novell.com

unread,
Nov 24, 2009, 10:26:53 AM11/24/09
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fair enough. Bug# 558044 (enhancement) has been entered. If you are
interested in the feature please e-mail me your e-mail address and I'll
add you to the CC list. By default this entry is, unfortunately, not
visible to the public. Speak to your sales reps to get the bug system
more-open by default.

Good luck.

gmarsh wrote:


> dgersic;1894591 Wrote:
>> Right. I need this, so that I can control the rights that are given to
>> eDirectory objects for anonymous LDAP binds. I don't actually want
>> this
>> user to be used for anything else, like file system access to NetWare
>> (or
>> OES) servers in the tree. But, because this user has a blank password,
>> any Windows workstation with Client32 installed could potentially use
>> this user to log in with, gaining access to file systems.
>>
>

> So the proxy user in the LDAP group object can be limited to the
> address of only its own server (or the list of IPs of the servers in the
> group) because when the anon bind happens via the proxy user, it's
> actually coming from its own server not the workstation that requested
> it. I think that's the way it works - I need to test it - someone
> correct me if wrong - so in theory, it's a good solution because the
> only IP that can do an authenticated connection with that user is the
> server itself, and if a student is doing that, you've got bigger
> problems :-)
>
> My only concern was the possibility that imposing the IP addr
> restriction would break anything else, but unlikely.


>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJLC/s9AAoJEF+XTK08PnB5EMQP/RV1f+KF+sR2MXId8HcjCQ6T
HanO/hujdR62ePKv73tdpCyINRT3uzgPvOqfeOFXfZhAp1cO0X2YVyfTUBQMTuBR
s35GR7W1TVLuEbpq4pjwHP69OCte7M9NfLceb8mk9YmR7CrQ2QB053OlyrIVfASi
RbmBrS/s1DBs/vnp7NLsAcvlH7UOT+oIuWGbKwWu/OLZp9V5X+xRQwMGMVKPDx2g
FCwkck9iN3Ce7D0gvKDaAAWBCTYzeV/70GYBkW8aMTTliouFWLUxO7FGg2iovA/r
E7AxJ5EiOvOhjrVj/IU3hSatj4ftfApy4qqBujcojK0O0aNknHsfo956Fn1RPll8
4KrD3Us9HQjomSsK6Xk5NFM46eRcHRZnMluNRbp39FFD5RVnjkpiDCV+dpOdcXfa
rDsQ+oeDxHpiuAwdSzaTN73Iyq40wW4D9UOxjf6VHAPmPHh9RMUJN5Srl9NbNNuP
g8sijmrcfsDrtwxjGtZEK6/CY5DlJIsEv0SJjhZTgFFqBO08t2pJTrL/TrfgUNwb
vJt8K/YDZu0kPcNoH4tjd0clCbSoSCn2lq+cxGrSamZYpOS2PfwC8BV3FGW6EM2Y
SgludVHwdj64RxFOgjSFrXPvjRLiXa61c4NyaoY8QD3IWNZGR8BdDhCg4X9QOKBn
fEna+Ub3oA+NW7M6yORH
=0hGo
-----END PGP SIGNATURE-----

David Gersic

unread,
Nov 24, 2009, 1:29:26 PM11/24/09
to
On Tue, 24 Nov 2009 15:06:02 +0000, gmarsh wrote:

> dgersic;1894591 Wrote:
>>
>> Right. I need this, so that I can control the rights that are given to
>> eDirectory objects for anonymous LDAP binds. I don't actually want this
>> user to be used for anything else, like file system access to NetWare
>> (or
>> OES) servers in the tree. But, because this user has a blank password,
>> any Windows workstation with Client32 installed could potentially use
>> this user to log in with, gaining access to file systems.
>>
>>

> So the proxy user in the LDAP group object can be limited to the address
> of only its own server (or the list of IPs of the servers in the group)
> because when the anon bind happens via the proxy user, it's actually
> coming from its own server not the workstation that requested it.

Correct. That's exactly what I've done, and it works.

a...@novell.com

unread,
Nov 24, 2009, 1:52:37 PM11/24/09
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

And it probably works as expected as long as you do not have any
NDAP-based services hosted on the server itself doing authentication
(iManager, or the client on the server and remotely accessible for one
reason or another).

Good luck.

David Gersic wrote:
> On Tue, 24 Nov 2009 15:06:02 +0000, gmarsh wrote:
>
>> dgersic;1894591 Wrote:
>>> Right. I need this, so that I can control the rights that are given to
>>> eDirectory objects for anonymous LDAP binds. I don't actually want this
>>> user to be used for anything else, like file system access to NetWare
>>> (or
>>> OES) servers in the tree. But, because this user has a blank password,
>>> any Windows workstation with Client32 installed could potentially use
>>> this user to log in with, gaining access to file systems.
>>>
>>>
>> So the proxy user in the LDAP group object can be limited to the address
>> of only its own server (or the list of IPs of the servers in the group)
>> because when the anon bind happens via the proxy user, it's actually
>> coming from its own server not the workstation that requested it.
>
> Correct. That's exactly what I've done, and it works.
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJLDCt1AAoJEF+XTK08PnB5iCsP/0+cfVOWBanvodyQsMbxC23W
VvdEMUppxFRgEAo+depak90KBij6/HPtqFzjLi4M/O3pDabg6Pg3RHKUIFB9PyZo
9I4p6C0LZpCs/vRMd6cujnRHOn+KQPvP2Ycir1WRtTaVoJFPCU+U5evyfOOd2kP6
AgiSLQxkTaNZOe6zQhTTevPjNiu6r/W4lVzs2JFCD07IblhPnPVQhnl2K63MwaZH
gwTksOxHyxXqbs0N8fWY3aOy3g0c2RVSSRBgBi0ZRGYCvlAY8TC08D5BQwka1xxh
Nr8ZyMWpph7i1kXwh3ZQi2bUvAnvRX/nKUXgMkr5ecaqrneIY/tdbP4OdeZqtwW1
iYe+k58VDa5K0mCNiKuLWmoMs2I6YE+YFQ9S5NxbZLoXArQ3iKXwF49n/bsxSaTC
wLfOEOgM45bqaq9Zu7VGr4todAbpEnO2thdcGx0BAsuqtG0T4FXTXqKT3ZXHP/PT
6+a5MxTqq56As89KjzLBWH3mQskxR6fRolQ5VA2NtZV4MFiGRiP197YFP+SRxdcN
C22mgV1gr/uOVriQgsyMNaNF/NR3nsVJ/IIfg/BC8skonF0SWsjk1Vd8Gm5A8Wr9
dTy92BRktYRR9A7SBc37Vh++sJlwciaS6+pmbrM8XoP2vmTHLSZQeHiOD033sl7P
RYn5NZHVr9WgyawEPQ+g
=wFZv
-----END PGP SIGNATURE-----

0 new messages