• Home
• About
• Advertise
• Contact
• Search

Using restricted groups in Active Directory

by Mats Hellman on 21.Oct, 2009 under Active Directory, Group Policy, Windows

Using restricted groups is something very simple and still for many very confusing. Using restricted groups you can delegate administration or other roles to certain groups without giving these groups administrative rights to your Active Directory.

As an example, let’s say you have a helpdesk working in your company. For them to work as efficiently as possible they might need to login as Administrators to a client computer to fix various problems. Sometimes (read most times) you don’t want your helpdesk having Domain level Administrative rights because they might, even unknowingly, mess something up in your production domain. To deal with this we use Restricted groups. Restricted groups are provided by Active Directory group policies, they provide us a way to centrally drop in certain Active directory groups to computers local groups, yes computer local groups. They don’t have to administrative groups, they might be anything from backup users to Power Users.

(more…)

1 comment

Upgrade to / install Adobe Acrobat Reader 9 centrally using Active Directory group policies.

by Mats Hellman on 20.Aug, 2008 under Windows

In January 2008 I published an article Installing Adobe Acrobat Reader centrally with Active Directory group policies. The time has come to upgrade to Acrobat Reader 9 now. So I’ll be taking you through some simple steps today to get that part done.
If you want to push out Adobe Reader for the first time I suggest you follow the old guide located at http://www.nixadmins.net/node/317 and substitute everything Acrobat 8 related with 9.
What you need to complete this how-to is the Adobe Customization Wizard 9 and Acrobat Reader 9.

Download links:
Adobe customization wizard 9:
http://www.adobe.com/support/downloads/thankyou.jsp?ftpID=3993&fileID=3727
Adobe Reader 9
http://www.adobe.com/products/acrobat/readstep2.html?promoid=BUIGO

Getting the MSI package

As you might have noticed the Acrobat Reader 9 is a .exe file. It does include a MSI we just need to get it out of there.
Run the install from a command prompt or a run field.

You will find your fresh adobe packages in
Windows XP
%Userprofile%\Local Settings\Application Data\Adobe\Reader 9.0\Setup Files\READER9
Windows Vista
%userprofile%\AppData\Local\Adobe\Reader 9.0\Setup Files\READER9
Copy out all the files in that directory. I copied them to the desktop.

Let’s get on to the customization wizard.

Modifying the Adobe reader 9 installation package

Now that we have the MSI package we can start modifying it. So start up Adobe Customization Wizard and open your fresh MSI and let’s get started.

Now you should read and understand the settings in the wizard. And also read the End user license agreement (EULA). If you select not to show it YOU agree with it for your whole organization.

The following are the settings I changed.

• Installation options
  • Make Adobe Acrobat reader the default viewer if Acrobat and Reader are installed. I set this because there are some new features in reader 9 and our organization still uses Acrobat 8.
  • Enable optimization
  • Enable caching of installer files on local harddrive
  • Run installation silently, we don’t want the user to participate at all in the process.
  • Suppress reboot, users reboot often enough and most our computers are set to install updates 3 A.M so they will reboot soon enough.
• Shortcuts
  • I left Programs->Adobe Reader 9 but removed the desktop icon. I see no reason at all in having it clutter the desktop. Most I’d guess over 99% of users click the file to open not start up Adobe Acrobat reader and then open the file.
• EULA and document status
  • Suppress display of End User license agreement. I really don’t want the users to see it. Bu be sure to read it yourself BEFORE you accept it.
  • Hide document message bar
• Online and Acrobat.com features
  • Disable all updates, I want to see to the updates myself, to keep application compatibility.
  • Load trusted root certificates from adobe, check Enable and install silently
  • In adobe reader, disable Help purchase of Adobe Acrobat. All our software is bought by the IT apartment, not single users.
  • Disable product improvement program. I really hate theese.
  • Disable viewing of PDF with ads for Adobe PDF
  • Display in browser, enable
  • Disable all acrobat.com access including initiation and participation.

That’s it, now save the file and copy all the files to the fileshare you use to deploy software, in my case \\server\userapps\Adobe Reader 9. On the next page we continue with assigning the policy to the computers in your organization.

Working with the policy

Start up your Group policy management console and select your Software installation policy. Select edit, go to Computer Configuration\Software Settings\Software Installation.

Right click and select new package. Browse to the folder where you dropped the MSI and INI file. Select the file and choose open.

At the deploy software screen select Advanced to check the following.

At the Upgrades tab you should see Upgrade Adobe Reader 8.?.?.

Checking the old Acrobat package

This is not generally something you have to do but I like to check and double check before I expect results. So select the old acrobat package and bring up its properties.
Go to the tab Upgrades where you should see the Adobe Reader 9 package.
That’s it, now you can push this out to your test environment and see that everything is working like it should.

Command line tools

Group policies are queried over a period of 30-180 minutes. This is to ensure not all computers query at the same time. So to speed it up you can use.

To check which policies are applied to a user/computer you can use

This lists all the policies applied to the computer you are at and the user logged in.

Final words

Working with Active directory group policies is a really straight forward process. If something doesn’t work check your event viewer for errors. I’ve even seen out of date network card drivers halt the whole group policy deployment.
If you need help with this comment here and I’ll try to get you trough the process.
I take no responsibility if this doesn’t work or setting this up makes a mess at your organization. This article is written only to help on the way and you should know what you are doing, not just “copy & paste”.

17 comments

Find stale / dead / removed computers or users from Active Directory using oldcmp from JoeWare.net

by Mats Hellman on 12.Aug, 2008 under Windows

I noticed our Active Directory domain and Windows Server Update Services had a small difference of about 200 workstations.

The forgotten computers

Naive as I was I never thought that we could “forget” 200 workstations in our domain. So I had to find a tool to get the job done. Luckily I found oldcmp at Joeware.net. This small 222kb tool promised to do what I needed done and I could even get a report in HTML, CSV or DHTML.

Using OldCmp

The use of this program is more than simple, but beware, don’t use delete unless you really now the computer accounts are dead.
The program has a few safeguards to keep you from doing something really bad, so I won’t show you anything other here than how to get a report from your Active Directory. If you want to delete or disable computers read the help.

Listing computers that haven’t changed their password in 90 days

Getting some help

Listing computers that haven’t changed their password for more than 120 days

I settled for computer that haven’t changed their password for more than 120 days, there were still a few computers in use, but we quickly sorted them out and could now disable almost 200 computer accounts from our Active Directory.

Users instead of computers

You can also check dead users by giving the program the user switch.

The above obviously checks for users who haven’t changed their password in more than 120 days.
Also check out the other magnificent tools you can find at Joeware.net.

Leave a comment

From installation to Active Directory client with CentOS 4.2 – Part two

by Mats Hellman on 22.Aug, 2006 under Linux

This is the second part of an article I started a _long_ time ago explaining how to connect a Linux desktop to Microsofts Active Directory, this time with the CentOS distribution. The first part can be found here. Hopefully you now have CentOS setup and are getting eager to get the domain logins working. We will get to that in a minute. First let’s discuss the process overall and what you already need to know or have setup. This guide has no guarantee on working, you should also backup any important data before proceeding. If you run in to trouble post in our forums and we’ll do our best to help you. A good practice is to backup the configuration file you are about to edit, so if you run into problems you can reset it to the original file. Remember, playing with authentication can get you locked out of your system!

You need:

• Working Windows domain with Active Directory.
• CentOS 4 installed on a desktop or virtual machine (VMWare, Microsoft Virtual PC or server).

Also you need to have the following information at hand:

• Your Windows domain name.
• The name of the Active directory domain controller.
• User account and password for an administrative account in the domain.

That’s it. Now let’s get on with configuring the system.

In this article:

• Installing OpenLDAP.
• Configuring Samba .
• Starting the winbind daemon.
• Adding the workstation to the domain.
• Configuring /etc/nsswitch.conf
• Testing winbind
• Testing Windows to Linux account conversion.
• Editing /etc/sysconfig/samba.
• Editing PAM settings.
• Starting the daemons.
• Further reading.
• Troubleshooting.

Installing OpenLDAP.

Well start by installing OpenLDAP and the clients also we need nss_ldap. YUM handles the installations for us nicely so we don’t have to worry about dependencies. Just fire up a terminal because that’s where well spend a lot of time in this part of the article.

[root@wrkst1~]$yum install openldap-clients openldap

Configuring kerberos.

When OpenLDAP is installed we can move on to configuring the different authentication handlers. Let’s start by configuring the network authentication protocol Kerberos.
We need to tell Kerberos the windows realm and a few other things. Kerberos configuration file resides in /etc/krb5.conf so fire up your favourite editor, I’m using both Emacs and Vi depending on the situation so no editor wars here, and open the file for editing.
You should see something like this:

