Powershell Sessions & Exchange 2010

[YellowOnline]

Bij mijn vorige werkgever had ik niets met Exchange te doen en bij mijn huidige is alles nog Exchange 2003. Maar kijk: nu hebben we een klant met Exchange 2010 en ik kan eindelijk mijn Powershell skills erop loslaten.

Er gaat echter iets mis. In tegenstelling tot bij andere producten wordt er geen module of snapin geladen. Een sessie wordt geimporteerd van de server.

PowerShell:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://EXCHANGE.TWEAKERS.COM/PowerShell/ -Authentication Kerberos
Import-PSSession $Session -AllowClobber

(die AllowClobber moet ik nog uitzoeken, die sessies zijn iets nieuws voor mij)

Als ik direct op de server Get-Mailbox doe, dan krijg ik 100 mailboxen. Als ik dat echter van mijn PC uit doe, dan krijg ik slechts één hit. Niet toevallig waarschijnlijk is de ene hit de mailbox die ik opgevraagd heb bij mijn allereerste Get-Mailbox op de server.

Enfin, wie brengt mij verlichting, zodat mijn fantastische script niet direct op de server uitgevoerd moet worden (want voor de rest is alles in orde).

[ralpje]

Voer je die remoting uit met dezelfde credentials als dat je lokaal op de server inlogt? In principe doe je die remoting ook als je op die lokale machine werkt, maar dan naar zichzelf . Technisch gezien zou er dus geen verschil moeten zijn. Geef je ook een -resultsize unlimited mee aan je get-mailbox?

[YellowOnline]

ralpje schreef op maandag 25 januari 2016 @ 09:58:
Voer je die remoting uit met dezelfde credentials als dat je lokaal op de server inlogt? In principe doe je die remoting ook als je op die lokale machine werkt, maar dan naar zichzelf . Technisch gezien zou er dus geen verschil moeten zijn. Geef je ook een -resultsize unlimited mee aan je get-mailbox?

Eigenlijk was het niet dezelfde gebruiker. Het is een domein waar ik voor de verandering eens geen enterpise admin ben en iemand anders was voor mij ingelogd. Ik heb dan Exchange Admin rechten gekregen op mijn eigen naam en ben dan met remoting begonnen.

Mijn code gebruikt trouwens niet Unlimited, maar zelfs dat heb ik al eens geprobeerd

PowerShell:

$arrMailbox = @(Get-Mailbox -ResultSize 1000 | Sort-Object Name)

Ik krijg slechts één zielig mailboxje terug. Hetzelfde uitgevoerd op de server geeft ze allemaal weer.



Maar er zijn nog bizarre dingen door die remoting hoor. Rechts zouden de gebruikers moeten staan die toegang hebben tot de mailbox links - dat gebeurt ook niet. Als ik GrantSendOnbehalfTo opvraag krijg ik niets terug op mijn computer, terwijl - opnieuw - ik de juiste waarden terug krijg als ik dezelfde code op de server uitvoer.

[ralpje]

Heb je de mogelijkheid om eens met dezelfde rechten te testen? Het klinkt alsof je alleen mailboxen terugkrijgt waar je daadwerkelijk rechten op hebt ofzo. Wellicht dat een hoop mailboxen geen inheritance op de rechten hebben waardoor je die niet mag zien onder dat account.

[YellowOnline]

ralpje schreef op maandag 25 januari 2016 @ 10:33:
Heb je de mogelijkheid om eens met dezelfde rechten te testen? Het klinkt alsof je alleen mailboxen terugkrijgt waar je daadwerkelijk rechten op hebt ofzo. Wellicht dat een hoop mailboxen geen inheritance op de rechten hebben waardoor je die niet mag zien onder dat account.

Dat is een interessante denkpiste, maar dan zouden er 3 mailboxen moeten opduiken (Support, Monitoring, Einkauf) waarop ik identiek dezelfde rechten heb. En ik ben bovendien lid van de groep Exchange Admins!

[Meekoh]

Ik ben ook wel benieuwd naar wat er in die session configuration staat. Session configurations kunnen nogal flinke beperkingen opleggen. Heb je die zelf gemaakt? Gebruik je diezelfde session config ook vanaf de exchange server?

[Jazzy]

Ik denk dat het inderdaad RBAC is waar je tegenaan loopt. Het account waarmee je de remote PowerShell sessie opzet moet wel de juiste RBAC rol hebben, anders mag je alleen je eigen object beheren.

De groep Exchange Admins is trouwens geen Exchange 2010 groep, dat is waarschijnlijk een overblijfsel van Exchange 2003 of ouder. Maar lees je even in op Exchange 2010 en RBAC, dan kom je er wel uit.

Nog even voor de duidelijkheid trouwens, zowel 'op de server' als op een remote computer wordt op exact dezelfde manier een remote PowerShell sessie opgezet. Het enige verschil zit hem dus in de credentials.

