I was able to hack together a pretty quick solution to do this in bulk:

$sScopes  = netsh dhcp server show scope
$sRegex   = "10\.11\.\d{1,}\.\d{1,}"
$aMatches = [regex]::Matches($sScopes, $sRegex)

if ($aMatches.count -gt 0) {
    foreach ($match in $aMatches) {
        netsh dhcp server scope $match.Value set optionvalue 006 IPADDRESS 10.0.0.1 10.0.0.2
    }
}

Let’s go through the code.  The first line fetches every scope from the netsh command. The second line defines the regular expression that matches the scope addresses we want to modify. The third line actually performs the regular expression matching.

Jumping down to the loop, we run the netsh command again, but pass in the value of the match (which will be the ip address defined on line two and set our options accordingly.

I hope this helps someone out there!

Windows does this extremely well with Active Directory; almost any good enterprise product will support Active Directory for authentication.  But, where do mixed environments fit in with Windows software and technologies?  Quite well, in fact.  In this article, I will be outlining how to configure authentication and authorization with Active Directory using CentOS, Scientific Linux, or any other Red Hat based distribution.  The concepts within can be applied Debian-based distributions with relative ease (but authconfig saves a ton of time).

Winbind

The process of linking Linux with Winbind has become increasingly straightforward, but there are some redundant pieces involved.

Installing Dependencies

We need to make sure winbind and friends are installed so there are no issues later on down the line:

yum install -y samba-common samba-winbind-clients samba-winbind nscd ntp ntpdate

Updating the Time

Keeping in sync with time is very important in an AD environment. Without the correct time, a machine will not even be able to join the domain.

ntpdate pool.ntp.org
/sbin/chkconfig --level 35 ntpd on
/sbin/service ntpd start

Authconfig

Authconfig is Red Hat’s utility for configuring PAM authentication. We will utilize it to do the bulk of our configuration for us. Run authconfig-tui and select Winbind for both User Information and Authentiction. Also, Cache Information should be checked. Make sure that local authorization is sufficient is selected in case there are problems! Do not select Join Domain in this dialog, as it will be done later.

• Security Model: ads
• Domain: The WORKGROUP of your domain.
• Domain Controllers: Specified in {server}
• ADS Realm: {DOMAIN}
• Template Shell: /bin/bash

We should also enable home directory auto creation, unless special provisioning for such things is already in place (shared filesystem for example):

authconfig --enablemkhomedir --update

Kerberos Configuration

The authconfig script sets this up for us, but we want to verify the script did it’s job correctly.

The Kerberos configuration file is used to join the machine to the domain as well as to reference it later on. I’ve provided an example configuration file, however some of the items need to be replaced with customized values:

• {DOMAIN} Your AD domain in all caps.
• {domainname} Your AD domain in all lowercase.
• {server} The IP address of your DC.

Example

vi /etc/krb5.conf

[libdefaults]
default_realm = {DOMAIN}

[realms]
{DOMAIN} = {
    admin_server   = {server}
    default_domain = {domainname}
    kdc            = {server}
}

[domain_realm]
{domainname}  = {DOMAIN}
.{domainname} = {DOMAIN}

Samba Configuration

Authconfig sets up the smb.conf file as well, but a few things must be changed for a easier to use solution. There is one variable in the example configuration that must be changed to suit your environment:

• {name} The base hostname of the system. In the case of test.example.com, it’s TEST.

Example

vi /etc/smb.conf

[global]
netbios name = {name}
winbind use default domain = true
add machine script = /usr/sbin/useradd -s /sbin/nologin -M %u

[homes]
valid users = %S

Connecting to Active Directory

Now comes the fun part, connecting our server with Active Directory, joining it to the domain.  We will then need to add a user account that is linked to the value set in {name}.

useradd -s /sbin/nologin -M {name}$
passwd -l {name}$

Finally, join the machine to the domain. To do this, you need access to an account with enough permissions (Usually a member of the Domain Admins group).

net join -w {domain} -S {server} -U {user}

PAM

From here, we must configure PAM itself. There are two main files to modify here, password-auth, which handles SSHd (and a few others) authentication, and system-auth, which deals with everything else.

Authconfig makes this pretty easy to do, but if not done right, modifications will be overwritten if something is changed. The good news is, this can be solved via changing the symlink from system-auth-ac to a custom file, system-auth-custom and using some include statements to link back to system-auth-ac:

password-auth-custom

# This file is designed to be used with authconfig.  It adds functionality
# while still allowing authconfig to generate configuration.  The symlink
# password-auth -> password-auth-ac was replaced with this file.

# The listsep argument is important as Windows groups may contain spaces
account required pam_access.so listsep=,

# Include authconfig file
auth include password-auth-ac
account include password-auth-ac
password include password-auth-ac
session include password-auth-ac

system-auth-custom

# This file is designed to be used with authconfig.  It adds functionality
# while still allowing authconfig to generate configuration.  The symlink
# system-auth -> system-auth-ac was replaced with this file.

# The listsep argument is important as Windows groups may contain spaces
account required pam_access.so debug listsep=,

# Include authconfig file
auth include system-auth-ac
account include system-auth-ac
password include system-auth-ac
session include system-auth-ac

Changing the Symlinks

rm system-auth password-auth
ln -s system-auth-custom system-auth
ln -s password-auth-custom password-auth

Now we’ve got a custom authentication piece that won’t be overwritten when authconfig does it’s magic!

Configuring Authorization With pam_access.so

Because of the previous step, the contents of /etc/security/access.conf are no longer valid as they assume lists are separated with spaces. Since Active Directory allows spaces in group names, (and encourages it), we’ve changed it to a comma.

To allow only members of Domain Admins, and wheel access to the system we would do the following:

vi /etc/security/access.conf
+:root,Domain Admins,wheel:ALL
-:ALL:ALL

Sudoers

Well, Domain Admins can log in, but they don’t have any privileges. How do we fix that? Sudoers of course! Warning: Whitespace characters must be escaped in the sudoers file or a syntax error will be thrown:

visudo
%domain\ admins ALL=(ALL) ALL

If you guys have any questions, feel free to post them in the comments below. Hope you learned something!

Today, I will be showing you a mechanism to not only secure the passwords being held in your databases, but a way to secure the authentication process itself from prying eyes.  Enter SCRAM.  While it’s impossible to completely prevent a man in the middle access attack, utilizing SCRAM will certainly make it exponentially more difficult.  For a site that isn’t running e-commerce, I believe this is a much more cost-effective solution to an SSL certificate.

SCRAM

SCRAM is a relatively new protocol for authentication written under RFC 5802 that works very well with web technologies as they are today.  It is algorithm agnostic, protocol agnostic (for the most part), and straightforward to implement.  The basic concept of SCRAM is that the client and server never send enough information for a hacker to simply decrypt (or use rainbow tables) the password.  Instead, a ‘client proof’ is generated that the server uses to determine authentication.  If you wish to know more about it, feel free to read the links above.

Differences

There are some key differences in the SCRAM-SHA256-JSON approach we will be utilizing today:

1. The protocol is HTTP, so some bits of the protocol are no longer necessary/possible.
2. In lieu of an AuthMessage, a JSON object is sent back and forth.  This is possible because the RFC defines the order of each part included in an AuthMessage.
3. The ‘third phase’, where client verifies server authentication has been left out to reduce client-side overhead.
4. A smaller iteration was chosen to cut the impact on performance caused by JavaScript code.
5. Input passwords will be hashed before salting.

I tried to stay as true to the protocol as possible, however some things just didn’t make sense in a web environment where connections do not persist and encryption transparent to the code itself.  None of the authentication steps have changed, just the way they are sent.

The Code

This tutorial is broken up into two major sections, the server-side and client side.  I will talk about what needs to happen on each step and present you with the well commented and completed source code.

Overview

I think it will be necessary to outline what we are actually trying to do in each section.   The SCRAM authentication process works like this:

1. Client sends username and ClientNonce.
    a. The client stores its own request string in memory for later use.
2. Server sends salt, ClientNonceServerNonce, and iterations.
    a. The server stores the client request and its own in SESSION
       for later use.
    b. The client stores the server request in memory for later use.
    c. The client uses the iterations response to determine the strength
       of the hash.
3. Client performs the calculations necessary to form a ClientProof,
   sending it and a ClientNonceServerNonce to the server.
    a. The server verifies the ClientNonceServerNonce with the one
       stored in SESSION.
    b. The server performs the calculations necessary to get a
       ClientSignature.
    c. The server obtains the ClientKey by performing an XOR on
       ClientSignature and ClientProof.
    d. The server hashes the SaltedPassword using the iterations
       provided in step 2.
    e. If the passwords match, an HTTP 200 response is sent with
       a URL to use on page refresh.  If the passwords don't
       match, an HTTP 401 response is sent.

Technologies Used

You should not need to install additional PHP extensions, however, mcrypt is highly recommended if you don’t already have it.  You might also want to pickup mbstring (if you don’t already have it).  A minimum PHP version of 5.2 is required to run the provided code.  It can certainly run on older versions with some effort, but PHP 5.3 is becoming the norm, so get with the program!

The client side will use the Dojo Toolkit’s core libraries for element manipulation and prototyping.  There isn’t much Dojo-specific code in the provided file, so it will be easy to remove if you so choose.  On the other hand, Crypto-JS is definitely engrained within the client side code.  Crypto-JS can be custom compiled using Google’s Closure Compiler if need be, which makes it an extremely small library to include.