Posts Tagged ‘Permissions’

Public

Worksite permissions default to everyone have access to everything. When a workspace is set to Public no permissions are restricted every if they are listed in the security list

Private

Private mode restricts access per the permissions listed 

FAQ

Read/Write Permission vs Full Access

Full Access gives users permissions to change existing permissions. Read/Write gives full access to the data

How do I give users read Access to a Workspace

Set it as Private

Great a group with all users and assign this read

Setup Users to full access

How can I get a list of all private or public workspaces?

SELECT p.prj_id, p.prj_name, p.prj_descript, p.prj_owner FROM mhgroup.projects p (NOLOCK) WHERE p.subtype = 'work' AND p.default_security = 'X'

To get a list of public workspaces you would change p.default_security = ‘X’ to ‘P’.

SELECT p.prj_id, p.prj_name, p.prj_descript, p.prj_owner FROM mhgroup.projects p (NOLOCK) WHERE p.subtype = 'work' AND p.default_security = 'P'

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

List the permissions on all the folders

$OutFile = "C:\temp\Permissions.csv"
Remove-Item $OutFile -ErrorAction SilentlyContinue
$Header = "Folder Path,Exception,IdentityReference,AccessControlType,IsInherited,InheritanceFlags,PropagationFlags"
Add-Content -Value $Header -Path $OutFile 

$RootPath = "D:\Shares\Users$"

try
{
#to add subfolders add - Recurse after $RootPath
    $Folders = dir $RootPath 2>&1 | where {$_.psiscontainer -eq $true} 
}
catch [System.Exception]
{
    $_.Exception.Message
}

foreach ($Folder in $Folders){
    
    try
    { 
        $ACLs = get-acl $Folder.fullname | ForEach-Object { $_.Access  }
        $Exception = $false 
      }
    catch [System.Exception]
    {
        $Exception = $true
        $SystemMessage = $_.Exception.Message 
    }
    Finally
    {
        Foreach ($ACL in $ACLs)
        {
             if ($Exception -eq $false) {
            $OutInfo = $Folder.Fullname + "," + $Exception  + "," + $ACL.IdentityReference  + "," + $ACL.AccessControlType + "," + $ACL.IsInherited + "," + $ACL.InheritanceFlags + "," + $ACL.PropagationFlags
             }
           else {
            $OutInfo = $Folder.Fullname + "," + $Exception  + "," + $SystemMessage
           }
           Add-Content -Value $OutInfo -Path $OutFile
       }
    }
}

Change the permissions

#######################################################
# 
# I put this script together to fix the permissions on users' home folders
# that had gotten messed up when they were moved to a new fileserver
# cluster.  After many attempts that 'almost' worked, I incorporated scripts
# from fellow SpiceHeads, most notably Martin Pugh (Martin9700).  An 
# edit or two from others, (Simon Matthews helped with the Set-ACL syntax 
# and Martin Boyle contributed the Set-Strictmode line for debugging), and
# I fixed up the logging output.
# 
# There's a couple of comments in the script that I left in but really only apply
# to the limited type of environment I was dealing with (2003 functional domain 
# with no access to the ActiveDirectory module).  (I figure I can't be the only 
# with overlords stuck in the past.)
# 
# Mike Schulman (s31064) 11/19/2015
# 
#######################################################

#Set-Strictmode -Version Latest -Verbose	##### Uncomment for configuring to your situation, then comment out again when you've got it right.

$Path = "D:\Shares\Users$"

##### Permissions adds the users/groups and the permissions they should have.  The actual User should not be added here.  
##### What's on the line below is an example only.  The format is domain\user-group:Permission.  
##### Separate additional users/groups with a comma and enclose the list in "".

$Permissions = "%yourdomainname%\Domain Admins:FullControl"

# Setup Access Rules
# $Domain = (Get-ADDomain).NetBIOSName	##### Need to set statically on next line because of 2003 limitations.
$Domain = 'ENCOM'
$AccessRules = @()
ForEach ($Perm in $Permissions.Split(","))
{	$Group = $Perm.Split(":")[0]
	$Level = $Perm.Split(":")[1]
	$AccessRules += New-Object System.Security.AccessControl.FileSystemAccessRule($Group,$Level, "ContainerInherit, ObjectInherit", 

"None", "Allow")
}

##### Setup Logging
##### Pasting this script as text into a PS command line causes the line below to throw an error and place the log file in the C:\ folder.  The script still works.

