BTW.. to Brett... Joe is like "Cher".. he doesn't need a last name....
joe wrote:
Two directories doesn't mean you
are doing it for two auth domains. You did this in E55, the Exchange
forest is simply for holding resources and the "real" directory handles
the auth.
I don't have a problem with
multiple directories in order to protect the global whole... What
really needs to happen is to push back on vendors who put out crap apps
that don't play nice. This includes MSFT. Unfortunately I can think of
no app that is as abusive and pervasive as Exchange and I still have no
faith that the Exchange Dev group actually gets that they are playing
in a shared sandbox versus their own private sandbox, so they feel no
inhibition to crapping in it whereever they desire. I look with great
joy at new mail/collaboration systems coming out that can give Exchange
a serious run because I think that is probably one of the only things
that will get them moving as they don't tend to listen to feedback
unless there is pain associated with it. At least I haven't gotten them
to fix a single thing unless I somehow threatened that they would feel
pain over it. Otherwise they blow you off and laugh knowing you are
pretty much stuck with it because while it sucks, as many say, it is
probably the best of crap apps out there doing the same thing.
I love the idea of Exchange using ADAM.
Unfortunately it doesn't appear that this is happening in E12 except in
a very minimal way, but at least it is a start. I think the issue here
is that Exchange Dev is more interesting in rushing towards new
features over stabilizing and properly securing the core application. I
understand why... For most customers out there, Exchange is good enough
as it is at a core infrastructure level because no one has used it
against them to beat their ass yet. They assume since nothing has
happened and they don't have the skill themselves to do something with
it that it must be safe and secure and good. Perhaps nothing will ever
happen, perhaps next week someone will release something that burns out
98% of the Exchange deployments and Active Directories in corporate
America because of the poor underpinnings in Exchange.
The binding between ADAM really doesn't
need all that much work. It could be very much like the
msExchMasterAccountSid... The ADAM directory simply points at the
associated object in AD so when a user logs into Exchange, it can
figure out what mailbox to present. Maybe you have a sync process for
maintaining the site/subnet definitions if the Exchange folks don't
want to have their own site/subnet/replication topology. The most work
is what I think Exchange needs to do whether it uses ADAM or not and
that is to start tearing all of the data except the actual messaging
info out of the store and maintaining it in the directory. Permissions
shouldn't be stored in both places... one or the other and I think with
the ease and thinness of LDAP over MAPI the logical place is in the
directory. Then Exchange can stop coming up with all sorts of fun
interfaces to allow intelligent admins to automate things, they can
focus on making the product bullet proof and leverage everything that
already exists for managing LDAP.
joe
Making it a black box is a strong argument. But it is Microsoft
and if they can't support it on their own software, then I have no
confidence in their ability. If they open it to other software, the
support matrix becomes increasingly detrimental to the availability as
you go through the possibilities causing the outage.
*could* these DB apps work with other DB's. Sure. It's not
likely that the DB's differ so much that they couldn't. But it's the
principal of the matter. And making it blackbox doesn't offer any
value other than masking it from rogue/stupid sql l-admins.
Hmm... Exchange permissioning. Funny, as bad as it is, the more
I use some of this opensource and *nix based cr*p, the more I like the
way they did it :) But you are correct that the permissions are
difficult. I disagree that you should ever give an Exchange admin
rights, even local rights, if they can't be trusted. Let's face it, if
I give a file/print admin rights, they can be dangerous and likely
could find a way to exploit something to cause pain. Lesson: give out
admin rights in a miserly fashion. Additionally, I agree that the
rights could and should be much better; an Exchange admin on a machine
should not have the rights available that they tend to have on a shared
service. That should have been nixed early in the dev cycle.
Since it wasn't, then the alternative you're presenting is to
maintain two directories and two authentication domains. I don't like
that option either. Does it protect one directory? yes. Is that
directory important to the other apps and companies? yes. Is it a good
solution? I don't like it. It sets a precedent that an app that's
dangerous (as deemed by the *other* directory admin) should get it's
own directory. Now we're back to 14+ directories being maintained etc.
Better idea? I think if you're going to do a separate directory,
make Exchange utilize ADAM and make special connectors (whatever name)
that push one-way replication to ADAM instances for the purpose of
Exchange. It would, of course have to be configurable and in it's
simplest form not be able to do transformation of data, but it would
solve both issues because then Exchange wouldn't have to have the DA
rights. In fact, they could be completely isolated. Of course, you
might be back to utilizing service accounts then :)
I'm interested in hearing a better solution. I hate the amount
of permissions and hooks that Exchange pushes on the directory and I'm
an Exchange guy from way back! But I haven't heard a better way to do
it and I know my ideas are full of holes.
-ajm
On 5/25/06, joe <[EMAIL PROTECTED]> wrote:
The thing is I am not so worried about the DA impacting
Exchange, it is Exchange admins impacting AD. The permissions that you
would normally delegate to Exchange without applying a ton of
denies touch some very sensitive attributes. On top of that, a bright
Exchange admin can bypass a lot of that anyway. You don't even
initially need Exchange admin rights, you just need local admin rights
on an Exchange server and you can start your attack on AD and keep
escalating away. The Exchange permissioning model sucks ass. It is
unnecessarily complex and overreaching. The only safe Exchange when you
have separation of duties is Exchange off in its own forest. If you
have a small environment and your 3-5 domain admins can also handle
Exchange comfortably too then it is fine for a single forest
(preferably single domain) model. I hope that E12 makes this all better
but I would be shocked if it does, I haven't done any testing of it yet
so I don't know.
I can see where MSFT would like to have an MSFT backend but I
don't see why there is a requirement for it. Any DB should be able to
be the backend if they are going to use a standalone separate DB. If
they want to make it all MSFT and no reason to look at anything else,
black box it with ESE or a version of SQL that needs nothing and can't
be touched with the standard mechanisms.
Sent: Wednesday, May 24, 2006 9:21 AM
Yeah, I think we're dancing around the same bush here. The
difference is how far each of us is willing to go in any one direction,
but generally we're on the same page.
Except for Exchange resource forests. It sickens me to see
some of the options presented to the designer when it comes to Exchange
delegation models. Using a resource forest throws salt on the wound.
Exchange was just not built to be in multiple forests. It's totally
unnatural and painful in many situations. Consider it this way: if
you're company has so many layer-8 issues that it must prevent DA's
from accessing or screwing with Exchange components by deploying a
resource forest, what's the chance that you can handle the complexity
that entails?
I live in the real world and I understand that politics and
process are a valid part of any implementation. But I highly prefer
simplicity to complexity when reliability is a concern. Microsoft
needs to come up with a better answer to the problem in my opinion.
Something more solid than "..here, throw this at it and deploy this PF
sync tool from the reskit and your problems will go away.." would be
appreciated.
Basing a solution on something like SQL Express is not a
problem to me. I appreciate the risk of rogue/stupid SQL admins
(<aside> let's face it, administrative impact could happen at any
point and disrupt service, but I'll confine it to SQL specifics for the
purposes of this conversation </aside>) but I also think that
something that comes from Microsoft should be based on their
technology. I just don't think that extra spend for that type of
design should be accepted by the architects and that those solutions
tend to be problem prone. Kind of like MSCS deployments - the
complexity may not be worth the return. In the case of resource
forests, it's almost always not worth the return from what I've seen.
LDSU? Did you get a cookie with the Kool-aid? ;)
On 5/23/06, joe <[EMAIL PROTECTED]>
wrote:
I think the goal should be to build a stable
robust directory service that is as flexible as you make it but not so
flexible that you put yourself into bad positions to support any one
app. The goals of the Directory folks should be to make sure they have
something that everyone can use and something no one group can wipe
out. This means that every app is the same to the directory people,
they have a dependency on the directory, none are more important than
any others in that set of goals.
I completely agree with the LDAP auth stuff.
LDAP isn't an auth protocol. I can carry water with my two hands cupped
together, doesn't mean I am going to try and fill a pool that way.
RE: Resource forest for Exchange.... The
Exchange delegation model sucks so much water that running a separate
forest is almost the only way to efficiently break off Exchange support
in a guaranteed safe and secure manner. And there are other solutions
to not using MIIS, such as LDSU or other third party syncing. As you
know I agree completely on MIIS'es "requirements". Personally I
wouldn't even go for SQL 2005 Express. I want to be able to specify any
backend store or I want the backend store to be completely and utterly
black box like ESE. Both because I don't want to have to worry about
grooming it and I don't want to worry about SQL DBA wannabees screwing
with it. Just like with AD there are a lot of people who think they
know SQL when in fact they can simply spell it, this goes for several
DBAs I have met through the years as well as some people I have heard
about through others. I heard a story recently about a SQL Expert that
made me wonder who tied his shoes in the morning for him. Had I been
dealing with him instead of my oh so patient friend, I don't expect he
would have reported back to work or his superiors would have let him
come back to work. There isn't a class or books teaching people how to
manage ESE so that makes it about 10,000% better than SQL Server all
alone because the people who will be figuring out how to work with it
will be doing so from MSDN API docs and will probably be considerably
more capable than your normal Microsoft SQL Server DBA. But that is
just one reason why I don't want SQL Server backend for stuff. I recall
when we are the summit a couple of years ago when we all were piping up
about this. It doesn't appear anyone listened, but I think it is good
that we continue to pipe up about it.
Sent: Tuesday, May 23, 2006 10:17 AM
No, Exchange is not the only app for the directory. I
concur. Exchange does not just leverage the NOS directory for it's
usage. It relies on it heavily. In fact, Exchange doesn't exist
without it, but...
I think the question needs to be answered though: Does the
application dictate what the directory can do or should the directory
dictate what the application does? I think that's important to the way
you design, deploy, and maintain your Active Directory, and other
directory services in your organization. The same theory and
guidelines apply when you consider SiteMinder (shudder) and SunOne or
OpenLDAP and Sendmail or ... the list goes on. Put another way, does
the directory exist for the sole purpose of being a directory or does
it exist to service multiple applications? If multiple applications,
how much should the directory adjust to the needs of it's constituents
vs. the constituents adjust to the needs of the directory? <my
thought: it's the whole not the part that's important. But neither has
a reason to exist without the other, so we're still stuck in a decision
loop.>
Figuring this out sets the stage for a solid deployment of
both the directory service and the applications. NOS directory aside,
it is a directory and it's one that can and should be multifunction.
Whitepages are nice and cute and all, but have limited use if that's
all they do. But if it can also identify and authenticate a security
principal (don't give me that LDAP authentication crap either - drives
me nuts to hear LDAP being used as an authentication protocol
</rant>) now that's real value. What? The hosts can be
multi-function devices? Bonus! I like it even better.
It's important to decide what the directory service is going
to be and how it will be maintained IMHO.
-ajm
Exchange in a resource forest? Ewwww.... that's less than
natural, reduces functionality, increases complexity and moving parts,
and MIIS's FP isn't what I call a good solution (I call it a stopper
and a reskit utility) until it runs on standard server and SQL 2005
Express and, and.. (why is it we should want to pay extra to get a good
design again?)
On 5/23/06, joe <[EMAIL PROTECTED]>
wrote:
> Does the application dictate what the directory can do?
>
Or should the directory dictate what the application does?
But
Exchange isn't the only app for the directory... Exchange is generally
leveraging the NOS directory for E2K+ deployments, now if you got o a
resource forest for Exchange, set it up for the app all day. :)
> Those are client-side
applications, not Exchange.
True,
but they need to be planned in the Exchange design as they have
tremendous impact on it. Recently I heard of a group that treated BES
as an office automation application, I was truly shocked, I never seen
it treated as anything but core messaging.
Sent: Thursday, May 18, 2006 9:13 PM
Subject: Re: [ActiveDir][OT] DNS on a DC or
NOT
"If someone was lucky
enough to have been running AD as a NOS directory for some time they
had enough understanding and ammo to tell those MCS guys to bag it when
they were saying Exchange-centric things. "
Why are you picking on me, joe? :)
I think there's a philosophical issue there: Does the
application dictate what the directory can do? Or should the directory
dictate what the application does?
My answer( ICYGAF ) is that neither. The directory is the
foundation and as such should tell the applicationS how to play with it
to achieve the most reliable service levels. One is not better and
without the other, there is not as much meaning in their life
</philosophical>
Crackberry? DTS? Exchange is a hog, I'll give you that. It
eats disk like nobody's business. What you're saying and what I'm
hearing are two separate things, I think. Those are client-side
applications, not Exchange. BB has an older architecture that works
because of the older protocols being brought forward. It's been known
for a long time that BES installations can severely limit the
performance of a machine. Severely is being optimistic and because of
the usage pattern predictability issues, it's a real art to design and
deploy reliable email systems these days.
Not the same thing however. And the tools? Exchange 2K vs.
Exchange 2K3 is a world of difference, but the 2K3 release was an
attempt to get admins back to 5.5 functionality levels using the MMC
model (don't get me started) and the new architecture of multiple
stores without a directory service local to the Exchange server.
In the end, the directory separation works out better than
other implementations. Exchange works better with the directory than
other applications I've seen (worked with application servers
lately? -bet you have and know exactly what I'm talking about). But I
also question the rubber stamp concept of separating the directory from
the server during design. There are times when it's a good idea. Kind
of like multiple forests have their place in a design. Not my designs
typically, but I can see where it might come into play.
Al
<still can't see me?>
On 5/18/06, joe <[EMAIL PROTECTED]>
wrote:
Hey I can read it! Good show Al!
Dean is a complete noob in terms of Exchange
next to me. ;o) But I am not an Exchange guy by any stretch, I am an AD
guy who digs into Exchange problems as if they were just any other
problem. I know nothing about E5.5. I constantly hear how the admin
tools etc suck in E2K+ compared to E5.5, I have no clue, I look away
when I see it, I don't want to learn it.
> Exchange actually does it better than
most, although as joe
> points out, there is always room for improvement.
Does what better? Exchange certainly uses the
directory more than most, it would be a rough morning after the night I
said it uses it better than most things and I might find myself married
with a crashed car and having a massive hangover at about the same time
I start the regrets on saying Exchange did something better... ;o)
Good comments on the original idea for AD. I
recall itching everytime I heard folks (even Stuart) saying it was the
every-directory as I was looking at Enterprise level companies with
10-15+ directories and no one even close to wanting to go to a single
one especially the one made by the company who couldn't produce a
domain that could reliably go over 40k users (slight exageration there,
we were running domains with 60-100k users on them but I was waiting
for the bomb to drop)....
> Meanwhile, Exchange was the "killer"
app that caused people to even
> consider that major leap from NT4 to AD
I think this helped but in a lot of larger orgs
I know they were going to AD before Exchange 2K was considered. The
earlier mentioned problem of NT domains that were barely running was a
big pusher for very large orgs as well as the idea of getting to a more
standards based environment. I feel for anyone who does their AD and
Exchange migrations at the same time because they end up building a
directory that is dedicated to Exchange and tend to run into fun when
trying to do other things. There are a lot of Exchange consultant with
a lot of silly ideas on how AD should be configured. If someone was
lucky enough to have been running AD as a NOS directory for some time
they had enough understanding and ammo to tell those MCS guys to bag it
when they were saying Exchange-centric things.
> Want a single server to handle 4,000
heavy mapi users?
> You can't do that with Exchange 5.x, but you can with
Exchange 200x.
Just make sure they are *just* heavy MAPI users
and not heavy MAPI AND (Blackberry OR Desktop Search) users. I swear I
hear more issues because of those two addons than anything else I have
heard of (DT Search also includes, probaby incorrectly, apps that
archive content). Once you start adding those side apps each user needs
to be considered much more than one user, they should be considered
3,4,5,6 users and E2K doesn't scale well to handle that if you are
counting users in the singular. Sorry that was wildly OT but I keep
hearing about folks complaining that their servers should handle 4000
users fine but they are finding that 1000 users may be a stretch if
they are BB or DTS users as well.
Good comments overall, bonus that I could
actually read it. :o)
<trying this in rich text from gmail to see if it
floats; let me know if you can't see the text joe :)>
Um, no. (Yes, it does have to be a DC to be a GC.) But other than
scalability and simplicity related to troubleshooting/recoverability,
what exactly do you sacrifice if you put Exchange on a GC?
There are those that think that putting Exchange on a GC is the way to
go. There are others that would disagree but what else is new. For
those that have been implementing and designing Exchange for a number
of years (joe's not really that old compared to Dean ;-) this concept
would seem familiar to the Exchange 4-5x days.
As a number of apps were promised to do, Exchange heavily utilizes and
therefore relies on the AD directory for authentication, authorization,
and directory services (identification) (i.e. directory lookups to aid
in mail routing, server lookups (DNS), configuration settings (GPO),
and GAL services, etc). Exchange actually does it better than most,
although as joe points out, there is always room for improvement.
If you look at the history, there were some dark days
around the Exchange 2000 deployments for Exchange. 2003 got much
better and hopefully E12 (what's it called now? I forget) won't get
"office-ized" by the org changes going on at Microsoft. I've seen the
"servers" that the office team put out and I'm thoroughly less than
impressed. Hopefully that gets better, but I'm not a desktop guy and
I'm not interested in becoming a desktop focused expert. Those desktop
machines and office productivity apps are prime targets for
commoditization over the next 5 years IMHO. Too much is at stake for it
not to be. But I digress.
<history> The original implementation of AD was
expected by Microsoft architects to replace ALL of the other directory
services you might have and become the centerpiece to your networked
computing infrastructure. It's why you'll find things like DNS
integrated into the directory. Well, one reason anyway. Anyhow, as
time wore on, adoption was slower than hoped for and one reason was
that it was a big pill to swallow. Many large companies already had a
working NT model (I say that tongue in cheek: it was limping along in
large orgs), had working DNS models including administrivia and DR
processes (shame on you if you don't), and a working directory
structure based on the LDAP standards that, although they started as a
client access protocol to X.500 directories, become synonymous with
server side implementations. Whatever, only a purist cares I'm sure. It
was realized that although AD had a place in the environment, it was
not likely going to rule the world overnight as originally expected and
designed and marketed and.... It could however be made to play well and
nicely and a lot of refinement was put into that release and now R2.
Meanwhile, Exchange was the "killer" app that caused
people to even consider that major leap from NT4 to AD (which we know
now is really not that big a deal, but boy was it scary then, right?)
Some are still migrating or just getting started, but to each their
own.
Exchange was often bashed for not being scalable
soooooo.... it makes sense to off-load some of the services to a single
purpose machine - we know it as a domain controller/dns host/directory
server/etc. Wow. What a great idea. Wait. What if you don't have a
network design that can take advantage of that? Maybe it was geared up
and refined to be better with a mainframe centric computing model and
maybe NT 4.0 was existing there? Hmm... Or maybe your company doesn't
have a network that looks like a single 40-story (storey for those
across the pond) building with one single high-speed network? Maybe you
have users accessing your email and directory from around the globe and
maybe 40% of your users are mobile at any given time? Maybe more.
Exchange won't play nice with a network like that out of the box
because it was geared up to be scalable. Want a single server to
handle 4,000 heavy mapi users? You can't do that with Exchange 5.x,
but you can with Exchange 200x. Why? Many reasons and I won't bore you
with the details. What's important is that if you look at the
topology, it might make more sense to put the directory back onto
Exchange computers based on the way your network works. Can you scale
it as high? No. Is it simple to recover? No (it should be easier than
it is IMHO). But does it serve the purpose better? Yes. Can it handle
that 150 user density South African office without being hampered by
the hamstrung internet connection off the continent? I've been told
it's much better performance than using something like cached mode
clients or OWA if the server is local. I can believe that.
Help me understand why I wouldn't put Exchange on a GC
in more situations than I don't? What would I lose?
Neil, I'm curious about what you'd pick for an
authentication service over AD?
Heck, now I'm just rambling though, 'cause this is likely blank ;)
Al
On 5/18/06, Carlos Magalhaes < [EMAIL PROTECTED]>
wrote:
> Well currently to have a GC you need that machine to be a DC and
as we
> all know you don't put Exchange on a DC ;)
>
> Exchange already feels special ;)
>
> Carlos Magalhaes
>
> Krenceski, William wrote:
> > Why can't exchange just have the GC on it somehow. I'm not a
developer
> > by any means of the word. It just seems that if Exchange is
"SPECIAL"
> > make it feel special......
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto: [EMAIL PROTECTED]
] On Behalf Of joe
> > Sent: Wednesday, May 17, 2006 7:21 PM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir][OT] DNS on a DC or NOT
> >
> > LOL.
> >
> > For those not at the DEC 2006 Dean and joe show presentation,
Mark's
> > 'Exchange is "SPECIAL"' comment is a direct reference to
something I
> > said when bouncing around talking about AD and bad
applications. I
> > miraculously stopped and looked straight at a Microsoft MVP
for Exchange
> > (Mark) while spouting the truism Exchange is "SPECIAL" in
relation to
> > how it abuses AD. I was in a groove when I said it so I
didn't actually
> > realize I was looking at Mark or else I probably would have
bust out
> > laughing as I did later when he explained what I had done.
> >
> > I think all of the Exchange MVPs tend to have a special place
in their
> > heart for me as does the entire Exchange Dev team. ;o)
> >
> >
> > joe
> >
> >
> >
> > --
> > O'Reilly Active Directory Third Edition -
> > http://www.joeware.net/win/ad3e.htm
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:
[EMAIL PROTECTED] ] On Behalf Of Mark Arnold
> > Sent: Wednesday, May 17, 2006 5:29 PM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir][OT] DNS on a DC or NOT
> >
> > Laura, a "Mucker" is, in English, a good friend.
> > You are probably not to be termed a Mucker, other words might
apply, but
> > Jimmy is one of mine and Dean/Joe is one of yours.
> >
> > Oh, and Joe is old and smells of wee, so pay no heed to his
Exchange
> > rants.
> > Exchange is indeed "special" because it's such a wonderful
solution. OK,
> > I should shut up now and go back to my padded cell.
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:
[EMAIL PROTECTED] ] On Behalf Of Laura E. Hunter
> > Sent: 17 May 2006 21:39
> > To: ActiveDir@mail.activedir.org
> > Subject: Re: [ActiveDir][OT] DNS on a DC or NOT
> >
> >
> >> BTW, anyone know what a mucker is? I am trying to figure
out if I am
> >> supposed to be morally outraged. <eg>
> >>
> >> joe
> >>
> >>
> >
> > I use "mucker" as a compliment, but in my vernacular it's
used in
> > reference to a semi-skilled hockey player whose lack of
scoring ability
> > is balanced by his ability to check an opposing player into
sometime
> > next week.
> >
> > So I guess what I'm saying is...draw your own
conclusions. :-)
> > 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/
> >
> >
> >
> > This message has been scanned by Antigen. Every effort has
been made to
> > ensure it is clean.
> >
> > 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/
> >
> > Confidentiality Notice: The information contained in this
message may be legally privileged and confidential information intended
only for the use of the individual or entity named above. If the reader
of this message is not the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient, you are hereby
notified that any release, dissemination, distribution, or copying of
this communication is strictly prohibited. If you have received this
communication in error please notify the author immediately by replying
to this message and deleting the original message. Thank you.
> >
> > 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/
>
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
The SBS product team wants to hear from you:
http://msmvps.com/blogs/bradley/archive/2006/05/18/95865.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
|
