OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: REPORT: Profile problems & solution
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: REPORT: Profile problems & solution

  • To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
  • Subject: Re: REPORT: Profile problems & solution
  • From: Luke Kenneth Casson Leighton <lkclSWITCHBOARD.NET>
  • Date: Thu, 6 May 1999 18:45:04 +0100
  • Approved-By: Russ.CooperRC.ON.CA
  • Comments: cc: Andrew Perrin - Demography <aperrindemog.Berkeley.EDU>, Multiple recipients of list <samba-ntdomsamba.org>
  • In-Reply-To: <Pine.WNT.4.05.9905060841460.74-100000twins.qal.berkeley.edu>
  • Reply-To: Luke Kenneth Casson Leighton <lkclSWITCHBOARD.NET>
  • Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>
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:lkclsamba.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 - aperrindemog.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
>
>