SharePoint Online CSOM Associated Site Groups AssociatedMemberGroup AssociatedOwnerGroup AssociatedVisitorGroup - powershell

Using the SharePoint Online CSOM, I have created a site and been able to set a number of things on the site. When a site is created using CSOM, the default groups are not created. I have created the groups okay however due to creating the groups outside the site creation process, I now need to assign them as the default groups on the site.
I've got the following code which doesn't come back with any errors in PowerShell but it doesn't set the groups either. Has anyone managed to achieve this?
$MemberGroupId = 101
$OwnerGroupId = 102
$VisitorGroupId = 103
$Web = $ClientContext.Web
$Groups = $Web.SiteGroups
$ClientContext.Load($Groups)
$ClientContext.ExecuteQuery()
$Web.AssociatedMemberGroup = $Groups.GetById($MemberGroupId)
$Web.AssociatedOwnerGroup = $Groups.GetById($OwnerGroupId)
$Web.AssociatedVisitorGroup = $Groups.GetById($VisitorGroupId)
$Web.Update()
I read in a couple of places that people had, had issues with these AssociatedMemberGroup, AssociatedOwnerGroup and AssociatedVisitorGroup properties so had set them instead by using $Web.AllProperties but I'm not sure how to do this and it certainly seems like a more complicated way.

Not sure if you found a solution for this. If not, try the following:
$groups = $web.SiteGroups
$clientContext.Load($groups)
$clientContext.ExecuteQuery()
$group = $groups.GetByName("Your Visitors Group Name")
$clientContext.Load($group)
$web.AssociatedVisitorGroup = $group
$web.Update()
$clientContext.ExecuteQuery()
Let me know how that works.

Related

MS Graph API - Group & membership info

I'm trying to pull out a listing of all groups in our Azure Active Directory org along with all the associated members (be them users, groups, contacts, etc).
Since I was unable to locate a method to do this through the various Microsoft portals with a simple export button I began the process of obtaining access to the Microsoft Graph API/SDK via Powershell.
I'm by no means a PowerShell expert as it's not one of my go-to scripts; however, from what I can tell the ability to pull group info in this fashion is fairly limited.
The following is what I've been able to accomplish thus far:
Pull in a list of the groups using Get-MgGroup -All
Use Get-MgGroupMembers to pull back a list of Directory Objects.
This is where I get stuck. From what I've read it looks like a Directory Object by default only returns the ID and the Deleted Date. I'd like to get a display Name for these objects; I can obviously do this by running the appropriate 'Get' cmdlet for the type of directory object (i.e. Get-MgUser); From what I can tell the type of directory object can't be gleaned via PowerShell with out 'trial-and-error'... This seems highly inefficient to simply get a displayName.
Is there a more effective way to determine either the displayName of a Directory Object via a PowerShell cmdlet or at the very least a type so I can write a case statement to run the right cmdlet on the first try?
For the record this is going to be incorporated in to a Powershell Script, the current iteration of which looks like this and sorta works okay... assuming the Id passed in $member.Id belongs to a User type directory object.
Connect-MgGraph
$groups=Get-mgGroup -All
ForEach ($group in $groups){
$members = #{}
$members = Get-MgGroupMember -GroupId $group.Id -All
ForEach ($member in $members){
$user = Get-MgUser $member.Id
Write-Output $object.ODataType
Write-output $group.DisplayName "," $member.Id "," $user.UserType"," $user.DisplayName "," $user.UserPrincipalName "," $user.Mail >> C:scripts\Azure_Groups.txt
}
}
Would appreciate any direction/assistance on this. Thanks in advance!
Not sure why its not returning all the details on the PowerShell query:
This is working fine in MS Graph Explorer with the results showing all the details of the members:
For more details:https://learn.microsoft.com/en-us/graph/api/group-list-members?view=graph-rest-1.0&tabs=http#example-1-get-the-direct-membership-in-a-group

