• Sharing In Windows 11 - Beware cloned images with identical SIDs

    From Java Jive@java@evij.com.invalid to alt.comp.os.windows-11 on Wed Dec 10 20:12:26 2025
    From Newsgroup: alt.comp.os.windows-11

    Appended below are the instructions I've posted previously to other
    Windows newsgroups for sharing folders across PCs. They are correct for Windows 7, and almost correct, slight changes only, for all of Windows
    2000 through to 11.

    However, now there is a new problem with cloned images. After a recent update, two PCs running cloned images of W11 with identical SIDs can not access each others shares. Symptom is that attempting to access a share
    that previously was accessible throws up a credentials - username &
    password - dialog that no obvious entries will make go away. The
    solution is to change the W11 SID on one of the PCs, either by running a sysprep (which IIRC will exasperatingly lose all your user
    customisations), or changing the SID with a utility such as SIDCHG64:

    https://www.stratesave.com/html/sidchg.html

    AIUI, buying a key for this is quite expensive, but, as described at the
    above link, this utility has a trial key available from the first third
    of each month lasting until the end of it, which private individuals
    like myself may use to make a small number of changes. I've just tested
    this, and it worked, though unfortunately, some customisations were
    still lost, those to the Start Menu and other Personalisation settings. Fortunately, the worst time consumer, Explorer settings, look as though they've survived.

    But, FFS, this is so typical of Microshit! For years they tried to tell
    us that you shouldn't allow machines with the same SIDs on the same
    network, but no-one could really explain convincingly why. Then
    SysInternals, having produced a utility called NewSID, conducted tests
    that showed having the same SIDs on the same network didn't matter, and
    so stopped developing NewSID, and everyone stopped worrying about
    duplicate SIDs. Microsoft took over SysInternals, and likewise didn't
    develop NewSID any further, but now have produced an update that breaks everything and needs a utility like NewSID to fix the resulting mess!

    Again I ask: Just where do Microsoft go to find programmers as bad as this?


    Windows Sharing Instructions
    ============================

    IMO, M$'s default sharing arrangements have always been dangerously
    insecure. What follows is the comparatively secure
    way that I've always set up sharing, ever since Windows 2000.

    Note: These are W7 instructions only, other versions of Windows will
    obviously be similar but not exactly the same, because of M$'
    pointless and idiotic habit of hiding all the control levers in
    different places with every new edition of Windows, thus forcing
    people continually to relearn everything they've known for years. (Can
    you imagine the catastrophic chaos that would result on the roads if
    car manufacturers decided to do that?).

    In what follows, I assume that you want to create shares on each PC
    visible to others, and that none are work PCs authenticating to a domain controller server.

    On each PC:

    1) Go into ...
    Control Panel, All Control Panel Items,System,
    Advanced system settings, Computer Name, Change
    ... and ensure that name and workgroup are changed to something
    memorable from the defaults, and that the latter is the same for all
    the machines that you wish to share files together.

    2) Any user wishing to access a share on a PC must have a user
    account on that PC, so set up the necessary accounts up on each PC,
    giving them the same logon user id and passwd as they normally use on
    their own PC. (If on a particular PC you want a user only to be able
    to access a share, but not be able to sign on to it, you still need
    his/her account to exist, but then it must be added to a block list in
    that PC's security policy - however, this may not be possible on
    some lower cost editions of Windows, and is beyond the scope of these
    notes).

    3) Go into ...
    Control Panel, All Control Panel Items,
    Network and Sharing Center, Advanced sharing settings
    ... and set the following:
    Network discovery
    Probably on, unless reason otherwise;
    File and printer sharing
    Probably on, unless reason otherwise;
    Public folder sharing
    Probably off, unless reason otherwise;
    Media streaming
    Probably off, unless reason otherwise;
    File sharing connections
    Use 128-bit, unless reason otherwise;
    Password protected sharing
    Turn on;
    HomeGroup connections
    Use user accounts and passwords.

    4) On each directory or drive of each machine that you want to
    share, creating subdirectories for this as required ...
    <rt-click>, Share with,
    Advanced sharing, Advanced sharing;
    Select Share this folder;
    Type a suitable share name
    (Note: ending it with a '$' will hide it from
    users casually browsing from other Windows PCs,
    but Linux users may still see it via Samba);
    Type a suitable comment, if required;
    Click Permissions, remove the relatively insecure
    default permissions offered, and then click ...
    Add, Advanced, Find Now
    ... and by <click>ing and <ctrl-click>ing select and add
    the following:
    Admininstrators
    System
    Authenticated Users
    ... and then give them the following permissions ...
    Admininstrators Full Control
    System Full Control
    Authenticated Users Read or Read/Change
    as required

    5) If necessary, but DO NOT DO THE FOLLOWING ON THE WINDOWS FOLDER OR
    OTHER SYSTEM FOLDERS (hopefully you're not trying to share these anyway,
    not normally recommended) including user folders but sub-directories of
    the latter that you've created especially to share are perfectly safe ...

    <rt-click> the drive or directory being shared
    and select ...
    Properties
    Security
    ... and ensure the above permissions are replicated on the drive or
    folder itself.

    Notes:

    To prevent a particular account from logging on to a particular PC -
    if, say, you want a child to be able to log on to a share on your PC so
    the child must have his user account credentials existing on the PC, but
    you don't want the child actually logging on to the PC itself - then
    you must be running a version of Windows that allows access to the
    Security Policy management console (from memory, Home versions do not,
    and note that I haven't needed to do this in quite a while, so I can't guarantee these instructions, but IMS they're correct):
    1 Get a Run dialog, say by <Win R>
    2 secpol.msc <Enter>
    3 Security Settings, Local Policies, User Rights Assignment
    4 Add particular username to 'Deny logon locally' list, Ok
    (by default this has only 'Guest')

    To prevent logging on using an M$ account, again you need to get into
    the Security Policy management console:
    1 Get a Run dialog, say by <Win R>
    2 secpol.msc <Enter>
    3 Security Settings, Local Policies, Security Options
    4 Click 'Accounts: Block Microsoft accounts'
    5 Select from the drop-down list ...
    'Users can’t add or log on with Microsoft accounts'
    ... Ok

    To allow XP and earlier to connect to more recent versions of Windows
    such as 10, or those between which are running Microsoft Security
    Essentials, you have to enable SMBv1. To do this ...

    Windows 10+: Run Powershell as Admin and enter the following:
    Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

    Windows 7-: SMBv1 is enabled by default, so normally no change is
    needed, however, ISTR that installing Microsoft Security Essentials
    disables it, in which case you have to set or make a registry change to
    enable it, as follows:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

    Registry entry: SMB1
    REG_DWORD: 0 = Disabled
    REG_DWORD: 1 = Enabled
    Default: 1 = Enabled (No registry key is created)

    Windows 8 versions: I'm not sure about and cannot test here, but one or
    the other of the above should work.

    In all versions of Windows, allegedly you have to reboot after making
    the changes, but perhaps restarting the service may suffice; again, as
    it's a while since I had to do this, I can't definitely say that this
    would work:
    net stop Server
    net start Server
    --

    Fake news kills!

    I may be contacted via the contact address given on my website: www.macfh.co.uk
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Java Jive@java@evij.com.invalid to alt.comp.os.windows-11 on Wed Dec 10 20:28:58 2025
    From Newsgroup: alt.comp.os.windows-11

    On 2025-12-10 20:12, Java Jive wrote:

    However, now there is a new problem with cloned images.  After a recent update, two PCs running cloned images of W11 with identical SIDs can not access each others shares.  Symptom is that attempting to access a share that previously was accessible throws up a credentials  -  username & password  -  dialog that no obvious entries will make go away.  The solution is to change the W11 SID on one of the PCs, [...]

    Meant to add that this only affects sharing between W11 PCs with
    identical SIDs, (and possibly between two W10 or W11 PCs ditto; I have
    no evidence about W10 either way, although I suspect that in fact it
    won't be a problem). Sharing between a W7 PC and either a W11 or
    another W7 PC both having the same SIDs doesn't seem to be a problem.
    --

    Fake news kills!

    I may be contacted via the contact address given on my website: www.macfh.co.uk

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Andy Burns@usenet@andyburns.uk to alt.comp.os.windows-11 on Wed Dec 10 20:52:52 2025
    From Newsgroup: alt.comp.os.windows-11

    Java Jive wrote:

    SysInternals, having produced a utility called NewSID, conducted tests
    that showed having the same SIDs on the same network didn't matter, and
    so stopped developing NewSID

    I thought the reason they stopped producing newSID was that they
    realised that joining a domain created a new SID anyway?

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Graham J@nobody@nowhere.co.uk to alt.comp.os.windows-11 on Wed Dec 10 22:03:02 2025
    From Newsgroup: alt.comp.os.windows-11

    Java Jive wrote:
    Appended below are the instructions I've posted previously to other
    Windows newsgroups for sharing folders across PCs.  They are correct for Windows 7, and almost correct, slight changes only, for all of Windows
    2000 through to 11.

    With apologies for the top post:

    Snip the bit about identical SIDs

    What follows is really good. I've tried to write something similar
    myself but yours is much better.

    Please could you re-post it here every few weeks so everybody can find
    it. Alternatively do you have a website that you could publish it on?
    Thanks.
    --
    Graham J


    Windows Sharing Instructions
    ============================

    IMO, M$'s default sharing arrangements have always been dangerously insecure.  What follows is the comparatively secure
    way that I've always set up sharing, ever since Windows 2000.

    Note: These are W7 instructions only, other versions of Windows will obviously be similar but not exactly the same, because of M$'
    pointless and idiotic habit of hiding all the control levers in
    different places with every new edition of Windows, thus forcing
    people continually to relearn everything they've known for years. (Can
    you imagine the catastrophic chaos that would result on the roads if
    car manufacturers decided to do that?).

    In what follows, I assume that you want to create shares on each PC
    visible to others, and that none are work PCs authenticating to a domain controller server.

    On each PC:

    1)    Go into ...
        Control Panel, All Control Panel Items,System,
        Advanced system settings, Computer Name, Change
    ... and ensure that name and workgroup are changed to something
    memorable from the defaults, and that the latter is the same for all
    the machines that you wish to share files together.

    2)    Any user wishing to access a share on a PC must have a user
    account on that PC, so set up the necessary accounts up on each PC,
    giving them the same logon user id and passwd as they normally use on
    their own PC.  (If on a particular PC you want a user only to be able
    to access a share, but not be able to sign on to it, you still need
    his/her account to exist, but then it must be added to a block list in
    that PC's security policy  -  however, this may not be possible on
    some lower cost editions of Windows, and is beyond the scope of these
    notes).

    3)    Go into ...
        Control Panel, All Control Panel Items,
        Network and Sharing Center, Advanced sharing settings
    ... and set the following:
        Network discovery
            Probably on, unless reason otherwise;
        File and printer sharing
            Probably on, unless reason otherwise;
        Public folder sharing
            Probably off, unless reason otherwise;
        Media streaming
            Probably off, unless reason otherwise;
        File sharing connections
            Use 128-bit, unless reason otherwise;
        Password protected sharing
            Turn on;
        HomeGroup connections
            Use user accounts and passwords.

    4)    On each directory or drive of each machine that you want to
    share, creating subdirectories for this as required ...
            <rt-click>, Share with,
                Advanced sharing, Advanced sharing;
            Select Share this folder;
            Type a suitable share name
                (Note:  ending it with a '$' will hide it from
                users casually browsing from other Windows PCs,
                but Linux users may still see it via Samba);
            Type a suitable comment, if required;
            Click Permissions, remove the relatively insecure
            default permissions offered, and then click ...
                Add, Advanced, Find Now
            ... and by <click>ing and <ctrl-click>ing select and add
            the following:
                Admininstrators
                System
                Authenticated Users
            ... and then give them the following permissions ...
                Admininstrators        Full Control
                System            Full Control
                Authenticated Users    Read or Read/Change
                                as required

    5)    If necessary, but DO NOT DO THE FOLLOWING ON THE WINDOWS FOLDER OR OTHER SYSTEM FOLDERS (hopefully you're not trying to share these anyway,
    not normally recommended) including user folders but sub-directories of
    the latter that you've created especially to share are perfectly safe ...

    <rt-click> the drive or directory being shared
    and select ...
            Properties
            Security
    ... and ensure the above permissions are replicated on the drive or
    folder itself.

    Notes:

    To prevent a particular account from logging on to a particular PC  -
    if, say, you want a child to be able to log on to a share on your PC so
    the child must have his user account credentials existing on the PC, but
    you don't want the child actually logging on to the PC itself  -  then
    you must be running a version of Windows that allows access to the
    Security Policy management console (from memory, Home versions do not,
    and note that I haven't needed to do this in quite a while, so I can't guarantee these instructions, but IMS they're correct):
      1  Get a Run dialog, say by <Win R>
      2  secpol.msc <Enter>
      3  Security Settings, Local Policies, User Rights Assignment
      4  Add particular username to 'Deny logon locally' list, Ok
           (by default this has only 'Guest')

    To prevent logging on using an M$ account, again you need to get into
    the Security Policy management console:
      1  Get a Run dialog, say by <Win R>
      2  secpol.msc <Enter>
      3  Security Settings, Local Policies, Security Options
      4  Click 'Accounts: Block Microsoft accounts'
      5  Select from the drop-down list ...
           'Users can’t add or log on with Microsoft accounts'
         ... Ok

    To allow XP and earlier to connect to more recent versions of Windows
    such as 10, or those between which are running Microsoft Security Essentials, you have to enable SMBv1.  To do this ...

    Windows 10+: Run Powershell as Admin and enter the following:
      Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

    Windows 7-:  SMBv1 is enabled by default, so normally no change is
    needed, however, ISTR that installing Microsoft Security Essentials
    disables it, in which case you have to set or make a registry change to enable it, as follows:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters


    Registry entry: SMB1
    REG_DWORD: 0 = Disabled
    REG_DWORD: 1 = Enabled
    Default: 1 = Enabled (No registry key is created)

    Windows 8 versions:  I'm not sure about and cannot test here, but one or the other of the above should work.

    In all versions of Windows, allegedly you have to reboot after making
    the changes, but perhaps restarting the service may suffice; again, as
    it's a while since I had to do this, I can't definitely say that this
    would work:
      net stop Server
      net start Server




    --
    Graham J
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Java Jive@java@evij.com.invalid to alt.comp.os.windows-11 on Wed Dec 10 22:07:53 2025
    From Newsgroup: alt.comp.os.windows-11

    On 2025-12-10 20:52, Andy Burns wrote:

    Java Jive wrote:

    SysInternals, having produced a utility called NewSID, conducted tests
    that showed having the same SIDs on the same network didn't matter,
    and so stopped developing NewSID

    I thought the reason they stopped producing newSID was that they
    realised that joining a domain created a new SID anyway?

    Don't think so, here's his original reasoning ...

    https://learn.microsoft.com/en-us/archive/blogs/markrussinovich/the-machine-sid-duplication-myth-and-why-sysprep-matters

    ... in which he states that, with one exception of Domain Controllers explained therein, SIDs are never used to authenticate to a remote
    machine, their use is only internal, and therefore cannot cause a
    problem on a network. Here's how he and another summarised the findings
    at the time, note in the latter that Microsoft actually planned changes
    to Sysprep accordingly (I don't know if they ever happened):

    "The New Best Practice

    It’s a little surprising that the SID duplication issue has gone unquestioned for so long, but everyone has assumed that someone else
    knew exactly why it was a problem. To my chagrin, NewSID has never
    really done anything useful and there’s no reason to miss it now that
    it’s retired. Note that Sysprep resets other machine-specific state
    that, if duplicated, can cause problems for certain applications like
    Windows Server Update Services (WSUS), so Microsoft’s support policy
    will still require cloned systems to be made unique with Sysprep."

    https://www.markwilson.co.uk/blog/2009/11/mark-russinovich-explains-the-machine-sid-duplication-myth.htm

    "“Microsoft™'s official policy on SID duplication will also now change
    and look for Sysprep to be updated in the future to skip SID generation
    as an option. Note that Sysprep resets other machine-specific state
    that, if duplicated, can cause problems for certain applications like
    Windows Server Update Services (WSUS), so Microsoft™'s support policy
    will still require cloned systems to be made unique with Sysprep.”"
    --

    Fake news kills!

    I may be contacted via the contact address given on my website: www.macfh.co.uk

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Java Jive@java@evij.com.invalid to alt.comp.os.windows-11 on Wed Dec 10 23:23:36 2025
    From Newsgroup: alt.comp.os.windows-11

    On 2025-12-10 20:28, Java Jive wrote:
    On 2025-12-10 20:12, Java Jive wrote:

    However, now there is a new problem with cloned images.  After a
    recent update, two PCs running cloned images of W11 with identical
    SIDs can not access each others shares.  Symptom is that attempting to
    access a share that previously was accessible throws up a credentials
    -  username & password  -  dialog that no obvious entries will make go >> away.  The solution is to change the W11 SID on one of the PCs, [...]

    Meant to add that this only affects sharing between W11 PCs with
    identical SIDs, (and possibly between two W10 or W11 PCs ditto; I have
    no evidence about W10 either way, although I suspect that in fact it
    won't be a problem).  Sharing between a W7 PC and either a W11 or
    another W7 PC both having the same SIDs doesn't seem to be a problem.

    Can now confirm that so far, unless an update under the extended scheme
    breaks something, not a problem with W11 <-> W10, so W10 as per W7 is
    trouble free.
    --

    Fake news kills!

    I may be contacted via the contact address given on my website: www.macfh.co.uk

    --- Synchronet 3.21a-Linux NewsLink 1.2