Technology


We’ve had a few customers and Open users posting about problems with machine accounts trying to access Samba shares and getting denied with:
smbd/sesssetup.c:reply_spnego_kerberos(439) Username DOM\COMPUTER1$ is invalid on this system
The “$” at the end of the account name means it’s a computer account, not a user. We’re seeing this for Citrix MetaFrame application servers on shared storage, startup scripts not stored on a DC, and several other cases.

On a Samba server joined to AD with winbind, this is easy to deal with because Samba’s winbind can treat the computer accounts just like user accounts, and assign them access to the unix filesystem with whatever backend has been configured. When a Samba server is joined with Likewise, however, the machine accounts are not visible, and the “username is invalid” message comes up.

Fortunately, Samba gives us a method to handle this, in form of the “username map” directive in /etc/samba/smb.conf.  There are two ways to use this, the first is with the username map file.
In smb.conf, to simply add:
[global ]
username map = /etc/samba/smbusers

then create a file named /etc/samba/smbusers and populate it with localuser=aduser pairs, like:
COMPUTER1$ = compacct
COMPUTER2$ = compacct
CITRIXFARM1$ = citrxact

and so on. Lastly, you’ll have to add the local accounts from the pairs above:
useradd -c "Account for AD Computers to use Samba" compacct -G users -u 998
useradd -c "Account for AD Citrix Servers to use Samba" citrxact -G users -u 999

Then, whenever one of the AD computers in the list attempts to access the Samba share, it’ll be mapped to the local account.

The problem with this is when you have a lot of servers, like a Citrix MetaFrame farm, or a Windows Server 2008 R2 Remote Desktop Services farm, that may be changing frequently, because managing that file could get hard. In this case there is the username map script directive, which is added to smb.conf as:
[global ]
username map script = /usr/lib/samba/auth/machine-acct-map.pl

Then download this script and save it in /usr/lib/samba/auth/ and make it executable (chmod +x /usr/lib/samba/auth/machine-acct-map.pl). Then run:
useradd -c "Account for AD Computers to use Samba" compacct -G users -u 998
Now, all computers which access the share will be remapped to the “compacct” user, and you won’t have to manage a file for every time the server farm changes.

Get the file here.

aka: Technology by Voodoo, Information Technology by Voodoo, Troubleshooting by Voodoo, Administration by Voodoo, Troubleshooting by Faith, etc.

The act of “trusting” that a computer will do something every time the same way, only because it did the last 2 times you tried it.

The alternative is to actually learn what the computer is doing, so that you can know it will do the same thing each time, because you’ve controlled all of the appropriate parameters.

Usage: “This sysadmin is performing IT by Voodoo – he just asked if I have faith that my file copy will work.”

Now that it’s defined, can we all stop doing it?  There’s enough resources on the internet to figure out how anything works down to the API call at least, and in some cases down to the processor registers, if you care to go that far.

I just finished my upgrade from Kubuntu 8.04 to 8.10 this past week (since I had downtime from work, I could afford to break things for a few days).  The upgrade went great, and I’ll write about it shortly, once I get used to the newness.

Anyways; Workstation 6.5 has been giving me problems.  Because of the newness of KDE4, I initially thought it was a KDE problem, but it turns out it’s something between Workstation 6.5 and Ubuntu 8.10.  I just ran the “adapt –dist-upgrade-devel” command from the Ubuntu wiki to upgrade, and upon reboot, I couldn’t “ctrl-alt-ins” or “ctrl-alt-del” to log into my Windows VM, my “Windows/Start” key on the keyboard wouldn’t respond, and my arrow keys wouldn’t work.  Incredibly, when I’d hit the “down” arrow, I’d get the Windows Start menu pop up!!

Fix is easy, edit /etc/vmware/config and add the line below like:

