Rick, Got a minute to chat off-list? Don't know if your @cox.net addy is still live. Sincerely,
D�j� Ak�m�l�f�, MCSE+M MCSA+M MCP+I Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon ________________________________ From: [EMAIL PROTECTED] on behalf of Rick Kingslan Sent: Sun 6/12/2005 7:02 PM To: [email protected] Subject: RE: [ActiveDir] mstsc /console switch for non admins "other members of their particular market segment get hit, or their customers start worrying.... " In my case, the other folks that were being lied to (outside of the Cxx's signing false documents and the Auditors collecting bad information) ARE the customers. They are being told that the correct practices (Such as CISP, etc.) *are* being followed and adhered to. Bull-Hockery... Rick ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ASB Sent: Sunday, June 12, 2005 8:36 PM To: [email protected] Subject: Re: [ActiveDir] mstsc /console switch for non admins >>Hopefully this will change now that it seems there is a company a day releasing that customer information has been compromised. Ha. Everyone thinks that OTHER companies make mistakes, but not them. Plus, most Senior Managers aren't going to see it as a problem unless the other members of their particular market segment get hit, or their customers start worrying.... -ASB On 6/12/05, Douglas M. Long <[EMAIL PROTECTED]> wrote: Hopefully this will change now that it seems there is a company a day releasing that customer information has been compromised. Here in Ohio, the state actually decided to sue DSW for such a thing (which is the first legal action in the states, I think). I know how politics works, so who knows, nothing may come of it, but lets hope. Management seems to worry about making everyone happy on the surface. "We will increase productivity, ease of use, and your overall experience." But lets not tell them that is at the risk of security by implementing it to allow such ease of use. Oh well, good luck on your job search. I may some day get canned for the exact same sort of thing. ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Friday, June 10, 2005 11:30 PM To: [email protected] Subject: RE: [ActiveDir] mstsc /console switch for non admins joe, Yeah, you had to know it was coming - Rick's $.02 worth. Remember what we both were relieved of our positions for? Oh, that's right - I didn't tell you about me! Suffice it to say I took one for my team because upper management was trying to get things done that were wrong, technically, tactically and strategically. They, in fact, are on the verge of violating, IMHO, Sox 40x controls. I complained, I argued, I provided information that they were on the precipice of something really bad. Apparently, I finally hit nerve and my rubbing of folks the wrong way (from their viewpoint) caused my layoff via 'Elimination of my position'. Whatever. I got fired for saying what I believed was right. You and I see eye to eye as it is with DC permissions and access controls. You and I see eye to eye on security as a whole. However, our view is not really a well accepted PRACTICE in Corporate environments. Our beliefs are actually radical when compared to the norm in practice. Does this mean that we're wrong? No. It DOES mean that our Secure Conscious viewpoint can still get one fired. It's not a popular stance to say "Of my 10 Systems Admins, only these two can log on to a DC." The common rebut is "Everyone needs to be able to do these functions when on call" or "when the help desk calls, we need everyone capable of dealing with the problem at hand". I still believe that we are correct, but - most folks don't live in "Rick and joe-land". They live in the screwed up Corporate world where the only endgame is money, and the generation of it [1]. With IT being a cost center, and Security viewed as an even bigger inhibiter to Production, most companies need to have a * Serious* computer security event to be convinced that they have their priorities in the wrong places. Money generated doesn't matter if you can't guarantee that you can SECURE your customer's money / data / private information. Rick [1] Case in point. One of the guys that I used to work with was told that one thing management was really pissed about was the time it would take me to lock down a server. For estimation purposes, I told folks to plan for (and published a timeline for planning purposes) 2 days for initial lockdown, 2 days for final lockdown and application of IPSec filters, and 3 days for InfoSec to certify the system (The time for InfoSec is THEIR guideline from their VP - not my timeline at all). Typically, I would have a server back to the application team the same day to apply their apps, and would take one day to do the final lockdown, apply IPSec, and scan it before sending to InfoSec (yeah, I'm kind of funny that way - I like to KNOW what the scan looks like before I send it for certification). Typically, it would take the application folks (who were the ones that complained about the time * I* took) about 2 - 3 weeks to get their applications on to the box. Now for the funny part. No one else has a clue how to do what I was doing Nada - nothing. Nobody wanted to learn the boring, mundane, and highly visible process of hardening servers for the perimeter and DMZ. So, other Supervisor gets this server that needs to be hardened. He assigns it to my friend and tells him, "I don't care if you know how to do it or not - just do it." He then proceeds to instruct him to just tell InfoSec you have a server to scan. When you get the vulnerability report back, just fix what shows up as problems and send it back over to them for certification again. "And, I need it by Friday, end of business..." How long did this 'abbreviated, BS, crap, end run, corner cutting hardening method for losers' attempt take? Three days. Yeah. They shaved a whole bunch of time off of my usual time to delivery. <G> R ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, June 10, 2005 10:33 AM To: [email protected] Subject: RE: [ActiveDir] mstsc /console switch for non admins I received a some offline questions on this that can be collected into three main questions 1. What are the things these non-admin but natively enhanced users do to compromise the DC or enhance their permissions? 2. What would you do in this situation? 3. SBS seems to contradict everything you say, MS obviusly doesn't have an issue with these things all being together. The first I will not respond to in any real detail. I do not want a response from me becoming the guidebook for evil people on how to escalate privs on a DC and compromise a forest, I am not thinking any customers I help would be appreciative of that because there really is no feasible way of locking this stuff down. Suffice to say that someone in that position can run anything they want to on the DC and can easily get a security context over and above what they should have. If you want the simplest stupid thing that could be done is they could put a trojan on the box that some silly domain admin runs. Alternatively, because this is a higher bar item I will mention it, servops can load drivers. Say like a keyboard driver...Those are the hard ways to get things done. The second is tough, it depends on the specific situation. However those that have worked with me on projects directly know that if a hard problem comes up, I can become pretty creative. If I am responsible for the security of a domain controller, I can be extremely creative. First off, print sharing. I wouldn't do it through the DC, most corporate printers now are connected through the network and have their own queuing mechanisms, use them. If it has to go on a DC, I as a domain admin, would handle all server based operations around it. I would not delegate it directly. As I had time, I would whip up a web based proxy system to give others the ability to do limited operations scoped by specific business rules on the print queue, such as being able to clear it maybe. I have done this in the past. Second off, file sharing. Again, I wouldn't do it through the DC. I think setting up file sharing through a DC is one way to lower your availability of f&p shares. Domain controllers sometimes have to be rebooted to clear various replication issues. The key components are so deeply embedded in DCs that you can't just stop and start pieces. MS is working on that, but at the moment, it isn't there. If you have a replication issue or authentication issues, do you boot everyone out of the shares so you can fix it? If so do you go to everyone's desk to make sure they properly close the Office Docs so they don't get corrupted? If I had to do it, again, domain admins would have a new job, managing the file share info and backup processes. The file shares would not be on any physical disk with my OS or AD files. I would work on delegating off specific items through a web proxy again with specific business rules. I would also make it so the stuff created could NOT be regularly accessed by Domain Admins (only allow backup access which is handled through different perms). This could be overridden so I would set up a process that constantly was rewriting ACLs on the shares and the folder structures. Reason being, you don't need some admin accidently running some program that some knuckle head uploads to the server that can cause harm if run by someone with a lot of rights. But wait, domain admins need to be able to work and they keep files on those servers to.... Domain Admins should not be using Domain Admin IDs for most work, they should only use those special IDs when they are purposely making changes or looking at something they absolutely can not get to without the domain admin ID. I was a domain admin for a long time, by far, most of my time was spent using a normal userid for troubleshooting and daily work. The third question, SBS. Do not take your environment security and operations cues from SBS. SBS is a very specific product for a very specific niche. It comes with you having to understand that you are compromising best security and system operating practices strictly for the sake of saving money. Microsoft isn't saying these things are ok to do, they are saying, hey there is a market here and we are going to take advantage of it, if the customers are willing to assume the risk to save the money we are willing to supply the product for them to do so. If any decent sized company started running their environment by spinning up DCs with all SBS services and got MS in to do a review MS would almost certainly report issues with it. SBS is the solution when cost overrides security very early on in the game. If someone ever comes up with something to target SBS by coming through one of the many possible penetration vectors and then targeting the domain controller aspects, there are going to be a lot of small businesses that are really hurting. Imagine, if you will, an attack that comes through one of the random and many services on the machine and gets localsystem access rights and takes over the machine. That attack can now successfully eat every other machine in that domain. Done properly, an attack here would completely wipe out all Windows computing cabability of the business very quickly and very easily. This is why you always run as few services and people with access rights on Domain Controllers. The more vectors for attack you have, the more insecure you are. Add to that that a domain is NOT a security boundary. I won't describe the mechanisms but someone you give serv op rights (or even less) to in one domain one night could find you looking at that same person with Enterprise Admin rights the next morning while you have no rights to correct it without hacking the DC at a core rather unsafe level. joe ________________________________ From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] On Behalf Of joe Sent: Friday, June 10, 2005 10:30 AM To: [email protected] Subject: RE: [ActiveDir] mstsc /console switch for non admins Honestly any time someone asks a question like this my response is make them domain admins because any time they want it they can take it and making them server ops is just a way so you can report you have fewer admins, basically you are adhering to the letter of some rule instead of the intended spirit. Someone who gives enhanced rights less than administrator on a DC to someone either doesn't understand how Windows works (nor Forest security) or assumes that the people they are giving the access to don't know how it works or how to enhance themselves. The bad thing is they may at some point those untrusted people may run some program that does know how to enhance those permissions OR they learn how to do it themselves. Basically what security do you think you have by not giving them domain admins right up front? This has been a popular discussion point over the years on this list. Look through the archives. This also goes for people who allow other non-admin groups to run things like monitoring, Software Delivery, Auditing, and distributed AV solutions that have services running on DCs as local system or with other high privileges that allow ad hoc software load or process execution. joe ________________________________ From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] On Behalf Of Frank Abagnale Sent: Friday, June 10, 2005 4:57 AM To: [email protected] Subject: [ActiveDir] mstsc /console switch for non admins Hi, Our IT Operations team will require access to our remote Windows 2003 DC's which act as File & Print Servers. At the moment, they are members of the Built-in domain Server Operators group which they use Remote Desktop to connect through to the DC's for data/print services support/administration which gives them the remote access they require. I would like them to use the mstsc /console switch however, it seems only members of the domain administrators group can use this switch as they are unable to logon. The IT Ops user can logon to the server via the physical kvm console using the same account and have access. Only through mstsc /console are they denied access. The Server Operators group have the following rights: Allow logon through Terminal Services Log on Locally Does anyone know of a way around this so I can allow Non-Admins use the /console switch? Any ideas or alternative workarounds appreciated and I already understand that Non-admins are not supposed to logon to DC's but due to politics we have to allow this...for the time being. Thanks - Frank 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/