[ Voor 54% gewijzigd door Jazzy op 25-01-2016 10:48 ]

[Killah_Priest]

Zeker weten een rechten issue.
Ik remote dagelijks naar meerdere Exchange 2010 en 2013 servers en dit probleem treedt bij mij alleen op als ik bv met mijn user account probeer te connecten (zonder admin rechten uiteraard).

De manier van connecten (sessie maken & importeren) is overigens wel de correcte wijze, ook voor het uitvoeren van PS scripts.

[wagenveld]

Je kunt beter dit doen, dan heb je zeker de juiste creds

code:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<FQDN of Exchange 2010 server>/PowerShell/ -Authentication Kerberos -Credential $UserCredential
Import-PSSession $Session

https://technet.microsoft...932%28v=exchg.141%29.aspx

[Jazzy]

Met vervolgens dan weer de uitdaging hoe je die credentials gaat opslaan in je script.

[Killah_Priest]

Ik gebruik altijd deze (ook om een connectie met een DC op te zetten) aan het begin van een werkdag :

PowerShell:

if (!$Cred)
    {$Cred = Get-Credential -Message "Please enter creds" -UserName '[e-mail]'}

$DC = New-PSSession -ComputerName FQDNvanDC -Credential $Cred
    Invoke-Command -Session $DC -ScriptBlock {Import-Module ActiveDirectory}
$Ex = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri 'http://FQDNvanExchange/Powershell' -Credential $Cred -Authentication Kerberos

Import-PSSession $DC
Import-PSSession $Ex

Een connectie maken van buiten een domein zonder UPN lukt mij niet altijd met een non-domain joined machine icm Kerberos (daarom gebruik ik de UPN ipv SamAccountName).

[ Voor 12% gewijzigd door Killah_Priest op 25-01-2016 12:27 ]

[Jazzy]

Hier vergelijkbaar in mijn Verbind-met-AzureAD-en-Exchange-Online-script, maar dan met de -Credential parameter. Zie nu dat je sinds PSv3 ook -Message en -UserName kunt gebruiken.

Aan de andere kant, als je PSv3 of nieuwer hebt is het niet meer nodig om de ActiveDirectory module handmatig te laten. Toch?

[ralpje]

Jazzy schreef op maandag 25 januari 2016 @ 12:25:
Met vervolgens dan weer de uitdaging hoe je die credentials gaat opslaan in je script.

Eénmalig je credentials opgeven en als securestring in een txt-file opslaan. Die kun je vervolgens weer als credential laden in je script.

Ik doe dat in mijn connect-naar-o365-script met verschillende omgevingen, ik kan als parameter de klantnaam meegeven, op basis daarvan worden de juiste credentials geladen. Als de credentials nog niet bestaan worden ze gevraagd en weggeschreven voor de volgende keer.

[Jazzy]

En hier dan methode om die secure string weer te converteren naar een plain-text password: http://stackoverflow.com/...ring-to-readable-password

[Meekoh]

Jazzy schreef op maandag 25 januari 2016 @ 13:05:
En hier dan methode om die secure string weer te converteren naar een plain-text password: http://stackoverflow.com/...ring-to-readable-password

Werkt volgens mij alleen wanneer je dat vanaf dezelfde machine probeert als waar de securestring is gemaakt.
Wil je het vanaf een andere server/computer kunnen ontfutselen zul je de securestring moeten voorzien van een key (AES bijv.). Maargoed moet je die key weer geheim houden

[.je]

Meekoh schreef op maandag 25 januari 2016 @ 13:12:
[...]

Werkt volgens mij alleen wanneer je dat vanaf dezelfde machine probeert als waar de securestring is gemaakt.
Wil je het vanaf een andere server/computer kunnen ontfutselen zul je de securestring moeten voorzien van een key (AES bijv.). Maargoed moet je die key weer geheim houden

Enkel waar je de get-credential in een variabel hebt geduwt. Soms kom ik die als "global" in scripts tegen.

Jazzy schreef op maandag 25 januari 2016 @ 13:05:
En hier dan methode om die secure string weer te converteren naar een plain-text password: http://stackoverflow.com/...ring-to-readable-password

Wat een omweg...

Get-Credential heeft een "method" genaamd "GetNetworkCredential". Als je daar de property "password" van pakt, heb je 'm in plaintext. Hoef je niets meer terug te rekenen

[ Voor 33% gewijzigd door .je op 25-01-2016 13:26 ]

[Razwer]

pwds in scripts is iets wat ik allertijde vermijd. Of handmatig in kloppen, of in de juiste user space script afvuren.
Er is bijna altijd een manier omheen te vinden met wat creativiteit.

[Jazzy]

En hoe vuur je het in de juiste user space af?

[YellowOnline]

Terug on-topic