sudo vim /etc/vmware/config
:$
A (that's vi-command for "go to the end of the file, and start writing a new line")
xkeymap.nokeycodeMap = true

Have to restart your VMs for this change to take effect. Thanks to Duncan Epping for this fix (he posted it in the forums, where I found it).

So, any regular readers might have noticed that the posts have been slow coming the past few months.  Hopefully you don’t think that the depth in those few posts has been lacking.  I’ve been struggling with how to report that I took a new full-time job in April.  Obviously, it’s not stopping me from writing, but has slowed me down a bit.

As you may remember, back in January I was invited to speak at Directory Experts’ Conference, 2008. If you weren’t there, I spoke about integrating 30+ Linux servers with a 2000-user Active Directory forest at one of the U.S.’s biggest home improvement providers. At the time, we had used Centrify DirectControl 4.0 to accomplish this integration, and they were the ones who invited me to speak at DEC.

As part of my preparations, I reached out to Quest Software to ask about Vintella, now renamed “Authentication Services”, and to Likewise Software, who sent me software and support contacts (at my request), so that I could learn Likewise Enterprise as well as I knew Centrify DirectControl. That was a very tall order for Likewise Software to fill, as I had spent the past 6 months learning DirectControl inside out.

After 4 weeks of building demonstration machines (with both products), capturing video in case the demos crashed (which they didn’t), and building a presentation and practicing it, DEC was upon us.  I gave two presentations, one specifically for Centrify on Monday, and the primary one on Wednesday.  At the end of both presentations, we recieved a lot of great questions which Centrify’s Director of Product Development helped answer.

At the end of the conference, Likewise offered me a job. After many discussions with them, my friends and family, and my customers, I decided to take the opportunity. This is not a decision I made to slight Centrify, who’s support of me through my time as a customer was amazing, and who’s assistance through the presentation was fabulous. It’s just one of those opportunities that comes along that I couldn’t pass up.

So for the past 6 months I’ve been the Project Manager for Deployments for Likewise Software. I’ve been on the road about 80% of the time, working with customers to install our software in their environments. Many of the posts I’ve made in that time have been in response to an issue we’ve seen or avoided at a customer of Likewise. I will continue to write these, and I’ll work on doing so at my old (2007) pace of about 3-4 posts a month, since they have been (according to my stats) useful to many people, which is the point of writing this blog.

That means, no changes here compared to last year, but I will have a wider variety of topics, and I’ll likely start mentioning our software specifically. I want it to be clear it’s not advertising, but just the state of what I’m working with. Again, Centrify makes a great product, and I was very happy to have chosen it for my needs at my previous employer.  However, I’ve chosen to move forward with this open source company (Likewise Software) for the next stage of my career, and will continue to write about software and integration with a view towards open source software.

Thanks for continuing to read!

Robert Auch

I’ve been working on something completely new for the past 2 months which has involved a lot of travel. 95% travel, which leaves precious little time to write new articles, especially as I’ve been spending my off-hours learning HP-UX 11 and Solaris 8 and 10. And I still have AIX 5 to learn too.

Apperantly Solaris 10 and OpenSolaris have a little quirk around how they work with DHCP and setting the system’s DNS name. In our test lab, all our systems are assigned addresses via Microsoft DHCP, which then registers (and un-registers) non-Windows systems in DNS properly. However, the x86 Solaris systems we built for a customer test came up with name “unknown”, every single reboot. Changing /etc/hosts and /etc/hostname.pcn0 or /etc/hostname.vmxnet0 (physical or VMWare) to reflect the new proper hostname, however, didn’t affect the server on reboot – the settings would still be there, but not reflected in the OS, in /etc/hosts, or in DNS.

A bit of searching turns out a bunch of posts talking about editing /etc/nodename to put in the system name, but that file doesn’t exist out of the box on a “complete” or “minimal” install, and I’m always hesitant to create new files by hand in /etc/ unless I’m 100% sure that’s what’s needed. According to this post on Sun.com, some logic, and some testing, I think what’s going on is:

  1. Solaris expects DHCP to set the hostname of a system based on MAC address
  2. In case DHCP does not set a hostname via MAC address, or if that hostname is wrong, Solaris provides an override mechanism called /etc/nodename
  3. Because it’s an override, /etc/nodename is not created as a blank file, since that could be construed as “override DHCP with nothing”
  4. Therefore, every new box I build needs touching after final login

I’m not a huge fan of this, but I’m also not a fan of the number of times I need to click a mouse on an OS Install using software from the last year. The short version of all this is:

If you have a Solaris 10 box on DHCP named “unknown”, best practices is to set the hostname on the DHCP server. Otherwise echo newservername > tee /etc/nodename and reboot. (with “tee” in the pipeline, you can “sudo” this command as well).

« Previous PageNext Page »