You took the words right out of my mouth. Perhaps .Net v4 or 5 will
jump through a few dozen hoops. 2.0 was a nice step up from 1.1 It's
Thanks for all your tips. I've never been a big book fan, but from
Joe Kaplan (MVP - ADSI) wrote:
> Ah, that is CDOEXM doing that. It is a terrible API and I hate it, but it
> is also the only supported method for mailbox-enabling objects in Exchange.
> Argh.
>
> But yes, AD in 2003 doesn't allow anonymous queries (GC or LDAP port), so
> that would cause a problem. Yet another reason to hate CDOEXM! The crappy
> deployment model (install Exchange System Manager?!) and dependence on ADSI
> integration (can't be used directly from LDAP) and other weird behaviors
> with little value-add increase my loathing as well.
>
> These "little" provisionings apps always do tend to get out of hand, don't
> they? :)
>
> Joe K.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"
>
http://www.directoryprogramming.net > --
> "Brian Hampson" <brian.hampson@gmail.com> wrote in message
> news:1153721235.105474.320620@m79g2000cwm.googlegroups.com...
> > Thanks Joe. I really appreciate all the tips. I had originally
> > planned on it being a "quick tool" and it has really grown. The reason
> > I wrote it is because I wanted to learn some AD programming, and make
> > my life easier. At least I got one of those two :)
> >
> > The lines that caused the anonymous GC query were:
> >
> > CDOEXM.IMailboxStore mailbox;
> > mailbox = (IMailboxStore)userentry.NativeObject;
> >
> > mailbox.CreateMailbox(MailServerList.SelectedValue.ToString());
> > userentry.CommitChanges();
> >
> > //Give Mailbox some properties, like email address.
> >
> > userentry.Properties["mailNickname"].Add(iFname.Text + "." +
> > iLName.Text);
> >
> > userentry.Properties["mail"].Add(ioemailaddress.Text +
> > emaildomain.Text);
> > userentry.CommitChanges();
> >
> > The subsystem apparently makes the query as anon if you aren't an admin
> > (or something like that) Anon read access to GC and things were happy.
> >
> > Joe Kaplan (MVP - ADSI) wrote:
> >> I was really just trying to suggest that checking permissions for DA's
> >> probably isn't that helpful. If you could, you might consider
> >> determining
> >> if the user is a DA and not filtering your list if they are. You can do
> >> this by getting the user's tokenGroups attribute and seeing if the DA
> >> group
> >> SID is in there. You can also get this directly from the user's
> >> WindowsIdentity.Groups property (which is probably easier).
> >>
> >> In our environment with >150K users and ~80K groups, this performance hit
> >> would really work. :) Neither would showing someone a list of 80K
> >> groups
> >> though. :)
> >>
> >> It is probably best to avoid doing queries that return
> >> allowedAttributesEffective against many many objects, as that result is
> >> fairly expensive for the DC to produce. However, if you are trying to
> >> trim
> >> a list, it is hard not to use it.
> >>
> >> A way to get much better perf would be to add your own attribute that
> >> contains the DNs of groups that are allowed to use that particular group
> >> and
> >> query against that. Then, of course, you need a way to keep the
> >> permissions
> >> delegations in sync with the contents of that attribute, but your UI will
> >> be
> >> much snappier and your DCs will be lest beaten up servicing that query.
> >>
> >> It is weird that your helpdesk users can't search the GC. That should
> >> work
> >> fine. Authenticated Users can typically query the GC, just like the
> >> standard LDAP ports.
> >>
> >> The rest of the stuff doesn't surprise me though. The way this kind of
> >> thing is often implemented is using a trusted subsystem design, where
> >> your
> >> client calls some server process that does have the credentials to
> >> perform
> >> the required operations, but then provides its own authorization layer to
> >> implement a role-based security mechanism. The role-based security
> >> mechanism is often a PITA to build and test, but it can gain you a bunch
> >> of
> >> important functionality. Some companies have whole products based on
> >> providing role-based delegation of operations against AD, so you could
> >> also
> >> consider buying something. :)
> >>
> >> Best of luck with your solution. It sounds like you've made a lot of
> >> progress. We have a book out there that might have helped you with some
> >> of
> >> the stuff you are doing if you are interested.
> >>
> >> Joe K.
> >>
> >> --
> >> Joe Kaplan-MS MVP Directory Services Programming
> >> Co-author of "The .NET Developer's Guide to Directory Services
> >> Programming"
> >>
http://www.directoryprogramming.net > >> --
> >> "Brian Hampson" <brian.hampson@gmail.com> wrote in message
> >> news:1153716245.263618.115990@m73g2000cwd.googlegroups.com...
> >> > Here's the gist of what I've created (some might call it a monster)
> >> >
> >> > Our environment had a number of domain admins (which we are now working
> >> > on pruning) People would create users and not put in alot of the
> >> > information ("Too much work...") so I've created a front end app that
> >> > will:
> >> >
> >> > a) create the user
> >> > b) create a home directory on a server of choice (based on which OU
> >> > they are in)
> >> > c) create a share for the home directory from that server.
> >> > d) create an exchange mailbox on a designated mailserver (based on OU)
> >> > and email address for the user.
> >> > e) place the user in a default group based on which OU they are in.
> >> > f) give the creator a list of other groups into which they have
> >> > permission to add the user. (This was the part that I needed this last
> >> > bit of help for)
> >> >
> >> > This was all fine with DA's. Then we created a "HelpDesks" group.
> >> > Suddenly things like D$ weren't available, remote WMI, Distributed COM,
> >> > reading the GC for email addresses, all fell apart. The last few weeks
> >> > I have been rewriting the code to handle the lower privs. When a
> >> > "HelpDesk" user creates a new user, they are now only presented with
> >> > the groups that they can "legally" add a user, not all :)
> >> >
> >> > Now, like I said, my only problem is that my DA's get a list of about
> >> > 500+ groups, and adding that process takes upwards of 60 seconds.
> >> >
> >> >
> >> > Here's what I'm doing for that:
> >> >