| Author |
Message |
Guest
|
Posted:
Sat Oct 15, 2005 6:20 am Post subject:
Access Control to LDAP on AD? |
|
|
Is there a way to block certain user accounts from performing LDAP queries
on Active Directory?
If anyone could let me know I would be most appreciative. |
|
| Back to top |
|
 |
Roger Abell [MVP]
Guest
|
Posted:
Sat Oct 15, 2005 8:50 am Post subject:
Re: Access Control to LDAP on AD? |
|
|
I believe you can not realistically do that as an account will at times
be issuing Ldap queries, behind the scenes, sometimes against
the GCs, just to function as a domain client. Also, not all Ldap
queries are authenticated queries so if your objective is to
avoid a potential DoS from malicious queries they may try to
side-step your efforts using unauthenticated binds if they are
allowed to communicate with the ldap and gc ldap ports.
--
Roger Abell
Microsoft MVP (Windows Server : Security)
MCDBA, MCSE W2k3+W2k+Nt4
<-> wrote in message news:uL$IzaS0FHA.3188@TK2MSFTNGP14.phx.gbl...
| Quote: | Is there a way to block certain user accounts from performing LDAP queries
on Active Directory?
If anyone could let me know I would be most appreciative.
|
|
|
| Back to top |
|
 |
Guest
|
Posted:
Mon Oct 17, 2005 8:51 pm Post subject:
Re: Access Control to LDAP on AD? |
|
|
So, there's no solution?
"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:Odue6pU0FHA.2008@TK2MSFTNGP10.phx.gbl...
| Quote: | I believe you can not realistically do that as an account will at times
be issuing Ldap queries, behind the scenes, sometimes against
the GCs, just to function as a domain client. Also, not all Ldap
queries are authenticated queries so if your objective is to
avoid a potential DoS from malicious queries they may try to
side-step your efforts using unauthenticated binds if they are
allowed to communicate with the ldap and gc ldap ports.
--
Roger Abell
Microsoft MVP (Windows Server : Security)
MCDBA, MCSE W2k3+W2k+Nt4
-> wrote in message news:uL$IzaS0FHA.3188@TK2MSFTNGP14.phx.gbl...
Is there a way to block certain user accounts from performing LDAP
queries on Active Directory?
If anyone could let me know I would be most appreciative.
|
|
|
| Back to top |
|
 |
Guest
|
Posted:
Tue Oct 18, 2005 4:51 pm Post subject:
Re: Access Control to LDAP on AD? |
|
|
Apparently not. So someone writing a rogue LDAP query can bring down and
domain or enterprise with no ability to stop them. Great.
<-> wrote in message news:ue2Ppy00FHA.2924@TK2MSFTNGP15.phx.gbl...
| Quote: | So, there's no solution?
"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:Odue6pU0FHA.2008@TK2MSFTNGP10.phx.gbl...
I believe you can not realistically do that as an account will at times
be issuing Ldap queries, behind the scenes, sometimes against
the GCs, just to function as a domain client. Also, not all Ldap
queries are authenticated queries so if your objective is to
avoid a potential DoS from malicious queries they may try to
side-step your efforts using unauthenticated binds if they are
allowed to communicate with the ldap and gc ldap ports.
--
Roger Abell
Microsoft MVP (Windows Server : Security)
MCDBA, MCSE W2k3+W2k+Nt4
-> wrote in message news:uL$IzaS0FHA.3188@TK2MSFTNGP14.phx.gbl...
Is there a way to block certain user accounts from performing LDAP
queries on Active Directory?
If anyone could let me know I would be most appreciative.
|
|
|
| Back to top |
|
 |
