I obviously have to agree with Jorge here. Allowing non-DA users to manage the file system and drivers and services on DCs is not a good thing - ever. When you do that and you don't make the person doing it to be a DA, you are simply depending on the fact that the individual involved is not aware enough to compromise your environment. Unfortunately, they may learn or something they may run may have that knowledge. Basically an untrusted person has too much power over your core security. How do I know they aren't trusted, you didn't give them DA.
If you use DCs for print servers, you need to have it so that the DA group manages them or you proxy it through some form of interface. Back in the old old days of NT4 SP3 or so I worked at a company that had a situation where we had a dual print queue system, the 4 DCs for the resource domain were one level of queues that simply dropped the print output to a second level of printer queues on member servers. This was done due to some interesting issues with mainframe printing, OS/2 printing and some other things, basically if you want to visualize it, 4 DCs fed documents to something like 8 or 10 print servers but not all users connected at the DC level, in fact most connected at the member print server level. In order to delegate off the ability for Level 1/2 Help Desk to clear/pause/restart/etc print queues (things that in the world of a DA really isn't important) on any of the servers, I had built a web site that took requests from specific people and did the clearing of queues, etc. If it came down to installing a new printer driver, that was done only by the DA group after they tested and verified everything. That web site also allowed group membership modifications, disk quota management (we used Quota Advisor I think), software delivery management (we had our own home grown setup which was based on a perl service), password resets, and some other company specific admin stuff. I actually wrote it as a skunkworks project an hour or two a day for a couple of months. I had recommended it as a solution as our group managing servers was only 3 people[1] and we managed something like 40 or so servers (4 DCs and about 35 members) and was told it wasn�t a viable solution and not to spend any more thought on it. In fact I was even told that the web/HTML stuff wouldn't amount to much and that was the primary reason not to do it. So on my own time for a couple of months I put together a very crude looking environment based on simply text forms but with a solid flexible backend that had a lot of business logic built in in a fairly flexible extendable way and logged everything. All in perl and a couple of services I wrote to execute stuff passed insecurely from a web site securely as an admin. once I was close to being done with the main backend components so that they were bulletproof, I let some of the support folks silently beta test the tool to verify it fit their needs, they were after all the customer and the customer should have some say in the products they use not just be told what to use from management[2]. It was an immediate hit with them because they could fix things quickly and they had no fear they would screw things up. When I presented it to the manager who told me not to do it in the first place he told me to make it immediately fully available and announced it to everyone like it was some big project the Office Automation department had been working on for months. I was then told to beef up the interface to make it prettier which only took a couple of weeks since all I needed to do was change the background from grey to white and introduce some nice fonts and images on all of the pages. Several of my friends thought I was an idiot for doing it because I was burning personal time building it, it ended up being probably 200-250 hours of personal time but was used by that division and later by other divisions I moved to for years and saved me and others tens of thousands of hours of "make work". It slowly grew year after year as I added more functionality to it. An interesting side story was that the machine that ran that web site was a desktop PC. Very simple little machine. The backend database was Access (not my choice, I used what was available). The system was built such that as long as the standards were followed for new shares being created on file servers and for new printers and for everything else it dealt with it would auto discover resources and add them to the site every 12 hours. The only management was through connecting to the Access DB and was adding/removing of admins and setting their permission levels (can restart queue, can purge queue, can deliver software, can reset passwords, etc) and adding new servers to the server table or removing old servers. I had great fear that some "knowledgeable" admin would come along and try to "fix" the system when I wasn't looking so I put a little trap on the machine. It was configured to not directly allow local logon for anyone. I didn't do it in the regular way, I dorked with the default profile so that when a user who had permissions to log on, logged on, a script in the profile would log the user back off[3]. This was immensely successful and I had a log of everyone that tried to log in... The profile directory. My thought was any admin not "knowledgeable" enough to understand how that was done, wasn't "knowledgeable" enough to be messing with that system. I played a hunch that if they weren't "knowledgeable" enough to understand, they wouldn't be "knowledgeable" enough to manipulate it in bad ways remotely. All and all, it was a roaring success, that system went and went for a loooong time with no issue. I had spoken with one admin whom I knew to be knowledgable and had discussed with him how it had been done (basically I said if it did this and this, what would you look at it and he nailed it in about 45 seconds). That way I wasn't the only one who knew and I knew this admin wasn't into casually changing things, a great admin, naturally constructively lazy. When I eventually left to go to another division I was one day called and a new admin was saying he needed to log on and change some stuff but couldn't figure out how to log on. I didn't give out the info. Then the manager called and I told him who knew how to get on. A few weeks after that, I was contacted by them again, seems they made some modifications to the system and now it was dead on the floor. I laughed and told them good luck. I figured if I went in and figured out how it broke and fixed it for them they were no better off, they were simply running. This way, the pressures was on for the person who broke it to fix it and thereby understand the system a little. It was broken for some time, eventually it got fixed. I believe the issue at the time was that they updated the DAO/ODBC stuff. Back then DAO/ODBC stuff was terribly buggy and any given version of it worked very differently from any other version and if you changed something there were even odds you would have to rewrite sections of code to make it work again. joe [1] Three people always seems like the magic number of the teams I am on. [2] Clueless or otherwise. [3] I have also been known to set the default shell to be command prompt, this really kills many Windows Admins. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge de Almeida Pinto Sent: Sunday, May 22, 2005 10:24 AM To: 'TIROA YANN '; Jorge de Almeida Pinto; '[EMAIL PROTECTED] '; '[email protected] ' Subject: RE: [ActiveDir] Adminsdholder Propertiy Qustion... For the sake of security you could move the print server role to other server(s) in your environment that are member servers. In this case you cannot use the print operators group if a member server is the print server. You need at least permissions to: * Create printer instances * Install printer drivers * Share printer instances * Manager the printer instances Or let the designated domain admins do those tasks I don't know how to configure this only. If a print admin is a member of the local admins group on the member server I'm sure he has enough power to manage printing on that member server... Maybe someone else on this list knows how to specifically delegate the print admin permissions as mentioned above on member servers with giving away the local admins group membership Cheers #JORGE# -----Original Message----- From: TIROA YANN To: Jorge de Almeida Pinto; [EMAIL PROTECTED]; [email protected] Sent: 5/22/2005 3:56 PM Subject: RE: [ActiveDir] Adminsdholder Propertiy Qustion... Hi Jorge, WAAOOU ! Endeed i was not aware that print operators group was able to log on to my DCs and do task as reboot !!!!!! And yes,my DCs are also prints servers..... maybe it's not good for security... but it's hard to convince my direction to buy a server ONLY for printers purposes..... So i'd better review the best security practices as you suggested rather than "playing" with the adminsdhlder.. Thanks for your feedback. ;-) Regards, Yann Cordialement, Yann TIROA Centre de Ressources Informatique. Campus Scientifique de la DOUA. B�t. Gabriel Lippmann - 2 �me �tage - salle 238. 43, Bd du 11 Novembre 1918. 69622 Villeurbanne Cedex. -----Message d'origine----- De : Jorge de Almeida Pinto [mailto:[EMAIL PROTECTED] Envoy� : dimanche 22 mai 2005 15:18 � : TIROA YANN; '[EMAIL PROTECTED] '; '[email protected] ' Objet : RE: [ActiveDir] Adminsdholder Propertiy Qustion... Hi, Have you seen "Delegated permissions are not available and inheritance is automatically disabled" (http://support.microsoft.com/?id=817433) This article describes how you can configure which default protected groups are protected or not by the adminsdholder object. Although possible I do not recommend it as there is more like I mention below. You are using the group "print operators" to manage printers, so this means your DCs are also print servers. Is this correct? Are you aware that the admin that manages the OU and its child objects (has Full Control) can log on to your DCs? That admin can change the password of the user that is a member of the print operators. After that he can use that user's credentials to log on to a DC. Why? By default print operators have ability to logon to DCs and do some stuff like shutting down the DC and load and unload device drivers (install printer drivers and others) I'm not sure if you already do it, but I recommend to distinguish between normal user accounts (to read mail, create documents, etc.) and admin accounts (to do all kinds of admin stuff). In my opinion each admin should logon to their workstation using their normal user account and do admin tasks using the RUNAS option. It is better however to have a separate workstation (or TS or Citrix) (protected like other servers) to do admin tasks. Using his normal workstation the admin user sets up a terminal session using RDP or ICA to the ADMIN workstation and does this things Cheers, #JORGE# -----Original Message----- From: [EMAIL PROTECTED] To: [email protected] Sent: 5/22/2005 2:39 PM Subject: [ActiveDir] Adminsdholder Propertiy Qustion... Hello ;-) I had a strange issue yesterday. An administrator who has full control(ct) of his OU and the child objects, was not able to modify a user account properties or password. The security option of the user object shows that the admin was not on the user object acl: the inheritance case that allows the parents to apply to this object ...was disabled !! After searching on the net, i have found that the adminsdholder was responsible for that. Endeed, user was member of print operators and thus is protected by adminsdholder throw his membershhip of this protected group. So i enabled the inheritance on the security option of the adminsdholder attribute, wait for less than 1 hour that PDCemulator "do his job", and checked that user object has the inheritance case activated: that's was OK and delegated admin was enjoyed ! :-) BUT, for my personnal interest, i think disabling the inheritance of the adminsdholder in not a good option d�e to security pruposes. So in this case, how can I just enabling inheritance of only this user acl without enabling it on the whole adminsdholder so the OU's admin have full ct on the user object. I also would like the user to continue to be member of the print operators. Thanks for your expert advices :o) NB: do not bother about my poor english writing and be indulgent 8-) Regards, Yann 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 e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. 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/
