RE: [ActiveDir] Dynamic Groups

[Alex Fontana]

Hahaha…   While reading the very first sentence in the last paragraph I was thinking to myself, what was that app that our Engineers used to use (prior company) that wanted all of the users to have this_special_group as primary…  Clearcase...they are notorious.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, April 02, 2006 6:12 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Dynamic Groups   I am feeling fiesty and have a desire to write a lot and am actually having fun writing tech stuff so I will debate this a little. :o) I am not assuming what you do or don't know here Ulf, just using your note as a platform to document something for some folks who may not be aware because the actual functionality deviates from the commonly accepted/explained functionality.   ---   Logging off and logging on is the most obvious way to get the new token with the new groups however if the domain group isn't needed for access ON the local machine but instead for network connections you can possibly get benefit from updating the memberships even in the middle of the day depending on the circumstances. Obviously the first benefit is that people CAN actually log off and log on and get the access needed. However....   In reality the whole thing is only SEEMINGLY only tied to logging off and logging on. Why you ask? Because people like me have spent years trying to tie the logoff/logon to getting a new token together for support folks on the help desk and the users so they don't have to try and worry out the various intricacies of the whole token generation process because it is confusing and trying to do that on a regular basis is just going to confuse most of your L1 people when they could simply say log off and log on and get around the whole thing.   It is *much* easier and faster and consistent to tell someone, yeah log off and log after a group change versus asking them if they have connections or tickets to specific resources already and then doping out if they will get immediate access (or lose it) or not. And if they expect it will but it doesn't then all of a sudden you have a "problem" that you probably really don't have other than someone doesn't completely understand token generation and use and I am not even saying I understand all of it, in fact I am sure I don't. Plus you don't have to explain to management why it works sometimes but not others which is even more important than explaining to users because if it isn't explained properly it could mean a lot of extra make work for you when the manager thinks there is something that can be done there when in actuality it probably can't.     So.... you have something that is inconsistent unless you follow a very specific process at which point it becomes far more consistent and predicatable... What is the solution there? Architects/Integrators in the house? You document the process and tell people you HAVE to follow this or it won't work right and whap them when they don't follow it. This is usually enough to get people to follow the process (unless they feel they know better) and things work in a more predictable manner. It is usually the case that it is far more important that things be consistent and predictable for the L1 help desk folks and users than accurate to 30 decimal places and they understand all of it. If shooting for the latter, good luck, L1 isn't paid enough to try and learn token generation nor to care how it works. Some may want to but that isn't the norm from my experience.     So, solution there, the simple statement from Level 2/3/4 or whatever that you need to log of and log on to get your new token and hope that everything has replicated to where it needs to get to. Now if someone gets access before that log off and log on it can generate a question of "hey, I got access and didn't log off and log on" or I lost access and didn't log of and log on but those are generally easy questions to duck out on as that is the final goal of the change anyway and the L2/3/4 person being asked can say I don't know, how odd, scratch their chin, then duck out hastily looking for someone flailing with another problem that appears to be tough but is actually just a PC that isn't turned on. :)     So anyway, "everyone" knows that you carry your creds and token around with you like a little keyring that you get when you present your initial credentials, the various popular security gurus all say so. So it really isn't worth trying to tell folks that that is just the very very high (say 37k and blue skies) viewpoint and not what is happening in its entirety. If you told them that every time you touched a new machine you get another key ring to attach to your belt it starts to confuse the situation and the simple analogy breaks down for folks (but wait, how does that machine know what keys to give me, only the DC should know and he/she should give them to me right off, etc etc etc).   So after all of that, it is entirely possible to get added to a domain group and then find yourself with some new accesses on machines you haven't previously touched or machines where your connection/ticket has expired and been regenerated. So say I spin up a new resource server and put up a powerpoint on it and I want everyone to peek at it, I add them all to the new domain group that gives the access I could either then wait for replication and tell everyone to log off and log back on and then wham they get to see the powerpoint or I could wait for replication and then just tell people to go get the powerpoint. Both would work.   If you want to see this for yourself. Log on to a machine either interactively or with a runas/cpau "interactive" (i.e. not network) logon  and look at your token. Then generate a new group, global, universal, or domain local, create a new share on a machine you haven't touched since you logged on, set up access to the share via that new group. Wait for the replication, try to connect. Should let you right on. Doublecheck your token again for group memberships and you still won't see that group locally. Log off and log back on (or close and reopen the runas/cpau session) and voila, there is that new group.   Now I don't recommend trying to explain this to folks on the help desk nor the help desk folks trying to explain this to users, simply stick with the you MUST log off and log on as life is MUCH MUCH easier that way. However I trust the level of this list to mostly be above help desk and think this is useful info for y'all.   Helpful? Did I just waste time?     Oh! On to the original problem... Yeah it would be cool if something did this population automatically. If you ask MS for an answer it will be some 4 letter word, in this case, most likely it will be IIFP or MIIS. Obviously as Brian indicated you can write up a pretty basic script to do this, just be careful with it because you don't want to dork this membership if it is used to grant access to things. The best way would be to generate a list of all users in an OU and use a REPLACE LDAP update to overwrite what is currently listed in the group.   Confusion can come in on this one if someone is doing something with primary groups. As a general rule I tell people to NOT do things with primary groups. It usually just results in pain and suffering and beleaguered cries of "why why why?" when things don't work as expected and the developers and/or managers close in on the person and start devouring the hapless individual. Several UNIX ported and Apple type apps want you to use those groups. I say tough toenails to them, do it the Microsoft way or go find your own security database. A product called ClearCase is one of my most favorite products that I have had discussions with the vendor in this area. Dense is the best way for me to put the conversations I have had with them on this product over the last 6 or more years. Not sure how many times you can tell someone that primary group modifications will not be available and you need to figure something else before it will actually stick. I know I personally have done it at least 5 or so times in very ernest discussions and they still don't quite get it.   Err anyway, updating multiple times a day may or may not be a good idea, depends entirely on your circumstances, just make sure you have a good logging/tracking mechanism for watching and going back to the changes.       joe   -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm        From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Monday, March 06, 2006 3:51 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Dynamic Groups And keep in mind that it only works when users are logging off and on (at least for domain groups) so that the token is recreated - so running it multiple times a day is propably not practical. Gruesse - Sincerely, Ulf B. Simon-Weidner   MVP-Book "Windows XP - Die Expertentipps": http://tinyurl.com/44zcz   Weblog: http://msmvps.org/UlfBSimonWeidner   Website: http://www.windowsserverfaq.org   Profile:   http://mvp.support.microsoft.com/profile="">        From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond Sent: Monday, March 06, 2006 9:29 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Dynamic Groups Bryan-   Just write a script which runs as a scheduled task which enumerates all the users in an OU and checks that they’re a member of the group. You’ll also need to remove users who don’t’ belong in there anymore. Depending on the scale of your AD deployment (in terms of number of DCs and links between them) it may just be easier for you to clear out the group and repopulate it.   Thanks, Brian Desmond [EMAIL PROTECTED]   c - 312.731.3132     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lucas, Bryan Sent: Monday, March 06, 2006 3:06 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Dynamic Groups   I know you can build a dynamic query based distribution group, but can you do the same for a security group?  What is the best way to accomplish making anyone who is in a particular OU a member of a security group on a dynamic basis (scheduled task frequency)?   Bryan Lucas Server Administrator Texas Christian University (817) 257-6971