Unified Diff

Well I finally did it. Last summer I set out to build and run CLAWS in my own environment. I was able to get parts of it running, but there were a few problems I was stuck on. I haven’t had much time to work on it since then, but over spring break I managed to get everything built and installed.

My goal was to get CLAWS running the way RIT uses it, and then write patches to the main codebase. If certain people in high places liked the changes I made, they could take the patches and apply them upstream. Even if that doesn’t happen, I could always fork the project and continue development on my own. For political reasons, I’d have to wait to do this until after I graduate.

The PAWS Project is aimed at taking what is now a very RIT-centric software system and transforming it into something the general public can use. Much to the chagrin of some un-named information security officials, CLAWS is open source and so I can (at very least) develop from the r2977 snapshot.

In the coming few months I plan to have my documentation finished for building and installing CLAWS. I should have a lighter schedule this summer, so I’m hoping to get most of my development work done then.

Managing thousands of user accounts in a heterogeneous computing environment can be a nightmare. Then throw in the need to manage user identities and network access to over forty-thousand network devices. What is a systems administrator to do? Enter CLAWS, RIT’s new open-source enterprise account, identity, and computer management tool.

The CLAWS central server manages communications between the various clients and back-end systems. A self-help tool allows students to activate an account and edit identity and mail preferences. The Help Desk client provides account management functions for staff that streamlines account creation and maintenance across the multiple systems.

Right now, CLAWS is used in production by both students and Help Desk staff. We are presently working to integrate IPEdit functionality into CLAWS. Visit the project homepage for more information.

There are probably a million and one articles about how to make Samba 3 an Active Directory domain member. But with all of that, this process still seems to require hours of research. So I’ve decided to compile my latest experiences here.

The domain member box is running Gentoo Linux. So you may need to adjust the steps to fit your flavor. Make sure the USE flags kerberos, ldap, samba, ssl, and winbind are set. Start by installing an NTP client.

# emerge ntp

I maintain several client and server machines that, up until recently, all authenticated users locally. I wanted a more centralized mechanism that could handle the various users and systems on the network. The big catch is that a few key system run Linux while others run Windows. So after doing some research, I turned to Active Directory.

My first chore was to install Windows Server 2003 and configure it to be a domain controller. This part was fairly easy, although a little time-consuming. Once that was working I was able to quickly join the Windows machines to the domain. Now to deal with Linux… for that I chose Windows Services for Unix. This software alters the AD schema to allow for Unix account attributes. On the Linux machines, I installed OpenLDAP, a Kerberos client, configured PAM… and voila! Now AD users can authenticate on the Linux machines.

My home-made DHCP/DNS configuration tool, however, was a little trickier. The data for this tool is stored in a MySQL database and accessed via a PHP script. If I wanted to grant someone access to the tool, I needed to first give them a MySQL account. Since Active Directory is basically an LDAP server, I rewrote the authentication mechanism to query AD.

With very little work, I was able to simplify authentication and account management. While this is not new technology, I still feel all warm and fuzzy with a sense of accomplishment.