Windows


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.

I have been invited to present at the Directory Experts Conference in Chicago in March, hosted by NetPro Computing, Inc.. I’ll be discussing how we recently integrated dozens of Linux servers into our 300+ server Windows 2000 Native Mode forest. I’m excited, but it’s taking away from the time to update a few things here I have in “unpublished” state.

Of note is a response for T. Colin Dodd regaring his short and sweet post regarding Red Hat Flaws according to Secunia. In short, Mr. Dodd (please correct me if the address is wrong), yes, Red Hat should be proud of what they’ve accomplished, but…

Well, that’s 2 pages of text that’s not yet finished.

As I mentioned in my last clustering post, there are some Exchange problems we’ve been working on over the past few weeks. One of the simpler problems has a complex answer, so I thought I’d explain a bit.

As any good Exchange administrator knows, Exchange stores its data (for a store)in 2 files, the EDB file, and the STM file. However, there’s not a really great explanation of the differences between the two files – the best I’ve found so far is at MessagingTalk.org, but they only explain that the STM is MIME formatted, and the EDB is MAPI content. Why, though, and how does it affect the end users? This is what we’ll explore. (more…)

If you are setting up a cross-forest trust with selective authentication (which requires a Windows Server 2003 Native mode level forest and domain), don’t forget to grant the “Allowed to Authenticate” right to the users from the trusted domain to the servers they’ll need access to in your domain. The error messages you’ll get back (replicated here in my test VM domains) don’t really say much helpful.

System Error 317 has occurred. The system cannot find message text for message number 0x*** in the message file for ***.

System Error 317

Further information about adding the “Allowed to Authenticate” right to the trusted users is available at Microsoft TechNet. If you have the opportunity to raise your forest and domain functional levels to take advantage of this, I highly recommend it. But I recommend also (even more strongly) documenting precisely what you set.

I’ve been very busy with clients over the past 2 weeks, troubleshooting Clustering problems, Exchange issues, and planning a new trust relationship, on top of normal maintenance and design. As I solve each issue, I’ll be posting what I can about them. This week we were able to solve the odd clustering problem…

We’ve seen some issues over the past approximately 2 months, particularly with MS SQL 2000 clusters (1 Exchange 2003 cluster), where the cluster group fails on one node, and the other node (or nodes) fails to pick up the group, leaving the complete cluster group offline. In each of the cases (on both HP and Dell hardware) the first striking piece of evidence in the logs is that all nodes that fail to bring up the cluster report that the Cluster IP Address resource couldn’t be brought online, because of an IP address conflict on the network

Making this issue particularly fun is that most of the information we used to solve the problem, is a lack of information.  In particular, there is absolutely nothing interesting at all in any nodes’ cluster.log file.You see the disks negotiate from node to node, but nothing that makes the failover look any different than if you had right-clicked the group and chosen “Move Group” from Cluster Administrator.

What starts the problem off is Event ID 1228 from source “ClusNet”, which says that the “ClusNet driver couldn’t communicate with the ClusSvc for 60 seconds, the Cluster service is being terminated.” Most of the time, you might even miss that this event is there, because it causes so many Event Source Tcpip, ID 4199; Source ftdisk, ID 57; and Source ntfs event ID 50 events, that it’s easy to look over 1 little error. Especially when monitoring systems like Microsoft Operations Manager (MOM), or Idera SQLDiagnostics Manager (SQLDiag) or HP Systems Insight Manager (SIM) all report the cluster as having issues 30-60 seconds after the CluNet 1228 event is written (timing which corresponds exactly to the Tcpip 4199 events (IP address conflict) or the ftdisk 57 events (failed to flush transaction data). So, here’s what happens, based on conversations with Microsoft, training with Microsoft and HP, and a LOT of reading. (more…)

« Previous PageNext Page »