- Posts: 1390
- Thank you received: 0
windows 2003 server are always has "read only" att
18 years 2 months ago #16865
by Smurf
Wayne Murphy
Firewall.cx Team Member
www.firewall.cx
Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
Replied by Smurf on topic Re: windows 2003 server are always has "read only" att
That sounds ok, glad you have sorted out your issue.
As a general rule of thumb, what i tend to do is give the root drive permissions of only admin access and don't assign any permissions for users at the root level. This is purely because when you add a new folder, it will in inherit the rights from the parent. This way i ensure that any creation of folders then need to have specific rights assigned and it ensures that i have actually configured the permissions and access is not given to people i don't want to by mistake.
Hope it makes sense, this is the way i do things.
As a general rule of thumb, what i tend to do is give the root drive permissions of only admin access and don't assign any permissions for users at the root level. This is purely because when you add a new folder, it will in inherit the rights from the parent. This way i ensure that any creation of folders then need to have specific rights assigned and it ensures that i have actually configured the permissions and access is not given to people i don't want to by mistake.
Hope it makes sense, this is the way i do things.
Wayne Murphy
Firewall.cx Team Member
www.firewall.cx
Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
18 years 2 months ago #16889
by monsky
Replied by monsky on topic Re: windows 2003 server are always has "read only" att
tnx smurf,
did i make it right? what is the best way you could suggest?
which means what i did is the reverse. i gave Everyone full access to the root drive, (so that's the reason why i was obliged to create special permissions, i unmarked create files/folders, create write data, etc. to prevent unwanted files created outside of their respective folders.)what i tend to do is give the root drive permissions of only admin access and don't assign any permissions for users at the root level.
did i make it right? what is the best way you could suggest?
18 years 2 months ago #16893
by Smurf
Wayne Murphy
Firewall.cx Team Member
www.firewall.cx
Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
Replied by Smurf on topic Re: windows 2003 server are always has "read only" att
When i am setting up a server i configure the NTFS permissions on the root drive to be just admin rights. I do this so that i can then further define the DATA drives to incorporate a shared folder for different departments.
For example;
F: - Administrators - Full; Domain Admins - Full
F:\Finance - Inherit above + GG_Finance - Write (and everything assigned along with it)
F:\Personell - Inherit above + GG_Personell - Write
etc...
The reason this is done, if any of the admins create a new folder in the root of the drive and then forget to configure the permissions, access isn't give to people by mistake.
You also know that because the F:\Finance is a finance share, if a new folder is created into the share, usually 99.9% of the time, ALL finance users will also need access to it, therefore no additional admin is required (and the finance users can create their own folders in that share anyway.
If, a folder for the Finance office is required in F:\Finance that only he/she wants access to, it can still be done so long as the permissions are changed, this would have been defined anyway by a request so it can be acheived.
By setting a rule of least access (most restrictive) at the root, you are ensuring that people don't get access to resources when they are not supposed to.
Also, further down in the drive structure you can then start to add the DENY rule to some of the really sensitive data.
So, F:\Personel you may want to add GG_Finance - DENY ?
Hope it makes sense why i tend to do it this way. At the end of the day its personal choice but we need to deal with administrators that are not necessarily as clued up as ourselves so we like to make sure that thought goes into the permissions so we make it most restrictive.
For example;
F: - Administrators - Full; Domain Admins - Full
F:\Finance - Inherit above + GG_Finance - Write (and everything assigned along with it)
F:\Personell - Inherit above + GG_Personell - Write
etc...
The reason this is done, if any of the admins create a new folder in the root of the drive and then forget to configure the permissions, access isn't give to people by mistake.
You also know that because the F:\Finance is a finance share, if a new folder is created into the share, usually 99.9% of the time, ALL finance users will also need access to it, therefore no additional admin is required (and the finance users can create their own folders in that share anyway.
If, a folder for the Finance office is required in F:\Finance that only he/she wants access to, it can still be done so long as the permissions are changed, this would have been defined anyway by a request so it can be acheived.
By setting a rule of least access (most restrictive) at the root, you are ensuring that people don't get access to resources when they are not supposed to.
Also, further down in the drive structure you can then start to add the DENY rule to some of the really sensitive data.
So, F:\Personel you may want to add GG_Finance - DENY ?
Hope it makes sense why i tend to do it this way. At the end of the day its personal choice but we need to deal with administrators that are not necessarily as clued up as ourselves so we like to make sure that thought goes into the permissions so we make it most restrictive.
Wayne Murphy
Firewall.cx Team Member
www.firewall.cx
Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
Time to create page: 0.123 seconds