Houston and San Antonio TAM's are, IMO, generally more technical than the average TAM. Or, if not technical, they're much more directly involved with their customers and know how to take care of them. Regardless, you're always going to hear the dev/support/sales engineers bag on TAM's. There's a pecking order that must be followed. :)
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Cace, Andrew > Sent: Friday, September 23, 2005 5:21 PM > To: [email protected] > Subject: RE: [ActiveDir] Domain Controller Security > > We have a great TAM. The guy is extremely knowledgeable on a > wide variety of MS products. What he doesn't know, he knows > who to get in touch with in Las Colinas to get the right > answers fast. That's why I was shocked when I went to some > MS training on MIIS in San Jose, and heard the technical > people in the class bagging on TAMs and how non-technical > they tend to be. > > -Andrew > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Friday, September 23, 2005 4:37 PM > To: [email protected] > Subject: RE: [ActiveDir] Domain Controller Security > > Which on the whole you may find to be far more helpful than > most TAM's you might have gotten... > > Not trying to be mean, but I haven't had the greatest luck > with TAMs. There have been two in ten years that I can think > of off the top of my head that I liked (hey Efrem, hey > Michelle) and I still beat the crap out of them when I had > them available. Generally, IMO, a TAM is a person who tells > you what you can't have even if they don't know what you are > asking for. > > I once talked about looking into a TAM position and a high > level MCS manager who had been trying to get me to join MS > for I don't know how long told me (he was drunk at the time), > hell no, you are far too technically gifted to be a TAM... > > > Just a thought though mom, you guys in SBS land seem to stick > together pretty well. I wonder if you could form a union with > all of the SBS crazies (and I say that lovingly) and have > dues and such and then get a joint Premier Support Account > for all of you together and funnel issues up through it. > > joe > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] > Sent: Friday, September 23, 2005 1:45 PM > To: [email protected] > Subject: Re: [ActiveDir] Domain Controller Security > > Us in SBSland have newsgroups and MVPs. > > <don't have a TAM either> > > Brian Desmond wrote: > > > *Technical Account Manager. When you spend ample money with MS, you > > get one of these. I think a PSS contract is enough to have one. > > They're sort of your MS/Customer bridge. * > > > > * * > > > > **Thanks,*** > > **Brian Desmond*** > > > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > **c - 312.731.3132** > > > > > ---------------------------------------------------------------------- > > -- > > > > *From:* [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] *On Behalf Of > *DeStefano, > > Dan > > *Sent:* Friday, September 23, 2005 12:26 PM > > *To:* [email protected] > > *Subject:* RE: [ActiveDir] Domain Controller Security > > > > Excuse my ignorance, but what is a TAM? > > > > Dan > > > > > ---------------------------------------------------------------------- > > -- > > > > *From:* [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] *On Behalf Of *ASB > > *Sent:* Friday, September 23, 2005 5:46 AM > > *To:* [email protected] > > *Subject:* Re: [ActiveDir] Domain Controller Security > > > >>>And knowing it, I can always take extra precautions. > > > > The knowing it consists of "don't do it, because you can't > secure it" > > > > There are no extra precautions to take. Certainly, you can increase > > your auditing, but you could do that now without knowing > anything else. > > > >>>basically, 25% more prepared and secure against this type of attack > > is better than 0%. > > > > The more people that know, the higher the potential of > attack. And, as > > folks have pointed out, since there are no viable workarounds, it > > doesn't help anyone to have the number of potential > attackers increased. > > > > Call your TAM and see if he or she will provide enough > details for you > > to feel comfortable. > > > > -ASB > > > > FAST, CHEAP, SECURE: Pick Any TWO > > > > http://www.ultratech-llc.com/KB/ > > > > > > On 9/23/05, *Kamlesh Parmar* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > I have to disagree a bit here... > > > > Certainly, obscuring of information is not the way to feel secure. > > > > If I don't know, how it is done, then how do I know, that I will be > > able to detect it, and trace it. > > And knowing it, I can always take extra precautions. Which I think, > > better than not knowing it at all. > > > > basically, 25% more prepared and secure against this type > of attack is > > better than 0%. and certainly it helps calibrate how much > paranoid I > > have to be. :-) > > > > I would like to know, how it is done, as our team is currently > > migrating some good number of domains to single domain. And we are > > going to give local guys rights to logon to DC for some system > > maintenance purposes, till final single domain is cleaned up and we > > revert back to core team for day-to-day maintenance. > > > > So I am very much interested in knowing it. > > > > On 9/23/05, *joe* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > > wrote: > > > > The docs are wrong. Many of us have been hounding MS on this for > > years. They really started straightening out docs with K3. > Some of the > > older 2K docs still suggest this security boundary at the > domain. It > > really came to a head when Lucent put out a paper on this and it > > started getting quoted in the newsgroups and some of us just flamed > > the crap out of it. > > > > No one here or anywhere should really publish how to > exploit rights on > > a DC to take over a forest. The answer is pretty self-evident if > > someone understands the underpinnings and processes used in AD and > > since we can't fully protect against it, it is better left > > undocumented. If there was a guaranteed safe way to protect > ourselves, > > then we could publish that workaround and some time later > publish the > > issue. > > > > joe > > > > > ---------------------------------------------------------------------- > > -- > > > > *From:* [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> [mailto: > > [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>] *On Behalf Of > *DeStefano, > > Dan > > *Sent:* Thursday, September 22, 2005 2:09 PM > > *To:* [email protected] > > <mailto:[email protected]> > > *Subject:* RE: [ActiveDir] Domain Controller Security > > > > I thought that in ad domains are considered security boundaries. In > > the cert exams, namely the 70-219, they are considered as > such. Also, > > how would a domain admin of a child domain elevate his privileges? > > > > Dan > > > > > ---------------------------------------------------------------------- > > -- > > > > *From:* [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> [mailto: > > [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>] *On Behalf Of *Phil > > Renouf > > *Sent:* Thursday, September 22, 2005 1:28 PM > > *To:* [email protected] > > <mailto:[email protected]> > > *Subject:* Re: [ActiveDir] Domain Controller Security > > > > Even as a domain admin of a Child domain they will still be able to > > munge your forest or elevate their priviledges. The > security boundary > > in AD is at the forest, not the domain. > > > > Phil > > > > On 9/22/05, *Gideon Ashcraft* < [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > The only thing to do is to make him an admin of that site, > or better > > yet make that site a child domain and make him a domain > admin of that > > child domain. I know from experience that using a DC as > anything but a > > DC is a freakin pain in the ass, my predecessor set a DC up as a > > print/file server and another as a SQL server (finally able > to demote > > that one now, soon hopefully). But my citrix profiles are on the > > domain controller, and after months of trying to set delegation up > > properly in AD and setting up permissions in the > appropriate folders > > on the DC, the only way I was able to get my Helpdesk admin > set up to > > create accounts with my scripts so that I didn't have to do > it was to > > make him a domain admin. My company is too damn cheap to get me > > another server to put the citrix profiles somewhere else. > Oh yeah, and > > its an app server for network install of office (can you > feel my pain). > > > > So, if there is only one server in the site and its a DC, > the only way > > to get him to do anything is to make him a domain admin (make it a > > child domain so he can't climb up the tree) > > > > Gideon Ashcraft > > > > Network Admin > > > > Screen Actors Guild > > > > > > > > > > > > > > ct: RE: [ActiveDir] Domain Controller Security > > > > Look through the archives. > > > > The short answer is... "Just don't do it". You can't > possibly secure > > this regardless of what anyone says. If someone says it can be made > > safe, stop asking them technical questions about Domain Controllers > > and Active Directory. > > > > Either you trust the person or you don't. If you don't trust the > > person, then don't put the person in a position to show you the > > meaning of screwed. > > > > > ---------------------------------------------------------------------- > > -- > > > > *From:* [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>[mailto: > > [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>] *On Behalf Of > *van Donk, > > Fred > > *Sent: *Tuesday, September 20, 2005 4:52 PM > > *To:* [email protected] > > <mailto:[email protected]> > > *Subject:* [ActiveDir] Domain Controller Security > > > > I have a contractor in a remote site. There is only 1 > server in that > > site which is a DC. > > > > He needs to administer that server. > > > > -Create shares > > > > -Make file/share permissions > > > > -Change user passwords in the User OU for that site. > > > > He is not allowed to log on to any other server is the domain. > > > > When I make him a "Server Operator" he can logon to any > server in the > > domain. > > > > Any idea on how to lock him down to that one server and then how to > > lock him down on that one OU where he should only be > allowed to change > > the passwords of the users. > > > > Thanks! > > > > Fred > > > > > > NOTICE: The information contained in this transmission is > privileged, > > confidential, and intended only for the use of the individual or > > entity named above. If you are not the intended recipient, you are > > hereby notified that any disclosure, copying, distribution, or the > > taking of any action in reliance on the contents of this > transmission > > is strictly prohibited. If you have received this transmission in > > error, please notify Eze Castle Integration, Inc. by e-mail and > > destroy the original message and all copies. 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/ > 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/
