Hey! I thought Stuart and I mentioned the undelete already? :) Oh, and Laura, I think your idea of being able to restore a DC to different hardware, i.e. having a backup utility that's not a sledgehammer approach to putting in a nail, but rather only backs those parts of the registry needed to restore the DC, is just crazy talk. Crazy. Plain crazy. -ajm
________________________________ From: [EMAIL PROTECTED] on behalf of joe Sent: Tue 8/2/2005 8:17 PM To: [email protected] Subject: RE: [ActiveDir] Biggest AD Gripes This topic is going well, I will add some more now o Backlinks capability on ACLs in the directory, so you can ask a user object, which objects do you have access rights on. I realize this a monster of a problem with group nesting, primary groups, etc. o The fact that primary groups are not in the memberOf listing and that member on a group doesn't show primary members. I know why this was done, but the reason is gone now... o Change tracking is a bit more painful than it needs to be. Would like a simple change log capability that could be subscribed to (platform agnostic) but that has good detail (what specifically changed, maybe even who made the change). Admins can configure the delegation on this and only this (i.e. it isn't tied to something else too). o Simple mechanism to find all group memberships across the forest, preferably LDAP based that any platform can use (i.e. not a special RPC or NET type function). Basically add a special constructed attribute on user object like forestGroupMemberships which returns everything, nested, primary, cross domain, etc. o A new group that is a cross between universal groups and domain local groups - call them a universal domain local group. Anyone can be put in them, they can be applied to a resource anywhere, but they aren't in the global catalog. Membership is maintained on the user object somehow through a phantom like mechanism. If a user in domainB is added to group in domainA, a phantom is added to domainB for the group and that membership is reflected on the user and when the user authenticates, they get the SID in the token. Gets around the whole pita with GCs everywhere. o Ability to turn off legacy support, like say sAMAccountNames. If I don't want it, it doesn't even create the attribute. We have stepped in that direction with K3 making it so SAM Names aren't required but it does so by randomly generating a name. o Staged delete process. This was discussed recently with some other AD Gurus I work with, the idea was put forth and I really liked it and added to it. Basically when you delete an object, all attributes are maintained for x1 days. At the end of x1 days, some portion of the attributes are stripped and it is maintained that way for x2 days (probably the same stripping that occurs now). At the end of x2 days everything is stripped from the object except name, sam name (maybe), sid, and guid which are kept forever unless that is even configured to be purged out. This means with x1 days you could easily do a full recover, in the x2 days you could do a partial recovery fairly easily, after x2 days you could still get the SID and GUID back. This actually could be implemented in a product outside of AD if you didn't mind really deleting objects but instead sticking them in a special hidden OU. If someone wanted to write a piece to insert into the LDAP API processing code and intercept deletes then even that limitation could be removed because you would change a delete to a move. I wouldn't recommend this mechanism as it would make MS very itchy but it is a mechanism that could probably be made to work. If someone builds this, I wouldn't mind royalties thanks... o Ability to query an object to determine what constructed attributes are available to be requested for the object or at least which ones the user querying has access to so as not to give away info insecurely. o An end to the back end hardcoding that directly overrules schema rules like description being single values on sam objects or samaccountname lengths, etc. A tool should be able to read the schema and get the real life actual implemented rules so that it doesn't try to use them then hit a special hard coded rule such that programmers have to write special code around specific attributes. o Better schema descriptions of attributes so that for instance a GUID can easily be ascertained from a normal binary attribute without taking a guess that a certain size binary value is *probably* a GUID. o I mentioned this one last MVP summit but.... Ability to upgrade AD outside of OS. This is obviously dependent on whether or not AD is taking advantage of some new function of the OS such as special disk I/O calls or something. But I would love to say have all DCs on K3 but be able to rev AD from Version 5.2 to Version 6.0. That way if I want to go to Longhorn AD native mode, I can actually shoot out the AD piece quickly to all DCs and get there and slowly come through upgrading the OS as possible. o I dislike the schema default SD, would rather have everything be initially inherited ACEs which can more easily be overridden. Give us a lockdown pack that is supported by MS even if running Exchange or any other MS apps. o I would like it if AD started ignoring any addresses that are flooding it with bad authentication attempts. The thresholds would be configurable by admin. o I would like global catalogs to register site AND domain specific records. I.E. A GC for domainA would register a GC record that is in domainA zone. This way if an app wants a GC that is a DC for domainA it can easily find it. Think Exchange though there are other apps that would use it. o I seriously dislike userAccountControl and userParameters. Break the function of these up into separate attribs that are simple clear unicode text or boolean values. o Wild card "exists" searches on linked attributes should use the implicit linked attribute indexes. They partially fixed this in K3 where now at least the index is used for normal searches, but how about for the EXISTS case like member=*. That falls back to the DNT_index or whatever other index could be used from the query. o Index objectClass already. o I would like a rootdse constructed attribute that I could query to get which sites a DC covers. Again, think platform agnostic. o Would like to be able to send a normal simple tcp LDAP query to get a response back in a standard format like the info returned from a UDP LDAP ping. Hard to do a UDP LDAP Ping from a script. o I like the AD/AM tokenGroups rootdse attribute, would like that in AD. There are more, I will let these sit out there for a while... Keep the ideas coming everyone. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Tuesday, August 02, 2005 12:25 PM To: [email protected] Subject: [ActiveDir] Biggest AD Gripes So what are everyone's biggest AD Gripes? I am not talking about gripes about things that use AD like GPOs[1] or Exchange or NFS or anything else like that. I mean actual AD really missed the boat because of this that or the other thing. Like o I dislike that when you defunct an attribute it doesn't purge the information in the directory for that attribute. o The fact that AD Security policy is managed through a technology dependent on AD and replicates both within AD and the other technology. o I dislike that there is no true schema delete. o I dislike the fact that I can't specify which branches of the tree replicate where. o I dislike the fact that GUIDs are represented in multiple ways in the directory. o I dislike the implementation of property sets especially since they could be so incredible awesomely cool. Specifically I dislike that an attribute can only be in a single property set. o I dislike creator/owner on SDs. o I dislike the lack of configurable business rules. o I dislike the fact that I can't run multiple domains on a single domain controller. Etc etc. I have more but lets see what others say. Everyone pipe up. Let's pretend that MS will actually see this, let's further say let's pretend MS AD Developers will see this. What would you tell them if you were sitting in the room with them? joe [1] I do not consider GPOs to be part of AD. They are a technology that leverages AD. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
<<winmail.dat>>
