How do I reference this object variable?

$ShareSec = Get-WmiObject -Class Win32_LogicalShareSecuritySetting -ComputerName "servername"
      
ForEach ($ShareS in $ShareSec)

      {      
            $SecurityDescriptor = $ShareS.GetSecurityDescriptor()
            $myCol = @()
            
            ForEach ($DACL in $SecurityDescriptor.Descriptor.DACL)
            {
                  $myObj = "" | Select Domain, ID, AccessMask, AceType
                  $myObj.Domain = $DACL.Trustee.Domain
                  $myObj.ID = $DACL.Trustee.Name
***
My questions is how to reference $DACL.Trustee.name in an get-adobject lookup, such as

$d=get-adobject -filter {name -like $dacl.trustee.name }
The things I've tried either give errors or lose the value and echo the variable name, etc..  I always have difficulty referencing variables especially in braces and quotes, etc..  The end goal is to list group members - when the DACL.trustee.name is a security group.  I was planning to check the object class for each DACL - and lookup the membership when the objectclass is group. Knowing the group name alone isn't very helpful.

Thanks for your assistance.
apsutechteamAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

footechCommented:
The only way I've ever been able to do that is to first assign the value to a variable, and then use that variable in the filter.
$name = $DACL.Trustee.Name
get-adobject -filter {name -like $name }

Open in new window

0
footechCommented:
Actually, just tested and another way is
get-adobject -filter "name -like '$DACL.Trustee.Name'"

Open in new window


Unless you're using a wildcard, you probably want to use -eq instead of -like in the filter.
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Since the value is constant for the filter, you should be able to use this too, called a subexpression:
Get-ADObject -filter { name -like "$($dacl.trustee.name)" }

Open in new window

In double quotes you always need to use a subexpression to access properties of objects.
"$dacl.trustee.name" will replace "$dacl" with its string representation, and then append ".trustee.name" as string.
0
Introducing the "443 Security Simplified" Podcast

This new podcast puts you inside the minds of leading white-hat hackers and security researchers. Hosts Marc Laliberte and Corey Nachreiner turn complex security concepts into easily understood and actionable insights on the latest cyber security headlines and trends.

footechCommented:
@Qlemo - have you been able to get that to work?  I've tried it and it doesn't work for me.  It seems like subexpressions don't work within filter brackets, which I find odd.  The second syntax that I listed is like what I use for Get-WmiObject filters, and it doesn't work if I reverse the double and single quotes.  The help for AD cmdlets doesn't mention using quotes to surround the filter, though when you look at the help topic about_ActiveDirectory_Filter, a number of the examples have the filter surrounded by single quotes.

You're right about the subexpression of course, I messed up when I was pasting the command.  Should be
get-adobject -filter "name -like '$($DACL.Trustee.Name)'"

Open in new window

And what I find odd about that is that you wouldn't expect the subexpression to work within single quotes...
0
apsutechteamAuthor Commented:
I appreciate your help, but I seem unable to get any of these variation to work.  I can echo $DACL.Trustee.Name to the screen, or another variable I have used to put this value into, such as $name.  They both display as expected.  Then, I try the various syntaxes and I don't have any success.  Any ideas, do these variation work for you?  I've also test get-adobject with an actual name in quotes, omitting variables and that works too.  Thanks for your patience.
0
footechCommented:
Yes, I've tested both of the following and they work for me.
$name = $DACL.Trustee.Name
get-adobject -filter {name -like $name}
get-adobject -filter "name -like '$($DACL.Trustee.Name)'"

Open in new window

The only variation for me was that I used samAccountName instead of name since I know that no objects have a name in that format.  So my actual command was
get-adobject -filter "samAccountName -like '$($DACL.Trustee.Name)'"

Open in new window

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
apsutechteamAuthor Commented:
Ok - that works for me too with samaccountname.  Thanks - you've been great!
0
apsutechteamAuthor Commented:
I've requested that this question be closed as follows:

Accepted answer: 0 points for apsutechteam's comment #a40312919

for the following reason:

Multiple answers - and successful execution.
0
footechCommented:
@apsutechteam - Could you reopen the question and (re)select which post(s) helped you as the answer instead of your own?  You'll need to click the "request attention" button underneath your question.  Thanks.
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Advanced stuff ahead ...

After some deep-dive investigation, using objects representing something different than simple types (string, number) does not work inside of the script block notation for -filter (using the curly brackets).
With exception of AD objects, that is. Objects listed in get-help about_ActiveDirectory_ObjectModel are supported, and can be used directly including all their properties:
$adusr = Get-AdObject -identity 'cn=Qlemo Demo, cn=Users, dc=domain, dc=com'
Get-AdObject -Filter { name -eq $adusr.name }

Open in new window


The string variant of -filter is parsed exactly like a string first, so string literals (like the evaluated object content) have to be enclosed in single or double quotes.
The whole filter string needs to be enclosed in double quotes to allow string replacement by PowerShell. If the outmost quotes are double quotes, everything inside looking like a variable or subexpression (i.e. starting with dollar sign) will be evaluated.
Other quotes (single or double) inside those double quotes are just quotes, not restricting the replacement, with exception of the backquote as escape character, of course.
This leads to something like
    "property -eq '$($obj.property.property)'"
or
    "property -eq ""$($obj.property.property)"" "
or
    "property -eq `"$($obj.property.property)`" "


I hope that illuminates the background why some expressions work seamlessly.
0
footechCommented:
@Qlemo - You're right, I should have clicked the Object button.  I guess sometimes I'm too hesitant to use it...

That's interesting that AD object properties can be evaluated inside the braces.  It's odd that I've never seen any official (or by well-know PS bloggers) mention/explanation of the string variant of -filter.  Only time I've seen it used in examples is in about_ActiveDirectory_Filter as I mentioned before, but the section on filter syntax exclusively describes the scriptblock notation.  I'm just curious if you have ever seen the string variant covered?

I think I discovered it kind of by accident. First I had learned about AD cmdlets, then later I was learning about WMI cmdlets (Get-WmiObject in particular) and the filter for that.  The help there shows the string variant, and I (not being too well-versed in PS yet) probably thought that all filters should be like that.  So for a time I was always using the string variant.  After going back into the help for AD cmdlets at some point and reading more extensively on the AD filter syntax is when I started using the scriptblock notation again for AD cmdlets (probably just to be consistent with the documentation I was seeing), but still using the string variant for WMI cmdlets.    - I know everyone was curious about this.  :)
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
No, never seen the "string theory" in anything official. I guess "it just works" because PS tries to support with a lot of effort.
My take on that: the string expression is silently converted into a script block, with the vars and subexpression already substituted. There are several other cases where this happens (but can't recall one ATM).
0
footechCommented:
Answer - http:#a40312383

Assist - http:#a40313226

...and this is why I'm hesitant to object at times.  I'd rather the asker take the initiative to select which posts were helpful on their own.  Oh well.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Powershell

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.