Re: It must be simple, but...

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Thanks, Gregg. Your patience with someone that keeps saying, "Yes, but..."
is remarkable - it really is :-) I will try exactly what you suggested.
Sorry to be so stubborn :-(

BTW, is there an easy way to transfer all the settings of a local account
(on the client) to a new Domain account, or do I have to set everything up
manually?

Thanks again for your patience and good advice.

*M*



"Gregg Hill" <bogus@xxxxxxxxxxx> wrote in message
news:ePIMQ8H1FHA.3300@xxxxxxxxxxxxxxxxxxxxxxx
> Do exactly what I suggested and you will not be dizzy. You claim that
> "...but in this case it'd be better if I did" regarding sharing local
> drives. That may be the case, but you are still doing it incorrectly.
>
> I assume you have added both workstations to the new domain. If not, do so
> now. If they were members of a domain before, place them into a workgroup
> first, then add them to the SBS domain using the connectcomputer wizard.
>
> You are not doing what I recommended. DELETE the local accounts on the
> workstations. Do NOT "log on locally" as a local user; instead, log onto
> the DOMAIN, using the DOMAIN user accounts ONLY. Once you log on to the
> domain, you should be able to access server resources without further
> prompts for credentials.
>
> If you want the Client1 computer user to access Client2 computer folders,
> the easiest thing would be to add the Domain Users group to the share/NTFS
> permissions of the remote shared folder and give them whatever access you
> desire. Or, if you only want specific users to have access, then add
> Client1's desired DOMAIN user account to the share/NTFS permissions on
> Client2, and vice versa if you want 2 to access 1.
>
> Gregg Hill
>
>
>
>
> "Mocacius" <mocacius@xxxxxxx> wrote in message
> news:%23h$DiFG1FHA.1740@xxxxxxxxxxxxxxxxxxxxxxx
>>I understand why I shouldn't share the client drives, etc., and in general
>>I agree, but in this case it'd be better if I did.
>>
>> As far as the "Explanation Only" part, I even tried this...
>>
>> On the server - a logon was created UserName = UserN1, Pwd = trial335
>> On client1 - a local logon was created UserName = UserN1, Pwd =
>> trial335
>> On client 2 - a local logon was created UserName = UserN1, Pwd =
>> trial335
>>
>> All 3 user names and passwords are the same
>>
>> I then logged locally on client 1 and client 2 using the above
>> credentials, and then logged both clients on the domain (when accessing
>> the server shared drive), again, using the same credentials. Both
>> clients had the DOMAIN account in the shares permissions.
>>
>> I still could not access the client drives from each other.
>>
>> I'm getting dizzy <g>
>>
>> *M*
>>
>>
>> "Gregg Hill" <bogus@xxxxxxxxxxx> wrote in message
>> news:eNslVxD1FHA.3464@xxxxxxxxxxxxxxxxxxxxxxx
>>> Mocacius,
>>>
>>> It looks as though you are mixing a peer-to-peer setup with a domain
>>> setup. Why did you create domain accounts on the server and local
>>> accounts on the workstations?
>>>
>>> Remove the local workstation accounts and just use the domain accounts
>>> you created on the server when you log into the workstations. That will
>>> create profiles on the workstations that contain the domain user
>>> information. You do not need local user accounts at all on the
>>> workstations.
>>>
>>> What is happening is that you have set up peer-to-peer permissions in a
>>> domain. In order for your plan to work (explanation only!!! Do NOT do
>>> this!!), you would have to create a LUSR01 local account on the Client2
>>> computer with the same password used on Client1, and a LUSR02 local
>>> account on the Client1 computer, with the same password as the Client1
>>> user. See how screwy that gets? All you need to do is dump the local
>>> accounts, log into each workstation as the domain account you created,
>>> and get authentication from the server.
>>>
>>> If you MUST share your client drives (bad move from a security
>>> standpoint), then add the DOMAIN account of each user to the two
>>> workstations' share permissions.
>>>
>>> Gregg Hill
>>>
>>>
>>>
>>>
>>> "Mocacius" <mocacius@xxxxxxx> wrote in message
>>> news:%236IUrBA1FHA.3892@xxxxxxxxxxxxxxxxxxxxxxx
>>>> Just (finally <g>) moved the LAN to a new SBS2003 Server. At this
>>>> point, it's the only server, with 2 clients, both XP Pro.
>>>>
>>>> I am trying to make things work the way they user to work on NT4 (well
>>>> similar), but I think I must be missing something very basic. To
>>>> preface, on the recommendation from some in this NG, I purchased and
>>>> looked through the "Windws Small Business Server 2003", by Russel,
>>>> Crawford, Gerend, but I can't find the answers (may be because I don't
>>>> know what I'm looking for <smile>).
>>>>
>>>> Here is is in a nutshell..
>>>>
>>>> - SBS2003 has 2 user records created on it, U_SR01 and U_SR02, both
>>>> admin privileges
>>>> - Client #1, has a "local" user defined as LUSR01, Drive C is shared
>>>> for U_SR01 and U_SR02
>>>> - Client #2, has a "local" user defined as LUSR02, Drive C is shared
>>>> for U_SR01 and U_SR02
>>>>
>>>> Reboot all 3 systems
>>>> - Log on Client#1 as a local use, LUSR01
>>>> - Log on Client#2 as a local use, LUSR02
>>>>
>>>> From Client #1, through network neighborhood, I can see the SBS2003
>>>> server, and I can access its resources after I get prompted for and log
>>>> on as U_SR01.
>>>>
>>>> From Client #2, through network neighborhood, I can see the SBS2003
>>>> server, and I can access its resources after I get prompted for and log
>>>> on as U_SR02.
>>>>
>>>> From either client, I can see the other client, but when I try to
>>>> access the HD, I get an error message that I may not be authorized to
>>>> access it.
>>>>
>>>> I am probably missing something very simple, but you know, can't see
>>>> the forrest for the trees... :-(
>>>>
>>>> Any hints, anyone?
>>>>
>>>> *M*
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: Using EFS with Network Shares and SFU 3.5
    ... It does not take EFS into account. ... could again use the sharing server audit logs to see if success ... Read extended attribute and Read data, since the NFS client may ... Windows and *nix clients. ...
    (microsoft.public.windows.server.security)
  • Re: Adv Client with Workgroup Computers
    ... I was trying to use the SMS tools from the SMS server to initiate harware ... Inv for example the account is a domain account but the Client PC is in a ... Is there a procedure for installing the ADV client localy on a workgroup ... I have manually added to the WINS server. ...
    (microsoft.public.sms.admin)
  • Re: First Grade Basics Needed
    ... name should log me into my workstation account even if the server is down. ... I was planning on keeping the users's local accounts around for a while, ... workstations, push button on server, be sure light is blue, wait five ...
    (microsoft.public.windows.server.sbs)
  • Re: Horrible problem with SAMBA -- Does Karmic work?
    ... I have tried numerous times to set up SAMBA so that students can log into ... latest error is that the machine account isn't set up. ... Students can log in directly to the server or via ssh. ... but they do not appear to record the workstations. ...
    (Ubuntu)
  • Re: First Grade Basics Needed
    ... You took the server home, ... > http://servername/connectcomputer from all workstations. ... >> can read all the books I have. ... >> log in locally, but does not get me into my domain account, where all my ...
    (microsoft.public.windows.server.sbs)