$Log = "$(Split-Path $MyInvocation.MyCommand.Path)\Set-UserACL-$(Get-Date -format 'MMddyy-hhmm').log"
Add-Content -Value "$(Get-Date): Script begins" -Path $Log
Add-Content -Value "$(Get-Date): Processing folder: $Path" -Path $Log

##### This is where it all starts to happen.
##### You can also modify the -Path in the Get-ChildItem line to limit the number of folders affected during testing.

$Dirs = Get-ChildItem -Path "$Path\*" | Where { $_.PSisContainer }
$UserError = @()
ForEach ($Dir in $Dirs)
{	$User = Split-Path $Dir.Fullname -Leaf
	Try
	{	Add-Content -Value "-----------------------------------------------" -Path $Log
	 	Add-Content -Value "$(Get-Date): Testing $($User): $($Dir.Fullname)" -Path $Log

##### The next line should be        $Test = Get-ADUser $User -ErrorAction Stop
##### It will test for the existence of the user before looping through the script.  I had to take it out because of the limitations of my environment.

	 	$ACL = Get-Acl $Dir -ErrorAction Stop
        
        ##### Set inheritance to no
		#$ACL.SetAccessRuleProtection($true, $false)
        #Add-Content -Value "$(Get-Date): Inheritance for $User set successfully" -Path $Log
        
        ##### Set owner to user
		#$ACL.SetOwner([System.Security.Principal.NTAccount]$User)
        #Add-Content -Value "$(Get-Date): Owner $User set successfully" -Path $Log
        
        ##### Remove old permissions
		$ACL.Access | ForEach { [Void]$ACL.RemoveAccessRule($_) }
        Add-Content -Value "$(Get-Date): Old permissions for $User removed successfully" -Path $Log
        
        ##### Set new permissions
		ForEach ($Rule in $AccessRules)
		{	$ACL.AddAccessRule($Rule)
		}
		$UserRule = New-Object System.Security.AccessControl.FileSystemAccessRule("$Domain\$User","Modify", "ContainerInherit, 

ObjectInherit", "None", "Allow")
		$ACL.AddAccessRule($UserRule)
		Set-Acl -Path $Dir -AclObject $ACL -ErrorAction Stop
        Add-Content -Value "$(Get-Date): New permissions for $User set successfully" -Path $Log
	}
	Catch

##### This is where the errors get logged.  The first line logs them to the console, and the next two lines add them to the log file.

	{	Write-Host "Unable to process $($Dir.Fullname) because $($Error[0])" -ForegroundColor Red
		Add-Content -Value "-----------------------------------------------" -Path $Log
        		Add-Content -Value "$(Get-Date): Unable to process $($Dir.Fullname) because $($Error[0])" -Path $Log
	}
}

##### This just closes the log file.

Add-Content -Value "-----------------------------------------------" -Path $Log
Add-Content -Value "$(Get-Date): Script completed" -Path $Log
VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

One Way without Restart Service

I’ve come across a great way of resetting a SQL server “sa” password if you don’t have it, don’t have an account with sufficient privileges to reset it via SSMS, and most importantly, don’t have to stop the SQL services so processing can continue.fkgqx81huis863c-medium1

All you will need is psexec  (in the sysinternals  toolkit) available here à https://technet.microsoft.com/en-us/sysinternals/pxexec.aspx

Once the tools are extracted to a directory on the server:

Psexec.exe –s –i “{full path to the ssms.exe”}

This will start the SQL Management Studio as the NTSERVICE\SYSTEM account … enter the name of the SQL Server (or localhost) and then you’re in … reset the sa password in there

 

Another way

 

  1. Stop SQL Server Service
  2. Start is with 
    net start MSSQLSERVER /m"SQLCMD"
  3. sqlcmd -SServerName\InstanceName
  4. CREATE LOGIN RecoveryAcct WITH PASSWORD=’TempPass1’
    GO
  5. SP_ADDSRVROLEMEMBER RecoveryAcct,SYSADMIN
    GO
    This was on Microsoft SQL Server 2008 (SP2) – 10.0.4067.0 (X64).
     
VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

onbehalfofUser A and B are secretaries of Manager C and have permissions to send “on Behalf of” their Manager

User A works under User B and User B have access to specfic folders ( not full ) of User A

User A drafts an email and puts it in her Draft Folder

User B checks this email , modifies where required , and sends on Behalf of Manager C from User A’s Drafts

When the email is sent ( with Manager C in from field ) , instead of sending on Behalf of Manager C , it actually comes dierect from User B

When User B composes a new message ( with Manager C in from field ) it works.

For this to work , User B actually needs Full Access Permissions to User A’s mailbox ( not just to specific folders )

 

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)