Omdat hier de overtuiging heerst dat het een probleem is met credentials wou ik mij met Exchange verbinden zonder PoSh te gebruiken. In de console (ook lokaal op mijn PC) zijn alle mailboxen zichtbaar, wat in ieder geval al uitsluit dat mijn gebruiker onvoldoende rechten heeft. Het maakt trouwens geen verschil of ik expliciet of impliciet authenticate.

Vergelijk:

[ Voor 15% gewijzigd door YellowOnline op 25-01-2016 15:00 ]

[Jazzy]

Gebruik nu eens de Exchange Management Shell snelkoppeling in plaats van je eigen scriptje.

[YellowOnline]

Jazzy schreef op maandag 25 januari 2016 @ 15:12:
Gebruik nu eens de Exchange Management Shell snelkoppeling in plaats van je eigen scriptje.

Idem. Zou ook geen verschil mogen zijn - ik gebruik nooit dedicated consoles (ESX, NetApp, SQL, AD, SCOM, SCDPM, SCCM, ...).



EDIT
Ho, wacht. Ik heb in de console geen rechten om iets te veranderen. Dat betekent dat er toch iets niet klopt met de rechten.

[ Voor 33% gewijzigd door YellowOnline op 25-01-2016 15:35 ]

[Razwer]

Jazzy schreef op maandag 25 januari 2016 @ 14:09:
En hoe vuur je het in de juiste user space af?

In geval van automation: Scheduled task bijvoorbeeld. Deze zijn on demand/remote af te trappen. Wie de tasks mag af trappen is weer via standaard windows permissons te regelen.

https://technet.microsoft...ry/cc785125(v=ws.10).aspx

In geval van human: $cred = Get-credential

[ Voor 18% gewijzigd door Razwer op 25-01-2016 16:18 ]

[Jazzy]

Ik wilde dat ik met je mee kon kijken want het kan niet anders dan dat er gewerkt wordt met verschillende RBAC rollen. In de EMC wordt namelijk precies hetzelfde gedaan op de achtergrond, namelijk een remote PowerShell sessie naar een Exchange-server. In beide gevallen, zowel EMS als EMC, zie je op een bepaald moment de cmdlets in je sessie geïmporteerd worden. Het is dus afhankelijk van je RBAC rol welke cmdlets je krijgt en wat de scope is waarop die van toepassing is.

Test dat maar eens, cmdlets als Get-ExchangeServer en dergelijke bestaan waarschijnlijk ook niet in deze PowerShell sessie.

[Killah_Priest]

.je schreef op maandag 25 januari 2016 @ 13:20:
[...]

Enkel waar je de get-credential in een variabel hebt geduwt. Soms kom ik die als "global" in scripts tegen.


[...]

Wat een omweg...

Get-Credential heeft een "method" genaamd "GetNetworkCredential". Als je daar de property "password" van pakt, heb je 'm in plaintext. Hoef je niets meer terug te rekenen

PtrToString is dus wel DE manier om een securestring naar een reguliere string te converten (dit is hoogstwaarschijnlijk ook de onderliggende method die uitgevoerd wordt bij de GetNetworkCredentials() methode).

Passwords in je scripts hardcoden is niet eens moeilijk (of echt gevaarlijk) als je je password dmv een certificaat encrypt.
In het verleden regelmatig gedaan, password bytes uitlezen, encrypten met de public key van mijn user certificaat welke in AD is opgenomen en dit dan in mijn scripts embedden. Werkte overigens wel zeer omslachtig (lees : omslachtiger als iedere keer mijn password met de hand invoeren ; scheduled scripts draai ik onder accounts welke daar de rechten toe hebben).

On topic :
dmv Get-RoleGroup en Get-RoleGroupMember kun je in ieder geval achterhalen welke rechten je zou moeten hebben op de Exchange omgeving.

[YellowOnline]

Jazzy schreef op maandag 25 januari 2016 @ 15:45:
[...]
Test dat maar eens, cmdlets als Get-ExchangeServer en dergelijke bestaan waarschijnlijk ook niet in deze PowerShell sessie.

Je hebt gelijk: die bestaan inderdaad niet in deze sessies. Bij Get-Mailbox ontbreken ook een aantal mogelijke parameters zoals -Server.

[Jazzy]

Dan zou ik even terug naar de beheerders gaan en vragen of ze de juiste RBAC rol op jouw account willen toepassen. Welke rol dat is dat weet je inmiddels al omdat je je hebt ingelezen in RBAC.

[YellowOnline]

Voor de volledigheid: het werkt nu.



Ik zat inderdaad in een verkeerde groep, een overblijfsel van 2003. Maar daarnaast moet ik ook expliciet credentials meegeven. Als de huidige credentials gebruikt worden dan blijft het probleem hetzelfde. Dat is spijtig, want aangezien de gebruiker het script sowieso al met elevated credentials uitvoert is het onnodig en zelfs storend om die nogmaals in te geven.