[OpenAFS] Testing OpenAFS with Windows XP Roaming Profiles....

Claudio Prono claudio.prono@atpss.net
Fri, 17 Sep 2010 16:15:48 +0200


This is a multi-part message in MIME format.
--------------070101010800020109060802
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit



Jeffrey Altman ha scritto:
> On 9/15/2010 10:45 AM, Claudio Prono wrote:
>   
>> Hello all,
>>
>> I am testing a solution like: OpenAFS with kerberos, Windows XP with
>> Integrated logon and roaming profile.
>>
>> OpenAFS works, Kerberos works, integrated logon works... The profile on
>> AFS not.
>>
>> I have manually copied the profile in a directory on AFS like
>> "msprofile", edited the windows registry at key:
>>
>> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
>> NT\CurrentVersion\ProfileList and changed the key ProfileImagePath to
>> \\afs\mediaservice-test.pri\users\claudio\msprofile
>>
>> Deleted the local profile, rebooted the machine, logged in as claudio...
>> and...a new local profile was created!!! If i check the registry key, it
>> is changed again to the default (something like %SystemDrive%\Documents
>> and Settings\claudio.TESTAFS)...
>>
>> What i am doing wrong? What is the best solution?
>>
>> Cordially,
>>
>> Claudio Prono.
>>     
>
> Claudio:
>
> I cannot tell you what you are doing wrong because I do not know what is
> failing yet.   The logon process is extremely complicated and without
> identifying which of the many Windows operations is failing, it is
> impossible to provide advice as to what should be altered.
>
> You are not using Active Directory to provide the profile location
> information which is going to complicate manners.  The first thing you
> need to identify is what paths are actually being accessed and which are
> failing.  You can do this using the SysInternals Process Monitor tool.
> Configure it to log all file system activity starting from boot to a
> file.  Be sure to give it a disk with lots of open space.
>
> You can obtain the tool from
> http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
>
> After you have a failed logon attempt, you can search the log data for
> the path that you believe it should be attempting to access.  You can
> also search for the new profile path that is created and work backwards
> through the log seeking AFS file path operations that fail.  Note that
> all FASTIO operations will fail and that is normal.
>
> Jeffrey Altman
>
>
>   
> ------------------------------------------------------------------------
>
> !DSPAM:1,4c9365a0264548047658515!
Ok, i have done some step forward.

Now i have only a problem:

When i disconnect from the remote pc, it seems it drops first the
tickets of AFS, and then try to write the changes to the remote profile.
The result is: if i have the remote folder msprofile with an ACL like
system:anyuser all, it writes correctly the changes on the profile, if i
don't have that ACL, it fails to write remote profile.....

Now, the question is: how i can make Windows first write the updated
profile, then drop tickets?

The ACL system:anyuser all for the profile folder is not a good solution...

Any hint?





-- 
--------------------------------------------------------------------------------
Claudio Prono                         OPST
System Developer               
                                      Gsm: +39-349-54.33.258
@PSS Srl                              Tel: +39-011-32.72.100
Via San Bernardino, 17                Fax: +39-011-32.46.497
10141 Torino - ITALY                  http://atpss.net/disclaimer
--------------------------------------------------------------------------------
PGP Key - http://keys.atpss.net/c_prono.asc





--------------070101010800020109060802
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-15"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Jeffrey Altman ha scritto:
<blockquote cite="mid:4C9363DB.4040802@secure-endpoints.com" type="cite">
  <pre wrap="">On 9/15/2010 10:45 AM, Claudio Prono wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hello all,

I am testing a solution like: OpenAFS with kerberos, Windows XP with
Integrated logon and roaming profile.

OpenAFS works, Kerberos works, integrated logon works... The profile on
AFS not.

I have manually copied the profile in a directory on AFS like
"msprofile", edited the windows registry at key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\ProfileList and changed the key ProfileImagePath to
\\afs\mediaservice-test.pri\users\claudio\msprofile

Deleted the local profile, rebooted the machine, logged in as claudio...
and...a new local profile was created!!! If i check the registry key, it
is changed again to the default (something like %SystemDrive%\Documents
and Settings\claudio.TESTAFS)...

What i am doing wrong? What is the best solution?

Cordially,

Claudio Prono.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Claudio:

I cannot tell you what you are doing wrong because I do not know what is
failing yet.   The logon process is extremely complicated and without
identifying which of the many Windows operations is failing, it is
impossible to provide advice as to what should be altered.

You are not using Active Directory to provide the profile location
information which is going to complicate manners.  The first thing you
need to identify is what paths are actually being accessed and which are
failing.  You can do this using the SysInternals Process Monitor tool.
Configure it to log all file system activity starting from boot to a
file.  Be sure to give it a disk with lots of open space.

You can obtain the tool from
<a class="moz-txt-link-freetext" href="http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx">http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx</a>

After you have a failed logon attempt, you can search the log data for
the path that you believe it should be attempting to access.  You can
also search for the new profile path that is created and work backwards
through the log seeking AFS file path operations that fail.  Note that
all FASTIO operations will fail and that is normal.

Jeffrey Altman


  </pre>
  <pre wrap="">
<hr size="4" width="90%">
!DSPAM:1,4c9365a0264548047658515!</pre>
</blockquote>
Ok, i have done some step forward.<br>
<br>
Now i have only a problem: <br>
<br>
When i disconnect from the remote pc, it seems it drops first the
tickets of AFS, and then try to write the changes to the remote
profile. The result is: if i have the remote folder msprofile with an
ACL like system:anyuser all, it writes correctly the changes on the
profile, if i don't have that ACL, it fails to write remote profile.....<br>
<br>
Now, the question is: how i can make Windows first write the updated
profile, then drop tickets?<br>
<br>
The ACL system:anyuser all for the profile folder is not a good
solution...<br>
<br>
Any hint?<br>
<br>
<br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
--------------------------------------------------------------------------------
Claudio Prono                         OPST
System Developer               
                                      Gsm: +39-349-54.33.258
@PSS Srl                              Tel: +39-011-32.72.100
Via San Bernardino, 17                Fax: +39-011-32.46.497
10141 Torino - ITALY                  <a class="moz-txt-link-freetext" href="http://atpss.net/disclaimer">http://atpss.net/disclaimer</a>
--------------------------------------------------------------------------------
PGP Key - <a class="moz-txt-link-freetext" href="http://keys.atpss.net/c_prono.asc">http://keys.atpss.net/c_prono.asc</a>



</pre>
</body>
</html>

--------------070101010800020109060802--