RE: securing AD parameters
- From: "Mulnick, Al" <Al.Mulnick@xxxxxxxxxx>
- To: "[ExchangeList]" <exchangelist@xxxxxxxxxxxxx>
- Date: Fri, 25 Feb 2005 09:20:56 -0500
Hmm... Not sure this is a great idea, but the concept I was looking at was
changing default permissions for objects in the schema:
http://support.microsoft.com/default.aspx?did=1&scid=kb;en-us;265399
&
http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/p
roddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/stan
dard/proddocs/en-us/sag_ADschemaReplicateAttribute.asp
Use that very very very carefully. You could ruin the entire AD Forest
implementation irreparably in nothing flat. It could also solve your
problem if used correctly.
If this is for a subset of objects instead, this might be a better way to
go:
http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/p
roddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/stan
dard/proddocs/en-us/dsadmin_set_permissions.asp
I suggest testing to make sure you have what you want coupled with careful
documentation of current settings.
Al
-----Original Message-----
From: Dan HINCKLEY [mailto:danslists@xxxxxxxx]
Sent: Friday, February 25, 2005 8:54 AM
To: [ExchangeList]
Subject: [exchangelist] RE: securing AD parameters
http://www.MSExchange.org/
At 14:30 2/25/2005, you wrote:
>http://www.MSExchange.org/
>
>I think you answered your own question (well, almost).
>
>What you want are rights assignments. It's not done via attribute per
>se, but rather through permissions settings on the attributes. Often
>done via schema if global.
>
>What exactly do you need to accomplish? By default LDAP users can't
>browse the directory in the first place without authentication.
>
>There may be an easier way to do what you want, but we'll need more
>information about the expected end state.
I am looking for a way for an admin group (for example) to store mildly
sensitive information using AD, and blocking access to that information for
my LDAP users, for example, remote mail clients who use LDAP for address
lookup; as these people authenticate with a username and password, as far as
I can tell they could lookup any AD parameter unless it has restricted
rights. I admit most wouldn't know the attributes are there or how to query
them, but why take a chance?
If indeed it's a question of managing rights on AD attributes, i confess I
have not gotten far enough into AD to know where to do that. If you have
pointers for self-study I'd be delighted to have them. Yes, I do know the
dangers of messing with the schema; we have a development server.
>-----Original Message-----
>From: Dan HINCKLEY [mailto:danslists@xxxxxxxx]
>Sent: Friday, February 25, 2005 3:25 AM
>To: [ExchangeList]
>Subject: [exchangelist] securing AD parameters
>
>Gentlemen,
>
>Is there a way to set the security on an AD parameter
>(extensionAttribute1 for example) so that only specific users or groups
>can query it via LDAP? I'm looking at keeping certain info in user
>objects secure from the general LDAP user but accessible to those with the
right to query it.
------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=exchangelist
Exchange Newsletters: http://www.msexchange.org/pages/newsletter.asp
Exchange FAQ: http://www.msexchange.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Other Internet Software Marketing Sites:
World of Windows Networking: http://www.windowsnetworking.com Leading
Network Software Directory: http://www.serverfiles.com
No.1 ISA Server Resource Site: http://www.isaserver.org Windows Security
Resource Site: http://www.windowsecurity.com/ Network Security Library:
http://www.secinf.net/ Windows 2000/NT Fax Solutions:
http://www.ntfaxfaq.com
------------------------------------------------------
You are currently subscribed to this MSEXchange.org Discussion List as:
al.mulnick@xxxxxxxxxx To unsubscribe visit
http://www.webelists.com/cgi/lyris.pl?enter=exchangelist
Report abuse to listadmin@xxxxxxxxxxxxxx
Other related posts:
