Wednesday, February 25, 2009

Join Samba 3 to Your Active Directory Domain

Always worth retrying….

Join Samba 3 to Your Active Directory Domain

A popular thing to do with Samba these days is to join a Samba 3 host to a Windows Active Directory domain. You may freely set up any number of Samba servers in a Windows network without joining them to the domain. The advantages of domain membership are central management and authentication, and single sign-on. Using Winbind allows Linux clients to log on to the AD domain without requiring local Linux system accounts, which is a lovely time- and hassle-saver.

Presumably you already have a functioning Active Directory domain, and know how to run it. AD is very dependent on DNS (domain name system) so I'll assume your DNS house is also in order. On your Linux box you'll need Samba 3, version 3.0.8 or newer. Plus MIT Kerberos 5, version 1.3.1 or newer, and OpenLDAP. (The Samba documentation states that Heimdal Kerberos, version 0.6.3 or newer, also works. The examples in this article use MIT Kerberos.) Debian users need the krb5-user, krb5-config, krb5-doc, and libkrb53 packages. Red Hat and Fedora users need the krb5 and krb5-client RPMs.

First you should verify that your Samba installation has been compiled to support Kerberos, LDAP, Active Directory, and Winbind. Most likely it has, but you need to make sure. The smbd command has a switch for printing build information. You will see a lot more lines of output than are shown here:

root@windbag:/usr/sbin# cd /usr/sbin
root@windbag:/usr/sbin# smbd -b grep LDAP

root@windbag:/usr/sbin# smbd -b grep KRB
root@windbag:/usr/sbin# smbd -b grep ADS
root@windbag:/usr/sbin# smbd -b grep WINBIND

If you are in the unfortunate position of missing any of these, which will be indicated by a blank line, you need to recompile Samba. See Chapter 37 of the The Official Samba-3 HOWTO and Reference Guide.

Configure and Test Kerberos

Let's say our Active Directory domain server is, and the Samba server is named samba1. This is the absolute minimum Kerberos configuration file, /etc/krb5.conf, for connecting to this domain:

default_realm = DOMAIN.NET

Related Articles

'realms' DOMAIN.NET = {
kdc =

.kerberos.server = DOMAIN.NET

Use uppercase where it shows. Now try to connect, and mind your cases:

# kinit Administrator@DOMAIN.NET
Password for Administrator@DOMAIN.NET

Configure /etc/hosts

Even if your DNS servers are perfect in every way, it is a good idea to add important servers to your local /etc/hosts file. It speeds up lookups and provides a fallback in case the DNS servers go down: bigserver

Configure Samba

This example smb.conf shows a basic setup for a printer server and home shares. Shares are configured in the usual manner, only the global section changes when you join to an AD domain.

# Global parameters
workgroup = BIGSERVER
realm = DOMAIN.NET
preferred master = no
server string = Samba file and print server
security = ADS
encrypt passwords = yes
log level = 3
log file = /var/log/samba/%m
max log size = 50
winbind separator = +
printcap name = cups
printing = cups
idmap uid = 10000-20000
idmap gid = 10000-20000

comment = Home Directories
valid users = %S
read only = No
browseable = No

comment = All Printers
browseable = no
printable = yes
guest ok = yes

The workgroup is the name of your AD domain. Server string is a comment describing the server, make this anything you want. Log level runs from 0, for no logging, to 10, extreme logging. See man smbd.conf for the rest.

Save your changes and run

$ testparm

This checks smb.conf for syntax errors. Any errors must be corrected before going ahead. Then start up Samba:

# /etc/init.d/samba start

Finally, join your Samba machine to Active Directory:

# net ads join -U Administrator
Administrator's password:
Joined 'SAMBA1' to realm 'DOMAIN.NET.'

Hurrah! Success. The Samba box will now appear as a machine account under "Computers" in your AD console. Now stop Samba until the final steps are completed.

Enabling Windbind

Debian users may need to install the winbind package separately. RPM users will find it in the samba-common RPM. First, edit /etc/nsswitch.conf. The first three lines are the most important; the others vary according to your system:


compat winbind


compat winbind




files dns wins


files dns


db files


db files


db files


db files

Save your changes, and fire up windbind and Samba:

# winbind
# /etc/init.d/samba start

Now verify that windbind is working. These commands pull lists of users and groups from the AD domain controller:

# wbinfo -u
# wbinfo -g
BIGSERVER+Domain Computers
BIGSERVER+Domain Admins
BIGSERVER+Domain Guests
BIGSERVER+Domain Users

This command verifies that logins and passwords are coming from the AD server, and not the local machine:

# getent passwd

If winbind is not working and local authentication is still active, they will not have the BIGSERVER+ prefix. Finally, as root run net ads info to display the AD server information.


If you've gotten this far and everything works, your Samba server is now a fully-fledged member of your Active Directory domain, and can be managed like any other AD object. A nice bonus is you may have local Linux accounts on the Samba box that are not visible in Active Directory; which means your Samba admins can SSH directly into the Samba server for admin chores, and not have to fuss with AD roadblocks.

A good troubleshooting guide is chapter 9 of "Samba-3 by Example" (Adding UNIX/LINUX Servers and Clients). Also refer to chapter 12 (Identity Mapping) of "The Official Samba-3 HOWTO and Reference Guide" to learn about winbind in greater depth.


Wednesday, February 11, 2009

A cool way to block internet access to certain users / machines

As a system administrator, you might find it useful to block internet access for certain users

and / or machine, but in many cases, you do want to allow access to several specific web sites.

This article shows an alternative way of doing it without using ISA, Firewall applications,

IPSec and other complex solutions.

The first thing you want to do is create a simple HTML document which says

'Internet access is forbidden… blah blah blah'.

You can use MS Word or simple Notepad to create such HTML file and save it somewhere

under the name 'Default.htm'.

The next step would be to publish this HTML document on one of your IIS servers.

You should use a dedicated web site which listens on some unused TCP port for this.

You can use any IIS server (or other OS) for publishing the HTML document.

However, I used IIS7 for enumerating the steps:

1. Create a folder on the IIS server and assign read access to the server's computer account

in the domain. (For example, if your server name is 'IISSRV01', assign to permissions on the folder.

2. Copy the 'default.htm' file you created to this directory.

3. Open Internet Information Services (IIS) manager (Shortcut: Start --> Run --> inetmgr)

4. On the left pane, Expand

5. Right click 'Sites' and choose 'Add new web site…'

a. Type 'InternetForbidden' in the 'Site Name' text box

b. Under the 'Physical Path' text box, type the path to the directory you copied
the 'default.htm' to.

c. Under the 'Port' text box, type any available TCP port number, higher than 1025.
For example: '8765'

d. Click 'OK' to save the web site. If your newly added web site appears with a
red X next to it, click 'Sites' and the refresh display by using 'F5' keyboard key.
At this point, your new site should appear with a little 'Earth' icon, meaning
everything is fine.
e. In order to test your settings, try to browse to the web site by typing the
following address in the Internet Explorer Address bar of one of your
client machines:
If everything worked fine by now, continue to the next stage.

The next stage would be to set this web site address as a proxy server for those
users / machines you want to restrict. There are many ways to apply these settings to clients.
In this article, I will go through the steps of configuring the proxy address through Group Policy.

1. Create a security group that will include all user / computer accounts which should be restricted.

2. Start Group Policy Management (Shortcut: Start --> Run --> GPMC.msc)

If you don't have GPMC installed, it is about time you install it! -

3. On the left pane, select the OU which contain the user / computer accounts which you want

4. Right click the selected OU and choose 'Create and link a GPO here…'

5. Type a name for the GPO and click 'OK'

6. On the left pane, click on the newly created GPO.
7. On the lower part of the right pane, click the 'Authenticated Users' group
(under 'Security Filtering') and click 'Remove'. Click 'OK' to approve.
8. Click 'Add…' and browse to select the security group you created in the first step.

9. On the left pane, right click the GPO and click 'Edit…'

10. On the left pane, Expand 'User Configuration' à 'Windows Settings' -->
'Internet Explorer Maintenance' --> 'Connections'

11. On the right pane, double click 'Proxy Settings'

12. Check 'Enable Proxy Settings'

13. In the 'Address of proxy' text box, type the address of the web site you created
at the beginning of the article. On the 'Port' text box, type the port of your web site
(In this example – 8765)

14. If you have URLs of sites which should not be restricted, type the URLs in the
'Exceptions' list.

15. Click 'OK'

16. On the left pane, Expand 'Administrative Templates' --> 'Windows Components' -->
'Internet Explorer'.

17. On the right pane, double click 'Disable Changing proxy settings', change to 'Enabled'
and click 'OK'.

18. If you are restricting computer accounts (and not user accounts), meaning that the
OU you selected in step #3 contains the computer accounts and that the security
group you created in step #1 contains computer accounts, perform the following tasks:
a. On the left pane, Expand 'Computer Configuration' -->
'Administrative Tools' --> 'System' --> 'Group Policy'.
b. On the right pane, double click 'User Group Policy loopback processing mode',
choose 'Enabled', select 'Merge' and click 'OK'.
19. That's it! You can now close the Group Policy Object Editor and the
Group Policy Management Console and test your settings.
Note that group membership is updated at logon, so you will need your clients to log off
and back on in order to be restricted. If you are applying the GPO on a group of
computer accounts, the client computer should be restarted in order for the
computer account's group membership to be applied.

Why some applications malfunction when one of the Domain Controllers is down?

Why some applications malfunction when one of the Domain Controllers is down?
- Or -
How to switch to disaster recovery site without booting my clients

Every Sysadmin installs at least two Domain Controllers on his domain for redundancy and
fault tolerance. But what actually happens when one of the DC's is down?

If you do a simple and disconnect one of your DCs from the network, you'll see that about
half of the workstations and member server who hasn't booted since the DC is down are
experiencing problems such as sluggishness, performance issues and some of the
applications simply stop working. The reason for that is the way Netlogon works.

Netlogon is the process which is responsible, among other tasks, to detect Active Directory
environment and the closest DC. The detection process is called DC Locator.

It is implemented in the NetAPI.DLL in a function named dsGetDCName and invoked by the
Netlogon service when the service starts. The DC Locator process sends a request to all
Domain Controllers in the domain and waits for them to respond. Once responded,
Netlogon caches the Domain Controller who was first to respond and saves its details
in the cache. From that moment, every call made by any application for the dsGetDCName
function returns this DC.

The DC Locator process does not re-check the availability of the cached DC periodically..
Therefore, if this DC is gone for any reason, workstations and member servers who have already
cached this DC remain with the faulty cache until the workstation is rebooted. As a result,
any application that needs to access the DC (and call the dsGetDCName for it) receives the
faulted DC and is expected to have problems when trying to connect to it.

In the last years, fault tolerance became an essential requirement in many organizations.
Many enterprises implement expensive disaster recovery sites, buy expensive clusters and
replicate data to at least one additional location.

When the disaster does happen and the main site is going down, this limitation will cause
you lots of trouble until you reboot your entire organization.

Tuesday, February 10, 2009

Settings Windows Time on PDC emulator using w32tm

· Type the following command to configure the PDC emulator and then press ENTER:

w32tm /config /manualpeerlist:peers /syncfromflags:manual /reliable:yes /update

where peers specifies the list of DNS names and/or IP addresses of the NTP time source that the PDC emulator synchronizes from. For example, you can specify When specifying multiple peers, use a space as the delimiter and enclose them in quotation marks.


w32tm /resync