13 Replies Latest reply on Feb 28, 2012 12:50 PM by Bill Robinson

    Local user compliance on Windows servers

    Joe Piotrowski

      I have a list of local users that should exist on a group of Windows servers (2003 and 2008). I want to create some type of job in BladeLogic that checks to see if they exist or not and what groups they belong to. If they don't exist I'd like to have them added and put into the correct groups. Is there a best practice to go about this? I was thinking of leveraging a Component Template but I'm unsure if that's the best way to go.



        • 1. Local user compliance on Windows servers

          Yes, the best way will be to make use of the compent template and have Compliance rules to check for user and groups

          U can then associate blpackages capable of creating these users and groups for remediatin of compliance rules failure

          see out of the box compliance content for some guidance !

          • 2. Local user compliance on Windows servers
            Joe Piotrowski

            Thank you Rohit. I need more specific direction however. I reviewed the Windows Server 2003 and 2008 OOTB Compliance Content and there is nothing regarding looking for the existence of specific Users and what Groups they belong to except the Administrator account. And there is no remediation (add user) for that.


            I can think of a few ways to do this, but I'm looking for the simplest and most straight forward. Here are the three I'm considering:


            - Have all the Users and Groups I want to check for already added to a server, then take a Snapshot of the "Local Users" and "Local Groups" and use this to Audit against other servers. But I'm not sure if I can Remediate this way and I'm not sure how BladeLogic will handle passwords and SIDs.

            - Add each User and Group into the Depot as BLPackages. Create a Component Template with these Users and Groups as Parts. Run existence Rules against these Parts and use the BLPackages as Remediation.

            - Create a Component Template with an Extended Object that contains a list of users in a Custom Property Class.

            • 3. Re: Local user compliance on Windows servers
              1. The audit option is possible. Create a `Golden Master` with all the local users and local groups, take a snapshot of it and make it a master in the audit job. You can remediate in that way by using the "Sync with master" option in the audit results. You should know that this operation is manual and cannot be executed automatically (unlike the auto-remediation). On the sync with master option the appropriate BLPackage is generated automatically and deployed to the specific server (once you initiate the manually the sync with master).
                • Pro: the remdiation packge is 'tailored' specifically to the target with the missing users and users group. No need to create BLPAckages manually.
                • Con: the process should be initiated manually (no option for automation).
              2. The first component template option is also possible. In case each target will have a different set of users and groups (which I guess this is the situation), you'll have to create specific rule for every user and every user group and for each rule set the correct BLPackage (with the corresponding user and user group). The only thing which I'm not sure (and should be tested in case you'll select this option) is what happens in case a user and his group are missing from the target - will the remediation first add the user and then add the group (and set the user to be in the group) or will they both be deployed at the same time and then the user will not be in the users group.
                • Pro: the process is automatic (you can execute the complaince job and if the target is not compliant it will be fixed automatically).
                • Con: need to create a rule and remediation package for each user and user group. This might be complicated to maintain.
              3. I don't fully understand what you intend to do with the EO so I can't tell if it is simple or not.

              Bottom line: if you want to execute this compliance test once, the audit option is better. If you want to check compliance peridically, take the compliance job option.

              • 4. Re: Local user compliance on Windows servers
                Joe Piotrowski

                Thank you very much Nimrod. I'm going to do some testing and will report back the results and any additional pros and cons I find.

                • 5. Re: Local user compliance on Windows servers
                  Joe Piotrowski

                  For my test I created two users (User1, User2) and two groups (Group1, Group2) on a Windows 2008 server. I added those users into my groups. I then took a Snapshot of the entire "Local Groups" and "Local Users." Then ran an Audit job of that Snapshot against a target server. I found some interesting results.



                  1. BladeLogic intelligently filtered out all the users and groups except the ones I created. Very nice.

                  2. The Audit job worked perfectly. I like that you can "Sync to master" or "Package Delta" directly from the results.



                  1. I initially liked that when you created the remediation BLPackage it included all the depends. Meaning, it added User1 as well as the Groups it belonged to; Users, Group1 and Group2.

                  2. Unfortunately, this causes my deployment job to fail. When I attempt to deploy the User1 package it fails with;

                  PreCondition "GroupExists" failed - Name = "Group1"

                  3. So I figured I could just deploy the Groups remediation package and it fails with;

                  PreCondition "UserExists" failed - Name = "User1"


                  So it looks as though I'm in a circular loop. I'm assuming I will have to remove the user references in the group package, and remove the group references from the user package. Then run the groups deploy job first, followed by the user deploy job.

                  1 of 1 people found this helpful
                  • 6. Re: Local user compliance on Windows servers

                    Why remove the user from the group package AND remove the group from the user if you deploy the BLPaclage sequentially? In that way the users will not be in the groups. You need to remove the references only for the first package you deploy. Let's say you removed the users from the group BLPckage and deployed it - now the group exists on the target. When you'll deploy the user BLPacksge (with reference to the user group) the user will be deployed and added to the user group.

                    I guess that you'll have to use the compliance job after all. If so you have to use very simple rules (for example User: "XXX" exists).

                    1 of 1 people found this helpful
                    • 7. Re: Local user compliance on Windows servers
                      Joe Piotrowski

                      You are absolutely correct. I came to that same conclusion when I was stripping out the users from the groups deploy job.

                      • 8. Re: Local user compliance on Windows servers
                        Joe Piotrowski

                        Worked like a charm. It strips the password when it creates a user BLPackage which makes sense. But you can set the password (encrypted) within the package properties. However, I was surprised it also stripped other attributes like "User must change password at next login."


                        Thank you for all your help.

                        • 9. Re: Local user compliance on Windows servers

                          I will check the missing "User must change password at next login" attribute (it seems like a defect but I want to double check with the dev person who is responsible for packaging objects).

                          • 10. Re: Local user compliance on Windows servers

                            It seems that the behavior you described (not taking all attributes) is as designed. The best way to handle it will be to open a ticket to fix it.

                            • 11. Re: Local user compliance on Windows servers
                              Bill Robinson

                              Changing the passwd is a different operation than setting the user attributes I think.

                              • 12. Re: Local user compliance on Windows servers

                                For now, can’t you run either net user or wmic useraccount to set these attributes …

                                Also there are things that need to be set using net accounts vs net user …


                                Specifically for "User must change password at next login." – this can be done for domain users but not local users via dsmod  and –mustchpwd yes or admod and pwdLastSet::00 <-- but this doesn’t work for local accounts.

                                • 13. Re: Local user compliance on Windows servers
                                  Bill Robinson

                                  You can still do this w/ a blpackage, but if you select the action of change passwd, I’m not sure if you can set the state or not.  pretty easy to test.