disable enumeration other user accounts in active directory

Huhu,
is it possible to disable the search for other Users in an AD? In this picture i am logged in as "normal" User.
Get-ADuser search
Here is a Picture of our AD structure.
AD Structure
So i don't want that a User can find another User in the Users OU by powershell (get-aduser)
is that possible?
I hope you have enough informations to understand my issue.
Regards
This is not really a thing in Windows proper. The default in AD is all users read. Secondly, anyone in AD is likely to have an email alias and thus search where they use PowerShell or not by their email alias/SMTP address, and should be for email lookups, so, IMHO, this is a futile use case.
One does not need Get-ADUser to find a user in AD. One has been able to do this since AD has been around and well before PowerShell was ever a thing using older scripting methods with .bat/.cmd/.vbs/WMI/ADSI or .Net directly and that is how it was done before PowerShell was ever a thing.
If you don't what a user using a specific cmdlet/cmdlets, then you need to implement restrictions via 'PowerShell just enough administration (JEA)'
Again, One does not need to use PowerShell to scan and get info from AD, a well documented and used thing, for folks who have PowerShell disabled (or tried to) in their environments.
Example:
How Can I Get a List of All the Users in an OU and Its Sub-OUs?
VBScript:
On Error Resume Next
Const ADS_SCOPE_SUBTREE = 2
Set objConnection = CreateObject(“ADODB.Connection”)
Set objCommand = CreateObject(“ADODB.Command”)
objConnection.Provider = “ADsDSOObject”
objConnection.Open “Active Directory Provider”
Set objCommand.ActiveConnection = objConnection
objCommand.Properties(“Page Size”) = 1000
objCommand.Properties(“Searchscope”) = ADS_SCOPE_SUBTREE
objCommand.CommandText = _
“SELECT Name FROM ‘LDAP://ou=finance,dc=fabrikam,dc=com’ WHERE objectCategory=’user'”
Set objRecordSet = objCommand.Execute
objRecordSet.MoveFirst
Do Until objRecordSet.EOF
Wscript.Echo objRecordSet.Fields(“Name”).Value
objRecordSet.MoveNext
Loop
Or
ADDS PowerShell (CMDLET, ADSI & .Net) to Expedite Your Tasks
ADSI:
<#
PowerShell ADSI(Active Directory Services Interface) commands
1. How to find the users property.
#>
$users1 = [ADSI]"LDAP://cn=copy,cn=users,dc=contoso,dc=com"
$users1 | select *
# 2. How to find the Group members for a Group.
$test = [ADSI]"LDAP://CN=test,CN=Users,DC=contoso,DC=com"
$test.Member |
ForEach-Object {[ADSI]"LDAP://$_"} |
select samccountname, samaccounttype
# 3. Listing an OU Contents
$ou=[ADSI]"LDAP://ou=tech,dc=contoso,dc=com"
$ou.PSBase.Children
$ou.PSBase.Children | Format-Table sAMAccountName
So this worked for me:
I just got it working by unchecking the "List Contents" from the "authenticated users" of the "Users" OU and I did not recognized any side effects so far.
Rights of Authenticated Users
And the "normal" User can't see the other users anymore by a query.
Tested with powershell: AD-GetUser and CMD "net user"
Query Result
So my problem is solved if there won't be any side effects in the future.
I will let you know.
Cheers

O365 Powershell | Breaking up a long list into two sets of 100