Joe Kaplan (MVP - ADSI)
Guest
|
Posted:
Tue Oct 18, 2005 8:51 pm Post subject:
Re: Access Control to LDAP on AD? |
|
|
There are also query policies that are already in place that help mitigate
DOS attacks via LDAP. It is possible to tighten these up even further
(limiting the number of query query threads, shortening time outs, etc.).
My experience is that people are more likely to do things to increase their
risk of DOS attack with these and decrease it (increasing maxPageSize and
query timeouts comes to mind), but they can go either way.
It may also be possible to severely limit the objects a normal user in the
domain can find via a search. The trick here is to make sure that it is not
so tightened down that the user no longer functions.
The original poster never explained their goal here, so it wasn't clear what
the right answer should be.
Joe K.
"Alun Jones" <alun@texis.invalid> wrote in message
news:NIedneASk79-q8jeRVn-vA@comcast.com...
| Quote: | Denial of Service is always a possibility. Consider someone simply firing
off connections - the classic SYN attack - to overload your LDAP server.
Yes, that will cause your LDAP server to become unreliable, in the
strictest sense that sometimes it will respond to requests, and other
times it will be unable to do so.
As for "no ability to stop them", that's going rather far. All ("all")
you have to do is monitor your network for suspicious behaviour, track
down the perpetrator, and then march over there with a couple of security
and HR personnel so that you can fire his arse for breaching your
corporate security policy. You do have a corporate security policy, don't
you? You do have an IDS in place to monitor rogue traffic, yes?
Alun.
~~~~
-> wrote in message news:O0HQAX$0FHA.1256@TK2MSFTNGP09.phx.gbl...
Apparently not. So someone writing a rogue LDAP query can bring down and
domain or enterprise with no ability to stop them. Great.
-> wrote in message news:ue2Ppy00FHA.2924@TK2MSFTNGP15.phx.gbl...
So, there's no solution?
"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:Odue6pU0FHA.2008@TK2MSFTNGP10.phx.gbl...
I believe you can not realistically do that as an account will at times
be issuing Ldap queries, behind the scenes, sometimes against
the GCs, just to function as a domain client. Also, not all Ldap
queries are authenticated queries so if your objective is to
avoid a potential DoS from malicious queries they may try to
side-step your efforts using unauthenticated binds if they are
allowed to communicate with the ldap and gc ldap ports.
--
Roger Abell
Microsoft MVP (Windows Server : Security)
MCDBA, MCSE W2k3+W2k+Nt4
-> wrote in message news:uL$IzaS0FHA.3188@TK2MSFTNGP14.phx.gbl...
Is there a way to block certain user accounts from performing LDAP
queries on Active Directory?
If anyone could let me know I would be most appreciative.
|
|
|
| Back to top |
|
 |
Alun Jones
Guest
|
Posted:
Tue Oct 18, 2005 8:51 pm Post subject:
Re: Access Control to LDAP on AD? |
|
|
Denial of Service is always a possibility. Consider someone simply firing
off connections - the classic SYN attack - to overload your LDAP server.
Yes, that will cause your LDAP server to become unreliable, in the strictest
sense that sometimes it will respond to requests, and other times it will be
unable to do so.
As for "no ability to stop them", that's going rather far. All ("all") you
have to do is monitor your network for suspicious behaviour, track down the
perpetrator, and then march over there with a couple of security and HR
personnel so that you can fire his arse for breaching your corporate
security policy. You do have a corporate security policy, don't you? You
do have an IDS in place to monitor rogue traffic, yes?
Alun.
~~~~
<-> wrote in message news:O0HQAX$0FHA.1256@TK2MSFTNGP09.phx.gbl...
| Quote: | Apparently not. So someone writing a rogue LDAP query can bring down and
domain or enterprise with no ability to stop them. Great.
-> wrote in message news:ue2Ppy00FHA.2924@TK2MSFTNGP15.phx.gbl...
So, there's no solution?
"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:Odue6pU0FHA.2008@TK2MSFTNGP10.phx.gbl...
I believe you can not realistically do that as an account will at times
be issuing Ldap queries, behind the scenes, sometimes against
the GCs, just to function as a domain client. Also, not all Ldap
queries are authenticated queries so if your objective is to
avoid a potential DoS from malicious queries they may try to
side-step your efforts using unauthenticated binds if they are
allowed to communicate with the ldap and gc ldap ports.
--
Roger Abell
Microsoft MVP (Windows Server : Security)
MCDBA, MCSE W2k3+W2k+Nt4
-> wrote in message news:uL$IzaS0FHA.3188@TK2MSFTNGP14.phx.gbl...
Is there a way to block certain user accounts from performing LDAP
queries on Active Directory?
If anyone could let me know I would be most appreciative.
|
|
|
| Back to top |
|
 |
