We had a question put through about setting up a files share and allow the external public users access without requiring credentials, although not a good idea due to security as anyone on the internet can potentially access the share and dump viruses and trojans on to it hence opening up an entry point that could easily be exploited, reduced security.
It was a requirement so we did a little research and the following is what we came up with:
- Right click on the folder you want to share, on the Share tab note hte Network Path
- Now go to start and search “Local Security Policy” and press enter
- Expand “Local Policies” and then Click Security Options
- Find the Policy: “Network access: Let Everyone permissions apply to anonymous users” and set the setting to “Enabled” and click OK
- Now find the Policy: “Network access: Shares that can be accessed anonymously” and enter the Network path you noted in step one into the text box and click OK
- Now open Command Prompt, you can search cmd in the Start search and press enter
- Type the following command and press enter: gpupdate /force
- Now you should be able access the share without having the need to enter credentials but if they try accessing other share they will be prompted with the login dialogue box
Again, we cannot emphasise enough how bad of an idea this is, unless you have a genuine requirement for it and reduce the risk as much as possible.
By allowing unrestricted access you are opening an entry point that could easily be used. huge amount of security issues, e.g.
We had a question about delegating read permissions to bitlocker recovery keys stored in active directory for standard users, they had followed the process outlined in the following article but hadn’t worked for them, we then tested the same process and it didn’t work for us either:
We then tried the DelegateBitLocker.vbs script in the following link: http://technet.microsoft.com/en-us/library/cc771778(v=ws.10).aspx#BKMK_AppendixA we edited the script so it would only apply to the computers OU.
‘ Connect to Discretional ACL (DACL) for domain object
Set objRootLDAP = GetObject(“LDAP://rootDSE”)
FROM: strPathToDomain = “LDAP://” & objRootLDAP.Get(“defaultNamingContext”) ‘ e.g. string dc=fabrikam,dc=com
TO: strPathToDomain = “LDAP://CN=Computer,DC=Fabrikam,DC=com”
Set objDomain = GetObject(strPathToDomain)
WScript.Echo “Accessing object: ” + objDomain.Get(“distinguishedName”)
Set objDescriptor = objDomain.Get(“ntSecurityDescriptor”)
Set objDacl = objDescriptor.DiscretionaryAcl
This showed that it gives the group in question read permissions to inherited object recovery information, instead of just the restricted attributes of the object, keep in mind this is exposing only read only attributes, we tried this using ldp-ace which also worked:
The process for calculating password expiry is simply the last set date + the limit in the domain policy. Therefore if you change the policy from say 1 year to six months, it will be re-calculated to expire a user’s password in six months from their last set date. Any accounts beyond that will automatically expire. Likewise if there has been no policy and you set a policy for 90 days. Those passwords that have been “set” longer than 90 days would expire.
More information on this and scripts to identify accounts that are about to expire can be found here:
Find out when your Password Expires:
If you are using fine grained password policies in Server 2008, this will be slightly different as the domain policy is not the ultimate controller of password expiry. Please take a look at the RSOP section of the following: http://technet.microsoft.com/en-us/library/cc770394(WS.10).aspx
For more information on Fine Grained Passwords take a look at the following:
If you are considering separate policy for students and staff, then Fine Grained Passwords is greatly improved in Windows 2012:
The following flow chart show a quick overview of what happens when a Password Age Policy is set and the scripts to detect expired users: