MSDE = SQL2005Express isn't it?
I'd really prefer not to introduce yet another DB technology into the mix if possible.
Joe, I think that some logic to prevent the creation of too many sids is needed in the product regardless, but I think some level of self-service is needed. I've seen too many processes that allow for the 'rubber-stamp' approval of group creation that I'd rather see a system that enforces some of the rules and reports on exceptions vs. having a layer 8 process that just doesn't get the attention needed until long after it's a problem. I can tell you from experience (and I'm sure I'm preaching to the choir here) that few organizations have regulated the creation of group policy the way they should until after it bit them either because of operational problems or because of compliance issues. Some still won't address nor ack that it's a even important after that (other than those that are required for compliance of course.)
Autogroup was fine, but it still allowed for groups of any name. I don't think that was such a hot idea for most organizations. I wouldn't be surprised to find a group inside of MS that was called something like "pigpen" or some other peanuts character. (Side note: While many may not see that as a problem, if you have an international presence, what seems fine in one culture won't be fine in another and may even be offensive. )
Oddly, I've thought that something like this should be available for years from the vendor (MS) but AutoDL and AutoGroup are not the answers I had in mind if they were to do that.
Putting tools that help you to manage your AD and or Exchange (let's just call them applications you've already bought) should not come in a product suite such as MIIS only. That would be similar to buying from another large, blue company that Microsoft used to write code for. That's a horrible model from my perspective and usually just irritates me especially when you have a partner model vs. a "we'll build it all" model for bringing products to market. That's because when you have that type of market, you make "good enough" products that satisfy the general need but allow room for creative and nimble third-party companies to come up with great products. The issue here is whether I should have to even go to a third party to manage what I already bought.
Anyway, if this doesn't make it, maybe we'll have to have a look at writing a tool based on some of that. For now, it might be good to move that to the back burner and see what already exists or can be easily modified.
-ajm
On 12/28/05, joe <[EMAIL PROTECTED]> wrote:
The old MS Solution which just did DLs is called AutoDL and it has been available externally but as Al points out, depends on SQL Server. Then came AutoGroup which MS would not give out to anyone but handled Sec and Non-Sec AD groups, I know I tried for over a year to get it and was finally told all of this functionality was being wrapped into MIIS.... But again, that depends on SQL Server.If someone inside of MS intends to make yet another solution, I would highly recommend it not need SQL Server and that it handle AD and ADAM. Possibly it should use ADAM as its backend store? Alternatively it could use AD itself or MSDE (regardless of size of org) or ESE.I agree completely with Al on the group naming. Blood has been spilled over much less than names. Some of the biggest bloodiest corporate arguments I have been involved in have been about naming standards. I know of no large company that would allow end users to come up with their own names without rules around it. Even in a small company you could see a name like sbradleysucksmybutt or something like that which is obviously not a good thing in a corporate environment. Sure you will have logging of who did it once someone figures out it was done, but if you have 50,000 or 100,000 groups out there, who is doing that checking?Another thing, users shouldn't just be creating groups ad hoc. There needs to be a corporate strategy that walks you around the mine fields of having too many SIDS in your tokens or just plain replicating a bunch of crap that doesn't need to be out there at all. As Al indicated you definitely need a work flow where approval has to be gathered prior to the system just doing this.Other than that. As Al and Brian indicated, this has been a problem with many solutions through the years.
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Al Mulnick
Sent: Wednesday, December 28, 2005 9:04 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] OT: creation of Email and Security groups [through GUI no less]
Wouldn't Tony already be aware of such things?DL/DG management is not a new issue by any stretch. It gets new life because the DG can now also be a SG which makes it more important to understand the ramifications of creating a new DG.The Dev team should well aware of such things and should also be familiar with the Microsoft solutions used in-house (which are not always available to the public).Personally, if they're going to roll a solution for group management, don't limit it to those using Exchange and therefore have DG's that are also SG's. Make it a group management function (preferred not to be based on expensive DB technology) that encompasses customers of AD (the common denominator). It would not bother me if there were added functions that you could get with Exchange deployed, but don't make it so you have to have it.Any solution created should have the ability to be self or centrally managed in an organization with 1 or more DC's and 1 to 500,000 users (or more?) There should be audit ability as well as the ability to send reminders and validation flows of group membership along with the ability to set business logic rules. An example of that would be to require an owner for every group created. That owner MUST have an account in the AD and it must be active. If not, there must be some sort of override else the group is automatically removed from circulation. This would help greatly with things such as SOX compliance as well as other compliance efforts. Another need to have would be the ability to have the creation of groups follow a pre-defined naming standard. Nice to allow users the freedom to create groups with any name they wish, but that doesn't help with the greater good in an organization over 100 people. Surprisingly (not really) if you put 100 people in a room and ask them to come up with meaningful names for groups, you'd get 101 names for the same group you're going to create. That would be fine in a Yahoo! setting but for corporate use it's unpredictable and next to impossible to manage or worse, troubleshoot. Good naming standards are the responsibility of the corporation's architects and it's up to those standards creation processes to come up with meaningful and useful naming standards. Not the consumers of the service. At least, not if you intend to keep the service available and able to be troubleshot in a timely manner. Besides, who would win if two equal folks decided they wanted the same name for a group? Sword fighting duels are not legal in most countries any longer :)The list goes on, but there are many things that this type of tool can be useful for. I think many of the third party solutions that are mentioned later in the thread are very good, but if Microsoft is going to create such a product, they should consider what it's intended uses are and balance that against what exists and what problems their customers need to solve. They should also consider the implications of creating a product that competes with their partners.Finally, Susan, if you know Tony, you might suggest that he talk with the Exchange and AD product teams. I'm sure they have somebody who is aware of the issues and the currently available solutions from partners. It's possible there's still some room for additional solutions, but it would be good for him to research with them to avoid overlap where it may not be needed.Then again, what would I know about it? ;-)
On 12/27/05, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] < [EMAIL PROTECTED]> wrote:Got a list? You might want to ping Tony so he doesn't reinvent the
wheel :-)
Brian Desmond wrote:
>Tools exist form MS in the past, 3rd party, and in many large orgs home baked stuff...
>
>Thanks,
>Brian Desmond
> [EMAIL PROTECTED]
>
>c - 312.731.3132
>
>________________________________
>
>From: [EMAIL PROTECTED] on behalf of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
>Sent: Tue 12/27/2005 9:42 PM
>To: ActiveDir@mail.activedir.org
>Subject: [ActiveDir] OT: creation of Email and Security groups [through GUI no less]
>
>
>
> http://blogs.technet.com/secguide/archive/2005/12/27/416528.aspx
>
>MSSC is looking into the possibility of a solution/tool to help with creation and lifecycle management of email and security distribution groups
>
>* Creating and managing groups within an organization requires unnecessary administrative overhead.
>* Administrators use valuable time creating groups that could otherwise be used for other IT activities.
>* End-user productivity may be hampered by delays in processing requests for creation of groups.
>* End users find it frustrating that they cannot create and manage groups that have meaningful names and users find it hard to manage especially for adding and removing users.
>
>The proposed solution would provide end-users with the ability to create and manage groups through a simple self-help Web portal.
>
>
>
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
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/