[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false [realms] EXAMPLE.COM = { kdc = kerberos.example.com:88 admin_server = kerberos.example.com:749 default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }

Now let’s edit the file. You did back it up like I told you didn’t you . Remember this file IS case sensitive, so default is not the same as DEFAULT. Remember to change the values if you copy/paste.

#/etc/krb5.conf

[libdefaults] ticket_lifetime = 600 default_realm = NIXADMINS.NET default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc [realms] NIXADMINS.NET = { kdc = ad-server.nixadmins.net default_domain = nixadmins.net } [domain_realm] .nixadmins.net = NIXADMINS.NET nixadmins.net = NIXADMINS.NET [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [logging] kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmin.log default = FILE:/var/log/krb5lib.log

Save the file and exit. Next let’s make the system a little more error tolerant, in case the DNS service goes down the workstation won’t be able to authenticate the domain users so we add the Active Directory PDC server to the /etc/hosts file. Add the following line to /etc/hosts:

# /etc/hosts

1.2.3.4 ad-server.nixadmins.net ad-server

Next we need to test to see if our Kerberos settings are working. Just type the following in your terminal, all it does is return you to the prompt if everything is working.

[root@wrkst1~]$ kinit aduser@NIXADMINS.NET

That’s it for Kerberos, it wasn’t that hard now was it.

Configuring Samba

Samba is used to set some Windows domain information and the machine name. Also we define where and how the user directories are and which the default user shell is. Here is my smb.conf, read it trough and change at least the values workgroup (the wins domain name), realm (the domain DNS name in capitals) and password server (your PDC).

# /etc/samba/smb.conf

[global] workgroup = NIXADMINS netbios name = wrkst1 server string = Linux workstation 1 security = ADS log file = /var/log/samba/samba.%m max log size = 50 local master = no preferred master = no idmap uid = 10000-20000 idmap gid = 10000-20000 winbind gid = 10000-20000 winbind enum users = yes winbind enum groups = yes winbind use default domain = yes template homedir = /home/%U template shell = /bin/bash encrypt passwords = yes dns proxy = no realm = NIXADMINS.NET password server = ad-server.nixadmins.net wins proxy = no

Before we move on let’s check our /etc/samba/smb.conf file to see if there are any errors in it.

[root@wrkst1~]$ testparm Load smb config files from /etc/samba/smb.conf Loaded services file OK. Server role: ROLE_DOMAIN_MEMBER Press enter to see a dump of your service definitions # Global parameters [global] workgroup = NIXADMINS realm = NIXADMINS.NET server string = Linux workstation 1 security = ADS password server = ad-server.nixadmins.net log file = /var/log/smb/samba.%m max log size = 50 preferred master = No local master = No dns proxy = No idmap uid = 10000-20000 idmap gid = 10000-20000 template homedir = /home/%U template shell = /bin/bash

Starting the winbind daemon.

Let’s start the winbind daemon that is responsible for the queries against Active Directory and find out if our setup is working. Before you do this be sure to check that neither smbd or nmbd are running.

[root@wrkst1 ~]# service smb status smbd is stopped nmbd is stopped [root@wrkst1 ~]# service winbind start Starting Winbind services: [ OK ] [root@wrkst1 ~]#

Adding the workstation to the domain.

Now that we have a working winbind we can add the workstation to the Windows domain. Run the following command. Use the Windows Administrator account or another account that has the rights to add a computer to the domain.

[root@wrkst1 ~]# net ads join -U Administrator Administrator’s password: Using short domain name — NIXADMINS Joined ‘WRKST1′ to realm ‘NIXADMINS.NET’ [root@wrkst1 ~]#

That’s it. The workstation should now be located in the computers holder in the Windows domain.

Configuring /etc/nsswitch.conf.

Edit the file top part of the file /etc/nsswitch.conf.

Before: # some text before this part passwd: files shadow: files group: files # and some after also, let them be

After: # some text before this part passwd: compat winbind shadow: compat group: compat winbind # and some after also, let them be

Testing winbind

Now let’s test winbind to see if we really are communicating with Active Directory. To do this we use the command wbinfo with the switches -u and -g, -u to query users and -g to query groups.
First let’s query for users in the directory, you output should look something like below.

[root@wrkst1 ~]# wbinfo -u NIXADMINSAdministrator NIXADMINS******* NIXADMINS******* …………. [root@wrkst1 ~]#

And next let’s query for groups.

[root@wrkst1 ~]# wbinfo -g NIXADMINSHelpServicesGroup NIXADMINSTelnetClients NIXADMINSDomain Computers NIXADMINSDomain Controllers …………. [root@wrkst1 ~]#

Testing Windows to Linux account conversion.

We need to be sure this is working properly or our users won’t be able to log in to the workstation. The command getent shows us all accounts or groups.
First let’s check the users, run the following

[root@wrkst1 ~]# getent passwd

And then the groups

[root@wrkst1 ~]# getent group

Editing /etc/sysconfig/samba.

Add -D to the winbindoptions part of /etc/sysconfig/samba, the file should look like this

# Options to smbd SMBDOPTIONS="-D" # Options to nmbd NMBDOPTIONS="-D" # Options for winbindd WINBINDOPTIONS="-D"

Editing PAM settings.

IMPORTANT! Make a backup of the whole /etc/pam.d folder before you continue.

Made the backup? Ok, let’s continue.
Let’s edit the file that handles the logins. Edit your /etc/pam.d/login to look like this

#%PAM-1.0
auth	required	pam_securetty.so
auth	sufficient	pam_winbind.so
auth	sufficient	pam_unix.so use_first_pass
auth	required	pam_stack.so service=system-auth
auth	required	pam_nologin.so
account	sufficient	pam_winbind.so
account	required	pam_stack.so service=system-auth
password	required	pam_stack.so service=system-auth
# pam_selinux.so close should be the first session rule
session	required	pam_mkhomedir.so skel=/etc/skel umask=0022
session	required	pam_selinux.so close
session	required	pam_stack.so service=system-auth
session	required	pam_loginuid.so
session	optional	pam_console.so
# pam_selinux.so open should be the last session rule
session	required	pam_selinux.so open

Note: we adde

8 comments

Software Installation by Group Policy

by Mats Hellman on 13.Dec, 2005 under Linux

For a large software deployment, most IT departments do not have the staff or time
to install the software on each machine individually. In this article, I will
show you how you can configure a Group Policy to install the software on each
machine automatically from a central point.

What is Group Policy?

Creating a Group Policy Object (GPO)

Editing Your GPO

Creating a Software Installation Package

Checking your Software Installation Policy

Further Reading

What is Group Policy?

Group Policy is a huge topic.
I don’t consider myself an expert by any means with Group Policy and I have
been working with it for a few years already. For the purpose of this article,
you need to understand that Group Policy is a feature available in Windows XP,
Server 2000 and 2003 that allows you apply policies to computers and users in
your network. A group policy may be applied Site-wide, Domain-wide, or
Organization Unit (OU)-wide. In this article, we will be applying a Group
Policy Object (GPO) to an OU that I have already created.

Creating a Group Policy Object (GPO)

Creating a GPO is simple. All
you need to do is select your Organization Unit (in our case), right click on
it and choose Properties. From the Properties window, click on the Group Policy
tab and click the ‘New’ button, as shown in Figure 1.

Figure 1: Creating a New GPO

Editing Your GPO

Editing your GPO is about as
easy as creating it. Note that you must be a member of the Administrators or
Domain Administrators group in order to edit a GPO. To edit your newly created
GPO, simply click the ‘Edit’ button.

Figure 2: Editing your GPO

Creating a Software Installation Package

Now that we have created our
GPO, we must define what goes in it. In this article, we will focus on creating
a Software Installation Package to make software deployment automated on
multiple clients.

Software Packages can be
Assigned or Published to either Computers or Users. You may use any combination
of the four, depending on your scenario. Let me give you a few examples:

• Assigned
  to Computer: you are deploying
  software to multiple clients and require the software to be installed on
  all of the computers in the OU.
• Assigned
  to Users: the Users in your OU
  require a special application to be installed on every computer that they
  log on to.
• Published
  to Computer: there is an upgrade
  (ie: Windows Media Player) that is optional to all computers in your OU
  and can be installed if the user on that computer wishes.
• Publish
  to User: if the users in your OU
  use multiple computers and you want them to have the option to have their
  software with them, they can install any published package on any computer
  they are on.

It is important to note that
only software that includes an MSI install package can be deployed via Group
Policy. If your software does not have an MSI installer, there are third-party
programs that will repackage your application into an MSI – I have yet to find
one I actually like and would recommend, though.

To create a new Software
Installation Package, you can navigate to the ‘Software Settings’ folder in
either the Computer Configuration or User Configuration, depending on your
deployment requirements. In our scenario, we will be publishing an application
to a user so under the User Configuration, we will click on ‘Software
Settings’. Next we right-click on ‘Software Installation’ and then ‘New’ and
‘Package’ on the menu

Comments Off

Advertising

Recent Posts

• Unable to use Active Sync / direct push on Exchange 2010
• Affordable SAN(UCC) certificates for Exchange Server
• Prepare a Virtual Environment for testing
• New theme
• Systems Center Configuration Manager 2007, Secondary site Pending

Archives

May 2010

April 2010

January 2010

December 2009

November 2009

October 2009

July 2009

April 2009

March 2009

February 2009

January 2009

December 2008

Login

Register

Log in

Browse by tags

Acrobat Active Directory Apple ASP.NET CentOS Defragmentation Domain Drivers Free Software Group policy Install Linux MSI Nixadmins OSX programs Redhat Security Service Pack 3 SSL VPN SSTP VPN tools Virtual PC VPN Windows 7 Windows Deployment Services Windows Server Windows Vista Windows XP WinPE

Ads

Ads