most secure way is simply to remove any write-permissions
for SELF on user objects. This is best done prior to user creation by changing
the default security descriptor of the user-class object in the schema -
otherwise you're going to have to script the removal from all users since the
permission is added explicitely to the ACL of every user
object.
Users can still logon normally and change their PW since
that right is granted by default to the Everyone well-known-security principal
anyways (changing a PW requires that you know the current PW - this is not to be
confused with a permission to "reset" a PW, which is typically granted to
delegated admins, but not to normal users).
If you then have a need for users to update specific
attributes, you can more easily achieve this by granting the required
permissions to the users via inheritance at the OU level.
Another option - as suggested below - is to remove the
more "risky" attributes from the respective default property set (not possible
in Win2). This would directly impact permissions for all users (or any
object that leverages the respective propery set). As such the change of a
property set is risky itself, but if tested and documented well, it can be a
helpful means to secure an existing AD. For example, I'd consider removing the
thumbnail photo from the "Personal Information" property set a sensible thing
(only required if you haven't removed the write permissions for SELF on user
objects via other means as described above).
Back
to the original question, if it makes sense to store photos in AD. Leaving the
security thought asside and assuming you've ensured that users can't do this
themselves, I'd say that this could even be useful for small AD
environments. But what is small?
Well, I don't consider a multi-domain AD >100K as
small. Adding real photo data into this AD will considerable impact DIT
size and memory requirements to allow good query performance of AD, bandwidth
requirements for replication, backup and recovery times as well as
promotion times for new DCs. While I'm sure AD can handle it (even in
memory once you upgrade to 64bit DCs and add sufficient memory), I can certainly
not recommend it. I am not aware of a single AD of this size that
leverages the storage of photo-data in AD - instead, as mentioned
before, I'd add a link to the photos on another store. Ofcourse the link
could be replicated to the GC and be available wherever.
/Guido
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bahta, Nathaniel V Contractor NASIC/SCNA
Sent: Donnerstag, 2. März 2006 14:42
To: [email protected]
Subject: RE: [ActiveDir] Photos in AD
Are there any Best Practices whitepapers out there on
the recommended default property sets for a secure AD? It sounds like this
ability could seriously hinder some infrastructures running
AD.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mr Oteece
Sent: Wednesday, March 01, 2006 8:56 PM
To: [email protected]
Subject: [ActiveDir] Photos in AD
Storage of photos in AD using jpegPhoto or thumbnailPhoto - yay or
nay?
I checked the archives on this and didn't see too much there beyond
Guido saying "don't do it". To quote:
[Grillenmeier, Guido
Tue, 14 Dec 2004 12:35:42 -0800
Tue, 14 Dec 2004 12:35:42 -0800
that's likely the photo or the thumbnailPhoto attribute (both octet
strings) - best way to kill your AD. There are a couple of tools out there
that allow uploading a user's photo to this attribute... The downside: every
user has the right to do so on his own account (via the SELF security principal
and the permissions granted to it with the PersonalInformation property
set). I can only recommend to take these permissions away (possible in 2k3
to remove unwanted attributes from the default property sets).
a link would certainly be better - I don't think there's a default attribute for this - you might want to introduce a new attribute to your schema.
/Guido]
a link would certainly be better - I don't think there's a default attribute for this - you might want to introduce a new attribute to your schema.
/Guido]
I actually didn't see the jpegPhoto attribute in the Personal-Information
attribute set (http://msdn.microsoft.com/library/default.asp?url=""
). Regardless, our users do not have the ability to update any of the photo
attributes. So beyond DoS issues with users being able to upload large files
into AD, what are the potential issues with having these out there? I certainly
don't want to be flinging these bits to all corners of the world, and I would
much rather use a link attribute. Coming up against management here though.
So, any real-world experience on populating photos in AD? Any more cons
beyond DIT bloat and DoS?
Consider it a rather large AD implementation, with multiple child domains,
>100K users, and a need to have the photo information in the global
catalog
