REPORT: Profile problems & solution (fwd)

Thu May 6 19:44:54 GMT 1999

=====================================================================
Luke Kenneth Casson Leighton        |  Direct Dial   : (678) 443-6183
Systems Engineer / ISS XForce Team  |  ISS Front Desk: (678) 443-6000
Internet Security Systems, Inc.     |  ISS Fax       : (678) 443-6477

http://www.iss.net/    *Adaptive Network Security for the Enterprise*
     ISS Connect   -   International User Conference   -  May '99
=====================================================================

---------- Forwarded message ----------
Date: Thu, 6 May 1999 15:30:08 -0400 
From: "Kean,Jay" <KeanJa at amsworld.com>
To: Luke Kenneth Casson Leighton <lkcl at switchboard.net>
Cc: "'aperrin at demog.berkeley.edu'" <aperrin at demog.berkeley.edu>
Subject: RE: REPORT: Profile problems & solution

I have had a similar problem occur with a Net Use mapping via a Database
service under NT using Pick D3 Database. D3 is the NT user when logged
through the app to the Pick based app. Problem is that to data import we
first create a temp file on a DOS share that is create through a Net Use
command. If the share was remote to the system the share could be create but
never deleted through compiled Pick Code but could be via a TCL prompt using
a Net Use [drvletter] /delete command. This was rather perplexing. 

As soon as the location to the shared was changed to the local
application/data server the compiled Pick code worked. Since the file was
temporary this wasn't a big deal. Morale is that NT can produce some rather
strange results depending upon the way it is accessed. It seems that the
Novell share we originally mapped to was not allowing the "administrator"
level user of the D3 data server to remove the drive it created. 

While it may seem trivial, my thought here is that you have an
authentication problem on the NT side. Perhaps the PDC (or whatever is doing
your authentication) does not have rights to map to the \\server_name
<\\\\server_name>  for the given user. That seems to have been my issue in
the above case. Just a thought. I hope you find it useful.

		-----Original Message-----
		From:	Luke Kenneth Casson Leighton
[mailto:lkcl at SWITCHBOARD.NET]
		Sent:	Thursday, May 06, 1999 1:45 PM
		To:	NTBUGTRAQ at LISTSERV.NTBUGTRAQ.COM
		Subject:	Re: REPORT: Profile problems & solution

		i've been trying to find some sort of samba workaround for
this problem
		for over two, no, three years.  it boils down to the fact
that the nt
		login subsystem is responsible for making the connection to
the root of
		the profile share (\\server_name\share_name) which then
maintains this
		connection open in between logins.  exactly what the status
of this
		connection is once the user has logged out is in debate.
strictly
		speaking, the user is still logged in!

		connections to other shares on that machine, e.g to
\\server_name\IPC$,
		exacerbate the problem.  with this particular share (IPC$)
it is
		particularly awkward as a first connection to IPC$ can be
done
		anonymously.  likely solutions include dropping a connection
or reporting
		"Access denied" to a user that attempts to make another
connection when
		the following has already occurred:

		- connection to IPC$ (anon)
		- connection to file share (by user, with password)
		- disconnection to file share
		- connection to file share by OTHER user should have "access
denied".

		the maintenance of "state" info by nt clients on behalf of
their users, in
		the form of an open file / connection resource, is also
responsible for
		the bug in... [no msdn access] the function that enumerates
what users are
		logged in to a workstation: _possibly_ named WkstaUserLogon.
this bug was
		reported to ntbugtraq and it is known that a programmer at
microsoft was
		investigating this issue.

		luke

		<a href="mailto:lkcl at samba.org"   > Luke Kenneth Casson
Leighton  </a>
		<a href="http://www.cb1.com/~lkcl"> Samba and Network
Development </a>
		<a href="http://samba.org"        > Samba Web site
</a>

=====================================================================
		Luke Kenneth Casson Leighton        |  Direct Dial   : (678)
443-6183
		Systems Engineer / ISS XForce Team  |  ISS Front Desk: (678)
443-6000
		Internet Security Systems, Inc.     |  ISS Fax       : (678)
443-6477

		http://www.iss.net/    *Adaptive Network Security for the
Enterprise*
		     ISS Connect   -   International User Conference   -
May '99

=====================================================================

		On Fri, 7 May 1999, Andrew Perrin - Demography wrote:

		> Greetings.
		>
		> Readers of the list may remember our vexing problems with
profiles, which
		> seemed to coincide with the upgrade of Samba from
1.9.19-prealpha to the
		> 2.0.3 level. We are now running 2.0.3 as both login server
and file
		> server.
		>
		> The problem, essentially, was that the first user to log
into a PC after
		> it had joined the domain worked fine; subsequent users
were unable to
		> access the HKEY_USERS hive of the registry, and therefore
their
		> user-defined preferences weren't available. The only
reliable solution we
		> found was to wipe out both local and roaming profiles and
start again.
		> However, even after doing that, the second and following
users had similar
		> problems.
		>
		> Jean-Francois kindly provided advice on the Domain SID bug
and Jeremy's
		> patch for big-endian machines, both of which proved
helpful; however, the
		> problem persisted in a less-consistent way.
		>
		> After much agony, we noted that the NTUSER.DAT that showed
up in the
		> roaming profile directory of the user that DIDN'T work
actually belonged
		> to the first user, e.g., the one that had worked. That is:
say I had
		> logged into a PC as the first user; then I logged off and
nttest logged
		> on. The NTUSER.DAT file saved in nttest's profile
directory, when
		> examined, had clear references to my preferences in it
(just using strings
		> ntuser.dat).  We further noted that the ntprofile share
was staying open
		> for an indeterminate amount of time, so we guessed that
there was a
		> similar problem to the [homes] share, that is, that NT was
keeping the
		> connection open for quite a while.  (As is strongly
recommended, we keep
		> the profiles in a different share.)  So... we changed the
permission on
		> each user's profile directory to 0700 - accessible only by
the user. Now,
		> happily, if a user tries to login while the ntprofile
directory is still
		> connected, at least they just get an error for that
particular session
		> rather than screwing up their profile forever.
		>
		> Moral of the story:
		> - Set profile directories to chmod 0700, owned by the
user.
		> - If possible, use a deadtime parameter to try to get NT
to release the
		> ntprofile share.
		>
		>
---------------------------------------------------------------------
		> Andrew J. Perrin - aperrin at demog.berkeley.edu - NT/Unix
Admin/Support
		> Department of Demography    -    University of California
at Berkeley
		> 2232 Piedmont Avenue #2120  -    Berkeley, California,
94720-2120 USA
		> http://demog.berkeley.edu/~aperrin
--------------------------SEIU1199
		>
		>