Potentialy due to all problems with connecting XP to win7 people are already glad to be able to connect to WIN7, but there seems to be a huge scurity hole in the process: [note] As I examin shares on win7 (controll panel shares) ACL's require a full grant on Everyone// it's unclear what read and change and full mean... As previous inter connections connections are made effects are less clear restriction seem to be less strickt what makes the shares ACL tricky to handle and test for security problems!!!!! [/note] The ACL Everyone: FULL seems to be required for all shares to work ???!!!! [note] but everyone is rather LARGE: "The Everyone group encompasses": well everyone. That is, it includes all the built it users and groups that come with Windows XP/win7 as well as any administrator defined users and groups. It also includes the service and system accounts that are created and any anonymous accounts that connect to the computer without providing any login credentials. Lastly, it includes the Guest account. [/note] As an acl GROUP grant is placed on the share ( a group of users(NOT individual users,but this is unmanagable)) the statement seems to be ignored !! The requirement of an EVERYONE:FULL is IMPLICITELY A SECURITY BREACH.... Relying on the file security restriction is a different matter. The SHARED security is the first security protection setting it: The need to use EVERYONE:FULL is killing the security purpose [/note] User/password all username passwords are synced by batch process and used on ALL machines files access to the files is granted by group but for the sake of the exercise a grant to authenticated users is added to ensure the file's protection is not the problem (implicit security breach but this is a test) what is a problem is the need to reboot.... since(clear credentials) all gets confused by first opening another share by that user then the state of the share switches virtually to authenticated user instead of everyone (first refused/then allowed(once logged in guest plays less in the game) UGLY to reproduce Basical settings and tests: Where can I find more on this, links to more professional security setup please.
There are some default shares which you can always disable (I mean administrative shares) if you are in workgroup situation+default public shares (disable them). But believe me nothing has ever happened to system with default settings unless you share user name and password. Though viruses and crackers can take advantage of situation if the system is not patched.
Opus: you sound like Microsoft trying to defend crappy,not working badly designed software. As there are no patches to correct for the problem does not mean there is no problem !!!! the issue has nothing to do with passwords or patches.... BUT WITH The assumed way of working as it was working in XP and is NOT WORKING in windows 7.(has NEVER WORKED SP0/SP1!) Due to this fact the manufacturing (intentionally? since test seem to be done badly on basic functions) supports hackers and blocks users to really secure their system. MY claim is the above DOES NOT WORK IN WIN7!!!!!!! Yes it works for users !!!!! BUT THAT IS NOT PREFERABLE AND UN-MAINTAINABILITY!!!! IT SEEMS NOT TO WORK FOR GROUP's (Correctly defined in control panel and working correctly for file access permissions[non share]) THIS BUG ????!!!! FORCES HUGE SECURITY RISKS on a OS that is supposed/mentioned state of the art. (Sorry for shouting, is intended but not intended to anyone personally) My cry is a CRY for help, is the above really as I state, or am I missing Something that is the reason I pledge the world for help Any help link or info is welcome
Well this doesn't work if the particular user has permissions of admin like if the user is say normal user and accidentally assigned domain admin right, it will bypass any effective permissions on a particular share provided Domain Admin had been assigned FULL control over the aforementioned share.
'l check them all in detail, behavior to say the least is odd: user works =file and user pw are ok/// group permission fails=>indeicates at least a bug common on multiple machines (no domain= less professionaly used) (simple construct group={users } group=>File (works/local) share with group fails. unless everyone !!
What do you mean by "group" over here? If not domain then are you referring to homegroup, workgroup or user groups?
Clearly user groups in a work group (i'm not working in a domain) The ms text is mainly bulls**t you can share if you share it to a USER or to everyone ...... that's all what is said just a group ACL where multiple users are collected does not seem to work at all. If I'm right : it is as the examples say 1 user or the WORLD independent of home/workgroup ...... VERY PRIMITIVE years 70 implementation ??? (XP was much better ) why the hell are group acl's for you can not use them Evan administrator rights do not help at all....(but that would not be a good requirement) the behavior seems very consistent IT DOES NOT WORK ! can anyone confirm accordingly to the spec's it should . Maybe in a domain I do not know as a simple group acl is not working this would mean for every share, possibly every file ... add all users individually this can run into the thousands , suppose now 1 user takes a different mission how can one change this ???? security would be a complete MESS.
we can generalize what we want, and declare "it works just fine" Or I am doing something incredibly wrong , OR there is a HUGE BUG in WIndows 7 killing all possible security PS the setACL tool just confirms the setting as defined by the shares : on the shares: it just confirms the above given commands (except they DO NOT WORK)
HomeGroup security gives anyone in the group access to any shared folder or printer. If you need to restrict access to shared folders and printers on a user-by-user basis, or if you have computers that don’t run Windows 7, you might not want to set up a homegroup. Windows 7 supports password-protected and passwordless file sharing. Before I explain this, I need to give you some background. In the original Windows NT workgroup network security model, when you attempted to use a network resource shared by another computer, Windows would see if your username and password matched an account on that remote computer. One of four things would happen: • If the username and password exactly matched an account defined on the remote computer, you got that user’s privileges on the remote machine for reading and writing files. • If the username matched but the password didn’t, you were prompted to enter the correct password. • If the username didn’t match any predefined account, or if you failed to supply the correct password, you got the privileges accorded to the Guest account, if the Guest account was enabled. • If the Guest account was disabled—and it usually was—you were denied access. The problem with this system is that it required you to create user accounts on each computer you wanted to reach over the network. Multiply, say, 5 users times 5 computers, and you had 25 user accounts to configure. What a pain! When you make a Windows 7 computer a member of a homegroup, it uses a built-in user account named HomeGroupUser$ when it accesses shared resources on other computers in the group. The member computers all have this same account name set up, with the same password (which is derived from the homegroup’s password in some way), so that all member computers can use any shared resource. When you share a library, folder, or printer with the homegroup, Windows gives the user account HomeGroupUser$ permission to read, or to read and write the files in that folder. When you use Internet Explorer to try to view your computer from outside on the Internet, and you are prompted for a username and password, or shared folders are visible, Microsoft file sharing services are being exposed to the Internet. If you have a shared connection to the Internet, you need to enable Windows Firewall or enable filtering on your Internet connection. At the very least, you must block TCP/UDP ports 137–139 and 445. Don’t leave this unfixed.