Fear, Uncertainty, Doubt and Citrix on Win2k

Tue Jan 15 02:17:10 GMT 2002

"Lightfoot.Michael" wrote:
> 
> We are testing a new application which uses Citrix running on Win2k servers
> to access a Samba share which contains some Java files.  The whole thing is
> being launched by a batch file run by the user after logging into the Citrix
> server.
> 
> Details of Samba are 2.2.2 running on Solaris 2.6.  The only (slightly)
> non-standard thing is that I have patched reply.c to allow the "'" (single
> quote) character in user names (see my previous plea on 6/12 and Andrew
> Bartlett's reply the same day - thanks again Andrew!)

That patch certainly shouldn't be the problem.  I'm going to see about
getting something like that into Samba HEAD while maintaining the
appropriate level of paranoia...

> Here are the appropriate users.map entries:
> apt = Taylor.Alex ccilm.test taylor.alexw2k taylor.win2kadmin Win2k.User2
> cuc = Payne.David Win2k.User1 Win2k.admin
> 
> Both the above users are members of the Unix group p2 (see below)
> 
> Here are the global settings and the appropriate share entry:
> 
> [global]
>   wins server = act-secondary
>   interfaces = XXX.XXX.XXX.XXX/255.255.252.0
>    load printers = no
>    workgroup = COMCARE
>    security = server
>    password server = act-primary
>    encrypt passwords = yes

Is there any reason you can't use 'security = domain'?

This gives a much more stable connection to the DC, and acts in the same
way an NT4 member server operates.  Security=server uses an ugly hack in
the same way Win9X does its 'user level security'.

To join the domain use 'smbpasswd -j DOMAIN -U Administrator'.  This
will create a machine account (with the PDC's admin password) and set a
password on that account.  This allows Samba to pass both the challenge
and response to the DC and to get back sane error codes.

>    username map = /usr/local/samba/lib/users.map
>    domain master = no
>    local master = no
>    preferred master = no
>    os level = 0
>    server string = Samba (%v,%h)
>    log level = 2
>    guest account = guest
>    locking = yes
>    strict locking = yes
>    keepalive = 30
>    password level = 2

You should not need this, its only used with plaintext passwords.

>    socket options = TCP_NODELAY
>    map hidden = no
>    map archive = yes
>    preserve case = yes
>    case sensitive = yes
>    dead time = 15

This would have helped a bit, because by idling the connections you
force a new challenge to be generated and so get a few more auths out of
the PDC - but a terminal server is unlikely to be idle...

> [pracsys]
>    comment = Production users' share
>    valid users = @prod @p2
>    path = /export/home/pp2
>    browseable = no
>    writeable = yes
>    create mode = 0664
> 
> The following are some log extracts of failures and successes.  Firstly a
> failure to log in to the share
> 
> [2002/01/15 10:24:11, 1] smbd/password.c:server_validate(1227)
>   password server ACT-PRIMARY rejected the password

> 
> Now a success:
>
> [2002/01/15 10:34:32, 2] smbd/reply.c:reply_special(93)
>   netbios connect: name1=GRIFFIN          name2=ACT-TERMSERV01
> [2002/01/15 10:34:32, 2] smbd/reply.c:reply_special(112)
>   netbios connect: local=griffin remote=act-termserv01
> [2002/01/15 10:34:32, 1] smbd/service.c:make_connection(610)
>   act-termserv01 (163.233.5.39) connect to service pracsys as user cuc
> (uid=60028, gid=201) (pid 25627)

> The only other relevant error I can find is the follwoing:
> 
> [2002/01/15 10:22:14, 0] lib/util_sock.c:write_socket_data(542)
>   write_socket_data: write failure. Error = Broken pipe
> [2002/01/15 10:22:14, 2] smbd/process.c:timeout_processing(1130)
>   password server keepalive failed.
> 
> and again later:
> 
> [2002/01/15 10:35:49, 2] smbd/open.c:open_file(217)
>   Win2k.Admin opened file pracsys.properties read=Yes write=No (numopen=3)
> [2002/01/15 10:35:49, 0] lib/util_sock.c:write_socket_data(542)
>   write_socket_data: write failure. Error = Broken pipe
> [2002/01/15 10:35:49, 2] smbd/process.c:timeout_processing(1130)
>   password server keepalive failed.

Ahh, now I see what's going on...

Because you were using security = server, the connection (and it is
exactly one connection) from Win2kTS to Samba must be mirrored exactly
with a connection to the 'password server'.  

This second connection specifies a challenge, and Samba becomes a 'man
in the middle' between it and the client.   The client gets the
challenge only once, and uses it until the TCP/IP connection is
dropped.  Samba passes all passwords straight on to the DC for checking.

In the event that the second connection is broken, no further
authenticaions are possible.  This is what the 'password server 
rejected the password' is indicating.  (The name is "" because the
connection got shut down).

> Has anyone out there any idea what is happening here?  We can't even see a
> pattern to the successes and failures.  Originally it appeared that the
> first login would fail, but then subsequent ones succeed.  I postulated a
> probelm "waking up" the password server.  That theory disappeared in a puff
> off M$ fud when the opposite started to happen.  Lately failures have been
> less predictable.  We have found that restarting Samba would alleviate the
> problem for a short time, as would rebooting the Citrix server.

If either end is rebooted then the connection must be reestablished, and
you get a fresh chance at authenticating users until the connection is
dropped again.

> Samba is working flawlessly for shares on several Solaris systems (2.6 and
> 8), including the system in the logs above, accessed via production users NT
> desktops or the new test Win2k desktops.

This is because you only get one login, and nobody notices that the
password server dissapered in the meantime because the session is
already active.

The final thing I will say is also the most annoying.  Unlike NT
Terminal Server, it is not possible to make Win2k TSE make more than one
TCP/IP connection to the server.  This means that samba will have to
deal with all the traffic via one smbd.  This not only removes that
ability to use multiple CPUs, it also makes samba constantly have to
change userid - a rather expensive system call.  This can kill
performance.

Hope this helps,

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net