Guest
|
Posted:
Fri Oct 21, 2005 4:51 pm Post subject:
Re: Access Control to LDAP on AD? |
|
|
Hello,
Thanks for the suggestions. Basically, I'm finding my DC's occasionally
hanging LSASS at 99% and investigation has found that there are developers
using my AD for their security, but their LDAP queries are inefficient and
therefore causing the LSASS spike. It was taking down one of our workhorse
DC's on a regular basis until it was isolated. The problem is, we can't
just turn off access to LDAP, we have to see how we can prevent this from
happening. I just found another one a week ago, not as severe. I cranked
up the LDAP logging and found out who it was, and asked them to recode their
query, but I can't stop him from running it, and it's still happening every
night when his script runs.
I'm going to look into chaning the LDAP query timeouts or better yet,
recreate a new OU structure with access restrictions for object viewing, and
then all the developers will start coming out of the woodwork.
Again, thanks for the advice.
"Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
in message news:urJBNQB1FHA.2072@TK2MSFTNGP14.phx.gbl...
| Quote: | There are also query policies that are already in place that help mitigate
DOS attacks via LDAP. It is possible to tighten these up even further
(limiting the number of query query threads, shortening time outs, etc.).
My experience is that people are more likely to do things to increase
their risk of DOS attack with these and decrease it (increasing
maxPageSize and query timeouts comes to mind), but they can go either way.
It may also be possible to severely limit the objects a normal user in the
domain can find via a search. The trick here is to make sure that it is
not so tightened down that the user no longer functions.
The original poster never explained their goal here, so it wasn't clear
what the right answer should be.
Joe K.
"Alun Jones" <alun@texis.invalid> wrote in message
news:NIedneASk79-q8jeRVn-vA@comcast.com...
Denial of Service is always a possibility. Consider someone simply
firing off connections - the classic SYN attack - to overload your LDAP
server. Yes, that will cause your LDAP server to become unreliable, in
the strictest sense that sometimes it will respond to requests, and other
times it will be unable to do so.
As for "no ability to stop them", that's going rather far. All ("all")
you have to do is monitor your network for suspicious behaviour, track
down the perpetrator, and then march over there with a couple of security
and HR personnel so that you can fire his arse for breaching your
corporate security policy. You do have a corporate security policy,
don't you? You do have an IDS in place to monitor rogue traffic, yes?
Alun.
~~~~
-> wrote in message news:O0HQAX$0FHA.1256@TK2MSFTNGP09.phx.gbl...
Apparently not. So someone writing a rogue LDAP query can bring down
and domain or enterprise with no ability to stop them. Great.
-> wrote in message news:ue2Ppy00FHA.2924@TK2MSFTNGP15.phx.gbl...
So, there's no solution?
"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:Odue6pU0FHA.2008@TK2MSFTNGP10.phx.gbl...
I believe you can not realistically do that as an account will at times
be issuing Ldap queries, behind the scenes, sometimes against
the GCs, just to function as a domain client. Also, not all Ldap
queries are authenticated queries so if your objective is to
avoid a potential DoS from malicious queries they may try to
side-step your efforts using unauthenticated binds if they are
allowed to communicate with the ldap and gc ldap ports.
--
Roger Abell
Microsoft MVP (Windows Server : Security)
MCDBA, MCSE W2k3+W2k+Nt4
-> wrote in message news:uL$IzaS0FHA.3188@TK2MSFTNGP14.phx.gbl...
Is there a way to block certain user accounts from performing LDAP
queries on Active Directory?
If anyone could let me know I would be most appreciative.
|
|
|
| Back to top |
|
 |
