CIFS/Samba and Windows Scheduled Tasks

[CelesteG]

Okay, weird problem has arisen in our environment. Our Samba server was connected to the domain via a particular DC (10101)that was running Windows 2003 SP1. The Windows dudes installed another DC that is running Windows 2003 R2 SP2 (30108) and removed the RID Master, PDC emulator and any other NTDS roles from the original DC (10101). The server is still on line but is set it to be decomissioned.

Issue # 1 User Authentication
Interestingly enough, we began experiencing problems with SAMBA at that time. We use smbuser.map file to map Windows users to generic accounts on our HP-UX 11.11 Samba server. Users configured in this file are now being prompted for a password and the log. was being populated with NT_STATUS_NO_SUCH_USER authentication errors when attempting to access their shares.*SIGH*

We were running at Samba 3.0.7. Thinking this could be a compatibility issue, I upgraded our Samba server from 3.0.7 to the latest Samba version packaged by HP...

root % swlist | grep CIFS
B8725AA A.02.03.04 HP CIFS Server

...which is Samba 3.0.22 with security fixes, but it didn't resolve the issue.

As a result of this unexpected DC migration, I had to remove our HP Samba server from the domain and rejoin it using the new DC.

/sbin/init.d/samba stop
net rpc join -S 30108 -U my-UID

I receive the "Joined domain 'domain'"
So it joined successfully
/sbin/init.d/samba start

I now have to add all the users that were generically mapped in the smbusers.map file onto the HP Samba server locally before they can authenticate *SIGH*. Why would the smbuser.map mappings suddenly stop working?


Issue # 2 - Scheduled Tasks
The scheduled tasks that were moved from the original location stopped working when moved to the yet another new server (Windows 2003 R2 SP2). I up'ed the debug level to 3 and another interesting fact is that I can map a drive to the share that holds the scheduled tasks on the new server (Windows 2003 R2 SP2) with my UID from **my Windows XP SP2 workstation** and run the scheduled task successfully. However when I log directly onto the **new Windows 2003 R2 SP2 server** with my same UID the job fails to access the Samba share.

I looked at the entries in the log files and when it works from my workstation the logfile has this entry

[2008/09/11 09:30:48, 3] smbd/reply.c:reply_tcon_and_X(707)
tconX service=IPC$
[2008/09/11 09:30:48, 3] smbd/process.c:process_smb(1206)
Transaction 4 of length 240
[2008/09/11 09:30:48, 3] smbd/process.c:switch_message(1005)
switch message SMBsesssetupX (pid 24084) conn 0x0
[2008/09/11 09:30:48, 3] smbd/sec_ctx.c:set_sec_ctx(287)
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2008/09/11 09:30:48, 3] smbd/sesssetup.c:reply_sesssetup_and_X(822)
wct=12 flg2=0xc807
[2008/09/11 09:30:48, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(633)
Doing spnego session setup
[2008/09/11 09:30:48, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(663)
NativeOS=[Windows 2002 Service Pack 2 2600] NativeLanMan=[Windows 2002 5.1] PrimaryDomain=[]
[2008/09/11 09:30:48, 3] smbd/sesssetup.c:reply_spnego_negotiate(525)
Got OID 1 3 6 1 4 1 311 2 2 10
[2008/09/11 09:30:48, 3] smbd/sesssetup.c:reply_spnego_negotiate(528)
Got secblob of size 40

When it does not work from the Windows 2003 R2 SP2 server itself I begin receiving

[2008/09/11 09:42:53, 3] smbd/reply.c:reply_tcon_and_X(707)
tconX service=IPC$
[2008/09/11 09:42:53, 3] smbd/process.c:timeout_processing(1459)
timeout_processing: End of file from client (client has disconnected)

These two problems could be completely unrelated but it's weird that they started at the same time. I sure would appreciate any advice or input on how to resolve these issues. We haven't made any changes to our HP-UX env aside from the CIFS upgrade attempting to address what was thought to be a compatibility issue

With the lack of further Windows-ly directions, I logged into the new server and made this change I found on the forums, but there was no change in the behavior that I am seeing.

control panel-->administrative tools-->Local Security Policy -> Security Settings -> Security Options. There will be a policy called "Microsoft network client: Send unencrypted password to third-party SMB servers" which you can enable.

Since we are connected to the domain with 'security=domain' then we are authenticating via the DC and not the local HP-UX server. Which was working until the DC switch was made. Does this mean that some other authentication method has been put in place? Or mabye I don't understand how Samba is doing it's authentication.

I need to know how to determine what has changed in our environment to cause this behavior and how to resolve it.

CG

[CelesteG]

old thread