I am looking to create a rule in Office 365 applied to all of the members in our org.
I would like this rule to append a warning on all incoming email from outside the organization with the same Display Names as our users.
When I attempt to apply it to all of the users in our org I get an error stating that the rule is too long.
In order to solve that I pulled a group, but I am still about 1000 characters over the limit.
I would like to make two variables, that each hold one half of the list, created by this command:
(Get-DistibutionGroupMember -Identity email#contoso.com -ResultSize Unlimited).DisplayName
I have attempted to modify the ResultSize parameter, but what I would need is result 1-100 and then 100-200 from the same list.
Another caveat to this problem is that the list cannot be static. It is something that the script will have to update every time it is run.
There is a sub-string command that you can use on a particular username that I have utilized when I made something for AD, but I am not aware of any way to break up a list like this.
If anyone has any other ways to solve this issue I would be more than open to any suggestion.
Thanks for taking the time to read this!
There are many ways of doing it. I found it very readable.
My favorite one is this one:
$ObjectList = 1..1000
$Step = 100
$counter = [pscustomobject] #{ Value = 0 }
$ObjectListSplitted = $ObjectList | Group-Object -Property { math]::Floor($counter.Value++ / $step) }
Then if you want to show the third subset just use this format :
$ObjectListSplitted[3].Group
Have a look to this solution already explained.
As a note other languages are capable of slicing an array of object with a start, stop and a step, have a look here if you're curious.

How to tell if a Windows group has a well known SID and what that SID is

I'm trying to get the Well Known SID (if it exists) from a group name.
So far I have:
$group = 'Administrators'
$account = New-Object System.Security.Principal.NTAccount($group)
$sid = $account.Translate([System.Security.Principal.SecurityIdentifier])
This gives me the Sid object for the group which has a method 'IsWellKnown', so far so good. If I feed it a list of well known sids I've copied from the web, this works.
Web link here:
https://msdn.microsoft.com/en-us/library/system.security.principal.wellknownsidtype(v=vs.110).aspx
$wks = 'list from the web'
foreach ($s in $wks){ $sid.IsWellKnown($s)}
I don't want to have the list of well known sids copied from a web page, I'd like to find them out programmatically. I can sort of do it by making the IsWellKnown method error out with nonsense:
$sid.IswellKnown('*')
Will give me an error message with the list I need inside. Obviously I don't want to get the list from an error message I want to get it properly, does anyone know how?
Thanks in advance.
Try this:
[Enum]::GetValues([System.Security.Principal.WellKnownSidType])

POWERSHELL - The member's SID could not be resolved

Hello im working with Active Directory Group and Users and i wanna check and set proper Users/Groups from AD to machines. Problem is when i iterate over Local Users/Groups on some machine and there is old Users/Group that no longer exists in AD POWERSHELL will stop working and will throw exception.
An error (1332) occurred while enumerating the group membership. The member's SID could not be resolved.
I know what causes this problem but i dont know how to work around it. The main issue here is that its not even possible to iterate over whole array of users if one is no longer valid. Only solution to this is manualy delete those invalid users.
I even saw some reports to Microsoft that this behaviour is wrong and should be fixed but nothing was done about it.
Anyone here encountered this issue?
Thank you for your help.
$ctype = [System.DirectoryServices.AccountManagement.ContextType]::Machine
$computer = "PC name"
$groupName = "Administrators"
$context = New-Object -TypeName System.DirectoryServices.AccountManagement.PrincipalContext -ArgumentList $ctype, $computer
$idtype = [System.DirectoryServices.AccountManagement.IdentityType]::SamAccountName
$groupData = [System.DirectoryServices.AccountManagement.GroupPrincipal]::FindByIdentity($context, $idtype, $groupName)
$groupData.Members | select #{N='Server'; E={$computer}}, #{N='Domain'; E={$_.Context.Name}},#{N='Group'; E={$groupName}} , #{N='Account Name/Group'; E={$_.SamAccountName}}
Here is example of code that im using for iterating over Local users/groups on some PC.
Can You post the code that you are using, and the full error. Im guessing there is a workaround, but without seeing your code I can't see what could be wrong. If a terminating error is thrown it will stop the script or function from running further (with some gotchas, and exceptions), there are many ways of working around this
Also could you post the full error.
You will probably need to set the $erroractionpreference to silentlycontinue. And then review the $error variable to check the errors, but again I am only speculating.