Blockchain is a technology that underpins the success of Bitcoin and other digital currencies, but it has uses far beyond finance. Learn how blockchain works and why it is proving disruptive to other areas of IT.
COURSE of the MONTH
11 days, 1 hour left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Windows 2000 Server & Windows 2000 Professional Dual Boot
Posted on 2004-08-28
Hello All:
I am working on a backup and recovery project and I am in need of some help.
I have tried to install and configure Windows 2000 Server (NTFS) and Windows 2000 Professional (NTFS) in their own partitions. They both boot up fine however, I am experiencing some strange behavior. The system will reboot intermittently and or I will get the Windows 2000 NT Authority System Shutdown Service Code 128 “services.exe”. This seems to happen when I copy files from partition to partition or the CD-ROM. Any clues or ideas or help would be greatly appreciated?
Both operating systems have all of the up to date security patches and SP4 applied.
Thanks,
Joe
I am working on a backup and recovery project and I am in need of some help.
I have tried to install and configure Windows 2000 Server (NTFS) and Windows 2000 Professional (NTFS) in their own partitions. They both boot up fine however, I am experiencing some strange behavior. The system will reboot intermittently and or I will get the Windows 2000 NT Authority System Shutdown Service Code 128 “services.exe”. This seems to happen when I copy files from partition to partition or the CD-ROM. Any clues or ideas or help would be greatly appreciated?
Both operating systems have all of the up to date security patches and SP4 applied.
Thanks,
Joe
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
10
-
4
-
4
18 Comments
http://support.microsoft.com/default.aspx?scid=kb;en-us;318447
Please read the KB article posted above. The problem is most likely caused by having the two partitions seen and used by one Operatings System. When you boot up the Server partition and you try to copy to the partition with Professinal on it, there is confusion over the system shares and the NTFS partitions. It will happen to both OS's when they see the other partition. Essentially, the Operating System sees shares and NTFS permissions, that are not its own on its disk drives.
J
Please read the KB article posted above. The problem is most likely caused by having the two partitions seen and used by one Operatings System. When you boot up the Server partition and you try to copy to the partition with Professinal on it, there is confusion over the system shares and the NTFS partitions. It will happen to both OS's when they see the other partition. Essentially, the Operating System sees shares and NTFS permissions, that are not its own on its disk drives.
J
Important... the KB describes the problem, but I want to make sure you know that it cannot help you. The KB helps when this problem occurs on a single OS, not the dual boot system you have. You probably want to try to reinstall both systems using FAT permissions and then make sure not to share any drives.
J
J
jdeclue:
Thanks for your quick response. I was considering to use FAT32, thinking it was an NTFS security issue. Based on your response and suggestions, I will try this but... I would need to have the drives shared within their environments.
Example: This particular machine will primarily boot to Windows 2000 Professional 100% of the time unless the MAIN Server crashes. Windows 2000 Server will reside on the C:<PARTITION> and Windows 2000 Professional will reside on the D:<PARTITION> of the pc backup solution.
My additional question is... Using the PC's normal "100%" operating state "Windows 2000 Professional.", if I was to share the "D" Windows 2000 Professional Drive, will I continue to have the same problems if both partitions were formatted in FAT32? In the event the MAIN server crashed, then I would need to boot to the "C" partition using Windows 2000 Server with its "C" drive shared.
I hope my explanation was clear.
Thanks,
Joe
Thanks for your quick response. I was considering to use FAT32, thinking it was an NTFS security issue. Based on your response and suggestions, I will try this but... I would need to have the drives shared within their environments.
Example: This particular machine will primarily boot to Windows 2000 Professional 100% of the time unless the MAIN Server crashes. Windows 2000 Server will reside on the C:<PARTITION> and Windows 2000 Professional will reside on the D:<PARTITION> of the pc backup solution.
My additional question is... Using the PC's normal "100%" operating state "Windows 2000 Professional.", if I was to share the "D" Windows 2000 Professional Drive, will I continue to have the same problems if both partitions were formatted in FAT32? In the event the MAIN server crashed, then I would need to boot to the "C" partition using Windows 2000 Server with its "C" drive shared.
I hope my explanation was clear.
Thanks,
Joe
Active today
Sorry, but jdeclue's explanation is definitely not the issue here.
The two OSs couldn't care less about shares on the respective other partition; they simply don't see them. Shares are defined in the OS's registry, in HKLM\System\CurrentControl
NTFS isn't the problem here, either. Default permissions in Windows include only generic groups; these have well known SIDs, which are independent of the machine's SID; so permissions for the local Administrators group are available on either OS. The only issue would be if permissions to a folder on the "inactive" partition have been restricted to only(!) custom created local(!) groups or users; but the only thing this would lead to is an "Access denied" message, not problems with services.exe.
Independent of that, another indication that this explanation is incorrect would be that this happens as well when copying from the CDROM.
You might check your registry for rogue share entries anyway as described in the article; these entries occur if you delete a shared folder without removing the share first.
If the problem happens mostly during copying from CD, then you might have hardware or driver issues, but it has nothing at all to do with the fact that both partitions are NTFS.
Is there anything in the event log?
The two OSs couldn't care less about shares on the respective other partition; they simply don't see them. Shares are defined in the OS's registry, in HKLM\System\CurrentControl
NTFS isn't the problem here, either. Default permissions in Windows include only generic groups; these have well known SIDs, which are independent of the machine's SID; so permissions for the local Administrators group are available on either OS. The only issue would be if permissions to a folder on the "inactive" partition have been restricted to only(!) custom created local(!) groups or users; but the only thing this would lead to is an "Access denied" message, not problems with services.exe.
Independent of that, another indication that this explanation is incorrect would be that this happens as well when copying from the CDROM.
You might check your registry for rogue share entries anyway as described in the article; these entries occur if you delete a shared folder without removing the share first.
If the problem happens mostly during copying from CD, then you might have hardware or driver issues, but it has nothing at all to do with the fact that both partitions are NTFS.
Is there anything in the event log?
Well, that's kind of right. Are both of the installations computer members and in a domain? If the answer to that is yes, then the computer names are different. There is not suppose to be an issue here, but the Domain adds to the SID. I am assuming this is the case. When the domain adds it's portion to the sid, as long as they are both in the same Domain the well known security identifiers are the same, for well known objects. But for that to happen the computer now has its own unique security identifier, which is different for each.
Now with that said, if both of the computers are joined to the same domain and have unique names, then there should not be an issue. If one computer is in a workgroup and one is in a domain, or if one has file and print sharing and one does not then there is an issue. The KB does describe the exact problem, I am just not sure how it pertains to a dual install. Let me do a little more research and I will get back to it on Monday, hopefully you will find the answer! ;)
J
Now with that said, if both of the computers are joined to the same domain and have unique names, then there should not be an issue. If one computer is in a workgroup and one is in a domain, or if one has file and print sharing and one does not then there is an issue. The KB does describe the exact problem, I am just not sure how it pertains to a dual install. Let me do a little more research and I will get back to it on Monday, hopefully you will find the answer! ;)
J
I forgot one thing, Windows 2000 is supported as a dual boot with Win95, Win98, WinME and Windows NT. Windows XP is kind of supported, but you must configure them as above, same domain different names and they must be joined properly so that their SIDS are identical, as oBda suggests, in regards to well known security principals. Windows 2000 and Windows 2000 has never been a supported configuration, and I am not sure why. Maybe we will figure that out.
J
J
I found one other case in which this issue occurs and it is related to extending dynamic disks. The issue is resolved (or supposed to be) by installing Service Pack 4. What service pack are you running?
J
J
jdeclue:
It's a very simple pier to pier network with no need to log into a domain. Service Pack 4 is installed on both partitions. I looked at dynamic vs basic etc... Keeping in mind... Only one OS "Windows 2000 Professional" will be running at a time. The SID's should be unique... Do to different CD-Keys and OS's, True?
I am trying to keep this as simple as possible without the need of a third party software like System Commander or some other MultiBoot software. Based on what I have read, it should work.
I just joined this service and honestly, there are some pretty knowledgeable individuals that participate within this service, including yourself.
I will try another HDD with NTFS to rule out any hardware issues and if that fails I'll try FAT32. Hopefully we can figure this out. I am sure I'm not the first person trying to do this.
I'll List the Hardware I am using...
Compaq EVO D510 CMT
P4 2.8
1 Gigabyte RAM
Intel Pro 100 VM Embedded NIC
Intel Extreme Video Embedded
Western Digital 40 GIG HDD
Thanks to all for your suggestions and help!
Joe
It's a very simple pier to pier network with no need to log into a domain. Service Pack 4 is installed on both partitions. I looked at dynamic vs basic etc... Keeping in mind... Only one OS "Windows 2000 Professional" will be running at a time. The SID's should be unique... Do to different CD-Keys and OS's, True?
I am trying to keep this as simple as possible without the need of a third party software like System Commander or some other MultiBoot software. Based on what I have read, it should work.
I just joined this service and honestly, there are some pretty knowledgeable individuals that participate within this service, including yourself.
I will try another HDD with NTFS to rule out any hardware issues and if that fails I'll try FAT32. Hopefully we can figure this out. I am sure I'm not the first person trying to do this.
I'll List the Hardware I am using...
Compaq EVO D510 CMT
P4 2.8
1 Gigabyte RAM
Intel Pro 100 VM Embedded NIC
Intel Extreme Video Embedded
Western Digital 40 GIG HDD
Thanks to all for your suggestions and help!
Joe
Active today
jdeclue,
please read my post again. The issue at hand has nothing to do at all with NTFS permissions or shares on either OS. Nothing.
Again: Shares are provided by the Server service. This service is obviously not running on the "inactive" OS/partition, so the "active" OS/partition will neither see the other OS's shares, nor can it be confused by them.
NTFS permissions aren't a problem, either. Windows isn't even confused about ACEs it can't match to an account name. All you would get if there were permission problems would be an "Access denied", but no problems with any services. Try it for yourself: Create a folder "Test". Create a new user, "TestUser". Assign "Full Control" to TestUser for the folder Test. In the security properties, you'll now see the account "TestUser". Close the properties page. Now delete the user "TestUser". Reopen the security properties of the Test folder, and instead of the name "TestUser", you'll now see a SID, which can't be resolved to a name anymore. And that's all that happens with unknown ACEs; no confusion, no services.exe shutdown, no nothing. And as I said before, in a default installation, there won't even be unknown SIDs on the other partition. The Well Known SIDs have their name from having the exact same SID on *every* Windows installation, whether they are domain members or stand-alone machines. The local group Administrators will have the SID S-1-5-32-544 on both the W2k Professional and the W2k Server partition. An ACE with this entry will be resolved correctly by either OS on either partition without any problems.
The KB318447 article does not describe the exact problem. It describes an issue that causes the Server service to not be able to start at all when *booting* the machine, caused by references to folders that are supposed to be shared, but aren't there anymore because they were deleted without removing the share first. jpuglin can successfully boot into both OSs, so even though those stale entries should be avoided and deleted if present, they don't cause the symptoms described in the article. Apart from that, the problem can occur under the following condition:
"This issue may occur if there are incorrect references to shared folders in the following registry key:
HKEY_LOCAL_MACHINE\System\
This issue may also occur if a stale security value is left for shares that no longer exist under the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\
This only affects the active OS. This has nothing at all to do with another (inactive!) OS residing on another partition on the same machine. The active OS doesn't know (and wouldn't care) that the other partition can be booted as well. It's just another drive with folders and files on it, nothing more and nothing less.
Sorry, but you are on the wrong track here.
The dual boot support only affects the actual boot process, and whether the NT boot loader is able to successfully start the respective OS entered in boot.ini. W2k and W2k are supported by default, they use the same boot files. You just can't use the Windows dual boot to boot into W2k and Linux, or W2k and OS/2, or Win95 and WinMe. jpuglin can successfully boot into both OSs, and they are on different partitions, so that's not the issue either.
And, yes, I've successfully used W2k pro and Server on the same HD in different partitions, as well as Server 2003 and XP on the same HD in different partitions; in every case with NTFS and individual shares on either OS, and in every case without problems.
Well Known Security Identifiers in Windows Server Operating Systems
http://support.microsoft.com/?kbid=243330
jpuglin,
again: Is there anything in your system or application event log indicating problems?
Are there unknown devices in the Device Manager?
Is the CDROM a burner, or just a reader?
Have you tried to tweak BIOS settings trying to gain performance?
Seeing as how this happens when writing to the disk, this might well be a hardware or driver issue. Boot into W2k pro, run chkdsk on the W2k pro partition. Boot into W2k Server, run chkdsk on the W2k Server partition.
Description of Enhanced Chkdsk, Autochk, and Chkntfs Tools in Windows 2000
http://support.microsoft.com/?kbid=218461
please read my post again. The issue at hand has nothing to do at all with NTFS permissions or shares on either OS. Nothing.
Again: Shares are provided by the Server service. This service is obviously not running on the "inactive" OS/partition, so the "active" OS/partition will neither see the other OS's shares, nor can it be confused by them.
NTFS permissions aren't a problem, either. Windows isn't even confused about ACEs it can't match to an account name. All you would get if there were permission problems would be an "Access denied", but no problems with any services. Try it for yourself: Create a folder "Test". Create a new user, "TestUser". Assign "Full Control" to TestUser for the folder Test. In the security properties, you'll now see the account "TestUser". Close the properties page. Now delete the user "TestUser". Reopen the security properties of the Test folder, and instead of the name "TestUser", you'll now see a SID, which can't be resolved to a name anymore. And that's all that happens with unknown ACEs; no confusion, no services.exe shutdown, no nothing. And as I said before, in a default installation, there won't even be unknown SIDs on the other partition. The Well Known SIDs have their name from having the exact same SID on *every* Windows installation, whether they are domain members or stand-alone machines. The local group Administrators will have the SID S-1-5-32-544 on both the W2k Professional and the W2k Server partition. An ACE with this entry will be resolved correctly by either OS on either partition without any problems.
The KB318447 article does not describe the exact problem. It describes an issue that causes the Server service to not be able to start at all when *booting* the machine, caused by references to folders that are supposed to be shared, but aren't there anymore because they were deleted without removing the share first. jpuglin can successfully boot into both OSs, so even though those stale entries should be avoided and deleted if present, they don't cause the symptoms described in the article. Apart from that, the problem can occur under the following condition:
"This issue may occur if there are incorrect references to shared folders in the following registry key:
HKEY_LOCAL_MACHINE\System\
This issue may also occur if a stale security value is left for shares that no longer exist under the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\
This only affects the active OS. This has nothing at all to do with another (inactive!) OS residing on another partition on the same machine. The active OS doesn't know (and wouldn't care) that the other partition can be booted as well. It's just another drive with folders and files on it, nothing more and nothing less.
Sorry, but you are on the wrong track here.
The dual boot support only affects the actual boot process, and whether the NT boot loader is able to successfully start the respective OS entered in boot.ini. W2k and W2k are supported by default, they use the same boot files. You just can't use the Windows dual boot to boot into W2k and Linux, or W2k and OS/2, or Win95 and WinMe. jpuglin can successfully boot into both OSs, and they are on different partitions, so that's not the issue either.
And, yes, I've successfully used W2k pro and Server on the same HD in different partitions, as well as Server 2003 and XP on the same HD in different partitions; in every case with NTFS and individual shares on either OS, and in every case without problems.
Well Known Security Identifiers in Windows Server Operating Systems
http://support.microsoft.com/?kbid=243330
jpuglin,
again: Is there anything in your system or application event log indicating problems?
Are there unknown devices in the Device Manager?
Is the CDROM a burner, or just a reader?
Have you tried to tweak BIOS settings trying to gain performance?
Seeing as how this happens when writing to the disk, this might well be a hardware or driver issue. Boot into W2k pro, run chkdsk on the W2k pro partition. Boot into W2k Server, run chkdsk on the W2k Server partition.
Description of Enhanced Chkdsk, Autochk, and Chkntfs Tools in Windows 2000
http://support.microsoft.com/?kbid=218461
jdeclue & oBda:
some further developments... I ran chkdsk and chkntfs and no issues were noted. I cleaned and purged to event logs and attempted to create the problem. With great success I was able to reproduce the issue mutiple times however, the "SYSTEM" event log was corrupt so I could not see any notifications. Additionally, on 2 cases I received an small window indicating an error stating "Unknown Hard Error" with a red "x". The system was extremely slow, explorer dumped, navigating was next to impossible, then the system eventually rebooted on its own, "This is the first time this happened". During the reboot the BIOS screen noted there was no HDD installed (the system didn't see the HDD) and requested press f1 to continue or f10 to enter setup. I powered down the pc, disconnect and reconnected the cables to the hdd, booted the system again then, it recognized the hdd. I booted back into the OS "Windows 2000 Professional" and launched Event Viewer... the "System" event log was corrupt and nothing was abnormal in the application event log.
You guys have been great... I am confused with this issue.
I am using a western digital 40 GIG with 2 PRIMARY partitions "C" & "D" and the type is basic. No logical drive or dynamic disks are used in this configuration. Everything in working properly in the device manager, no unknown hardware or (red "x"'s) indicating the hardware is malfunctioning or needs drivers.
Joe
some further developments... I ran chkdsk and chkntfs and no issues were noted. I cleaned and purged to event logs and attempted to create the problem. With great success I was able to reproduce the issue mutiple times however, the "SYSTEM" event log was corrupt so I could not see any notifications. Additionally, on 2 cases I received an small window indicating an error stating "Unknown Hard Error" with a red "x". The system was extremely slow, explorer dumped, navigating was next to impossible, then the system eventually rebooted on its own, "This is the first time this happened". During the reboot the BIOS screen noted there was no HDD installed (the system didn't see the HDD) and requested press f1 to continue or f10 to enter setup. I powered down the pc, disconnect and reconnected the cables to the hdd, booted the system again then, it recognized the hdd. I booted back into the OS "Windows 2000 Professional" and launched Event Viewer... the "System" event log was corrupt and nothing was abnormal in the application event log.
You guys have been great... I am confused with this issue.
I am using a western digital 40 GIG with 2 PRIMARY partitions "C" & "D" and the type is basic. No logical drive or dynamic disks are used in this configuration. Everything in working properly in the device manager, no unknown hardware or (red "x"'s) indicating the hardware is malfunctioning or needs drivers.
Joe
Are they dynamic disks or basic. You may want to keep them basic. I can't find much regarding this actual problem.
oBda, I made a mistake and assumed the computers were in a domain. My bad. So here is why that makes a difference. Again you are kind of right, but as soon as a computer joins a domain, the well known security principal are given the domain portion of the SID. THis is shown in the article above by the "domain" designator in the SID. At this point the identifier is now different, but the same within a domain. But in order to access shared resources you must have a number of keys related to those sids on your token, while the sid for an account like "administrator" is now the same within a domain, the combination of credentials on your token identify your account and your computer. So, does a well known secerity identifer change .. yes. In addition, the actual SID is not the only piece of the pie, as there are tokens, credentials and methods of authentication that take place which combined, distinguish the user, computer and access to a resource. Services.exe, and other applications which attempt a secured authentication process rely on much more than a SID... and if the stars and moon are not aligned then you will have a problem.
"Unique Computer Name
You can set up a server so that it has multiple installations of Windows 2000 (using any Windows 2000 product) or Windows XP (or any Whistler product) on multiple partitions. However, you must use a different computer name for each installation if the computer participates in a Windows 2000 domain. Because a unique security identifier (SID) is used for each installation of Windows 2000 on a domain, the computer name for each installation must be unique—even for multiple installations on the same computer. " ------MICROSOFT
http://www.microsoft.com/windows2000/techinfo/administration/management/mltiboot.asp
J
oBda, I made a mistake and assumed the computers were in a domain. My bad. So here is why that makes a difference. Again you are kind of right, but as soon as a computer joins a domain, the well known security principal are given the domain portion of the SID. THis is shown in the article above by the "domain" designator in the SID. At this point the identifier is now different, but the same within a domain. But in order to access shared resources you must have a number of keys related to those sids on your token, while the sid for an account like "administrator" is now the same within a domain, the combination of credentials on your token identify your account and your computer. So, does a well known secerity identifer change .. yes. In addition, the actual SID is not the only piece of the pie, as there are tokens, credentials and methods of authentication that take place which combined, distinguish the user, computer and access to a resource. Services.exe, and other applications which attempt a secured authentication process rely on much more than a SID... and if the stars and moon are not aligned then you will have a problem.
"Unique Computer Name
You can set up a server so that it has multiple installations of Windows 2000 (using any Windows 2000 product) or Windows XP (or any Whistler product) on multiple partitions. However, you must use a different computer name for each installation if the computer participates in a Windows 2000 domain. Because a unique security identifier (SID) is used for each installation of Windows 2000 on a domain, the computer name for each installation must be unique—even for multiple installations on the same computer. " ------MICROSOFT
http://www.microsoft.com/windows2000/techinfo/administration/management/mltiboot.asp
J
Active today
If the BIOS doesn't recognize the HD, then it seems like that's indeed hardware related. Is the CDROM connected to the same port as the hard drive? If so, make the HD the master on the primary IDE, the CD master on the secondary.
In W2k Device Manager, check if the CDROM is configured to use DMA; W2k for some reasons usually uses PIO (if you're using the MS IDE drivers, it's under properties of the IDE channel the CD is connected to, otherwise it needs to be configured with the chipset software you installed).
If you have Ghost or something similar, you might try to transfer the contents of the HD to a new one and try if the problems persist.
Either way, if you have important files on that HD, make a backup of them.
To get your system event log working again, you need to delete (or move) the corrupt log file:
Start services.msc, set the start type of the Event Log to "Disabled", reboot your machine.
Move (or delete) the sysevent.evt file in %Systemroot%\system32\conf
Start services.msc, set the start type of the Event Log to "Automatic", reboot your machine.
How to Delete Corrupt Event Viewer Log Files
http://support.microsoft.com/?kbid=172156
Here's a post-SP4 hotfix for that:
Event Logs Are Corrupted
http://support.microsoft.com/?kbid=829246
In W2k Device Manager, check if the CDROM is configured to use DMA; W2k for some reasons usually uses PIO (if you're using the MS IDE drivers, it's under properties of the IDE channel the CD is connected to, otherwise it needs to be configured with the chipset software you installed).
If you have Ghost or something similar, you might try to transfer the contents of the HD to a new one and try if the problems persist.
Either way, if you have important files on that HD, make a backup of them.
To get your system event log working again, you need to delete (or move) the corrupt log file:
Start services.msc, set the start type of the Event Log to "Disabled", reboot your machine.
Move (or delete) the sysevent.evt file in %Systemroot%\system32\conf
Start services.msc, set the start type of the Event Log to "Automatic", reboot your machine.
How to Delete Corrupt Event Viewer Log Files
http://support.microsoft.com/?kbid=172156
Here's a post-SP4 hotfix for that:
Event Logs Are Corrupted
http://support.microsoft.com/?kbid=829246
This is too funny, how did we all get goin at the same time... ok enough of the flaming... this may be getting a lot easier... ;)
J
J
I was too busy posting to see your last comment, so with all of the new developments OBda is absolutely correct. I would verify the config and then narrow in on the hard drive. I have had to deal with the corrupt event viewer issue before and the above directions work like a charm. I guess that error message really through me, but this is making a lot more sense.
J
J
Active today
jdeclue,
as far as the well known SIDs are concerned, it really doesn't matter whether the machine is a member of a domain or not. These SIDs never change. The *local* group Administrators, for example, has the SID S-1-5-32-544, worldwide, on any NT based installation, whether the machine is member of a domain or not (try it for yourself with PsGetSID from http://www.sysinternals.com/ntw2k/freeware/psgetsid.shtml). That is why you can access files on the other (NTFS) partition at all; if the default permissions for the file system were applied to machine specific accounts, you wouldn't have access to files on a partition were another OS resides. You wouldn't even be able to take ownership, you simply wouldn't be able to gain access.
The *global* group domain administrators of course have a domain specific SID, but this group (if the machine is domain member) will only be a member of the local group Administrators, and the Full Access NTFS permissions are still applied to the local Administrators group.
NTFS permissions are not the issue here, completely independent of domain membership or not.
And, no, I'm not flaming. I'm just correcting.
as far as the well known SIDs are concerned, it really doesn't matter whether the machine is a member of a domain or not. These SIDs never change. The *local* group Administrators, for example, has the SID S-1-5-32-544, worldwide, on any NT based installation, whether the machine is member of a domain or not (try it for yourself with PsGetSID from http://www.sysinternals.com/ntw2k/freeware/psgetsid.shtml). That is why you can access files on the other (NTFS) partition at all; if the default permissions for the file system were applied to machine specific accounts, you wouldn't have access to files on a partition were another OS resides. You wouldn't even be able to take ownership, you simply wouldn't be able to gain access.
The *global* group domain administrators of course have a domain specific SID, but this group (if the machine is domain member) will only be a member of the local group Administrators, and the Full Access NTFS permissions are still applied to the local Administrators group.
NTFS permissions are not the issue here, completely independent of domain membership or not.
And, no, I'm not flaming. I'm just correcting.
I know you wish to correct, the problem is that I don't disagree with you regarding a local sid, the issue (which no longer has anything to do with jplugins question) is that when a computer joins a domain and uses resources many of the sids are independent... well known sids which contain a domain reference are not universal. These SIDS do get applied in the access control lists of resources, ntfs or otherwise. Join a computer to a domain and put shares and file permissions for domain accounts... then put up a different windows 2000 machine on the computer and start accessing those files, stick the second in a workgroup or different domain. Any process which has to enumerate the aces and match them to tokens will have a serious issue. Many processes use RPC and LPC to travel the stack, in which case they use authentication. The machine expects that the local security is correct. While I agree with you that a SID displayed is an unknown Sid (orphaned), I differ here in that a machine does have an issue with an unkown or corrupt security principles. Foreign security principles are handled on a domain level as a result of trusts, broken trust and removed trusts. But a workstation does not handle foreign security principles like a domain does. Even a domain has an issue if the foreign security principle is introduced without some concept of the original trust. Essentially, by dual booting a windows 2000 worksation, I can make one side see the equivalent of a foreign security principle, which was never introduced through a trust, which to a workstations is a corrupted SID. That needs to be handled very different than an orphaned sid.
I will be honest with you, the only reason I know about this is because I have written security tools which deal with sids and aces. And when developing certain apps, when I incorrectly set local permissions with wrong sids (and the workstation is a member of a domain), it really screws things up.
J
I will be honest with you, the only reason I know about this is because I have written security tools which deal with sids and aces. And when developing certain apps, when I incorrectly set local permissions with wrong sids (and the workstation is a member of a domain), it really screws things up.
J
Featured Post
The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.
One of a set of tools we're offering as a way of saying thank you for being a part of the community.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
NTFS file system has been developed by Microsoft that is widely used by Windows NT operating system and its advanced versions. It is the mostly used over FAT file system as it provides superior features like reliability, security, storage, efficienc…
Check out the latest tech news, community articles, and expert highlights in August's newsletter.
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
Suggested Courses
Course of the Month11 days, 1 hour left to enroll
770 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.