Roger Abell [MVP]
Guest
|
Posted:
Sat Oct 22, 2005 8:50 am Post subject:
Re: Access Control to LDAP on AD? |
|
|
Sounds like you have the right strategy, particularly as you do
want especially the developers to have awareness of quality
of their queries.
--
Roger
<-> wrote in message news:upGpB1k1FHA.3124@TK2MSFTNGP12.phx.gbl...
| Quote: | Hello,
Thanks for the suggestions. Basically, I'm finding my DC's occasionally
hanging LSASS at 99% and investigation has found that there are developers
using my AD for their security, but their LDAP queries are inefficient and
therefore causing the LSASS spike. It was taking down one of our
workhorse DC's on a regular basis until it was isolated. The problem is,
we can't just turn off access to LDAP, we have to see how we can prevent
this from happening. I just found another one a week ago, not as severe.
I cranked up the LDAP logging and found out who it was, and asked them to
recode their query, but I can't stop him from running it, and it's still
happening every night when his script runs.
I'm going to look into chaning the LDAP query timeouts or better yet,
recreate a new OU structure with access restrictions for object viewing,
and then all the developers will start coming out of the woodwork.
Again, thanks for the advice.
"Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
in message news:urJBNQB1FHA.2072@TK2MSFTNGP14.phx.gbl...
There are also query policies that are already in place that help
mitigate DOS attacks via LDAP. It is possible to tighten these up even
further (limiting the number of query query threads, shortening time
outs, etc.). My experience is that people are more likely to do things to
increase their risk of DOS attack with these and decrease it (increasing
maxPageSize and query timeouts comes to mind), but they can go either
way.
It may also be possible to severely limit the objects a normal user in
the domain can find via a search. The trick here is to make sure that it
is not so tightened down that the user no longer functions.
The original poster never explained their goal here, so it wasn't clear
what the right answer should be.
Joe K.
"Alun Jones" <alun@texis.invalid> wrote in message
news:NIedneASk79-q8jeRVn-vA@comcast.com...
Denial of Service is always a possibility. Consider someone simply
firing off connections - the classic SYN attack - to overload your LDAP
server. Yes, that will cause your LDAP server to become unreliable, in
the strictest sense that sometimes it will respond to requests, and
other times it will be unable to do so.
As for "no ability to stop them", that's going rather far. All ("all")
you have to do is monitor your network for suspicious behaviour, track
down the perpetrator, and then march over there with a couple of
security and HR personnel so that you can fire his arse for breaching
your corporate security policy. You do have a corporate security
policy, don't you? You do have an IDS in place to monitor rogue
traffic, yes?
Alun.
~~~~
-> wrote in message news:O0HQAX$0FHA.1256@TK2MSFTNGP09.phx.gbl...
Apparently not. So someone writing a rogue LDAP query can bring down
and domain or enterprise with no ability to stop them. Great.
-> wrote in message news:ue2Ppy00FHA.2924@TK2MSFTNGP15.phx.gbl...
So, there's no solution?
"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:Odue6pU0FHA.2008@TK2MSFTNGP10.phx.gbl...
I believe you can not realistically do that as an account will at
times
be issuing Ldap queries, behind the scenes, sometimes against
the GCs, just to function as a domain client. Also, not all Ldap
queries are authenticated queries so if your objective is to
avoid a potential DoS from malicious queries they may try to
side-step your efforts using unauthenticated binds if they are
allowed to communicate with the ldap and gc ldap ports.
--
Roger Abell
Microsoft MVP (Windows Server : Security)
MCDBA, MCSE W2k3+W2k+Nt4
-> wrote in message news:uL$IzaS0FHA.3188@TK2MSFTNGP14.phx.gbl...
Is there a way to block certain user accounts from performing LDAP
queries on Active Directory?
If anyone could let me know I would be most appreciative.
|
|
|
| Back to top |
|
 |
|
|
|
|