• Bewerte uns auf OMR Reviews: Klick

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagatracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

V14 Powershell Fehler

EK1903

Well-known member
Hallo zusammen,

ein weiteres, evtl. Problem, was mir nach dem V14 Update aufgefallen ist.

Wir setzen PRTG ein, um gewisse Sachen innerhalb von NSP zu überwachen. In dem Zuge ist mir ein Fehler aufgefallen:

ich kann keine NSP Funktionen per Powershell mehr ausführen (weder lokal, noch remote).

Wenn ich Lokal (Intranet+GW Rolle) foldnden Befehl ausführe:

"get-nspreceiveconnector (oder andere NSP Befehle)"

erhalte ich immer den Fehler .->
Code:
Get-NspRule : The certificate validation with HOSTNAME.DOMAIN.local failed.
- The host name did not match any name in the certificate (nsp.DOMAIN.com).
In Zeile:1 Zeichen:1
+ Get-NspRule
+ ~~~~~~~~~~~
    + CategoryInfo          : Authentifizierungsfehler: (Hostname.DOMAIN.local:String) [Get-NspRule], AuthenticationException
    + FullyQualifiedErrorId : TlsCertificateError,Netatwork.NoSpamproxy.PowerShell.Commands.GetNspRule


bei der nächsten Ausführung des gleichen Befehls:
Code:
Get-NspRule : Fehler beim Senden der Anforderung.
In Zeile:1 Zeichen:1
+ Get-NspRule
+ ~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-NspRule], HttpRequestException
    + FullyQualifiedErrorId : System.Net.Http.HttpRequestException,Netatwork.NoSpamproxy.PowerShell.Commands.GetNspRule


Somit funktionieren die PS Befehle nicht mehr. Benutzer etc. haeb ich nicht geändert..
 
ffischer schrieb:
Hallo,
wegen der Fehlermeldung,
wurde was mit den Zertifikaten gemacht ?
Namensauflösung?

Zertifikate wurden nicht sep. angepasst / geändert.
Namensauflösung ist i.O.

Mailflow etc. funktioniert alles ohne Probleme.
 
Moin,
mich irritiert hier die Meldung: The host name did not match any name in the certificate (nsp.DOMAIN.com)
 
ffischer schrieb:
Moin,
mich irritiert hier die Meldung: The host name did not match any name in the certificate (nsp.DOMAIN.com)

exakt.

der Server heißt angeommen -> SERVER01
Die Intranetrolle im IIS hat das Zertifikat nsp.DOMAIN.com (ist KEIN SAN Zertifikat, somit steht Server01 nicht drin). Ich denke, das ist damit gemeint.


Aber merkwürdig, dass ich keine PS Befehle absetzen kann. Weder remote, noch lokal.... (Neustart der Rollen etc. bereits getan)
 
Weiß nicht ob das vielleicht was bringt,
Interne Probleme hatte ich mal nach einem Update.

War dann bei Konfiguration, NoSpamProxy Komponenten, NoSpamProxy WebApp und wählte hier ein anderes Zertifikat ,speicherte ab und danach (klar ist ja das falsche) dann nochmal das ganze mit dem richtigen Zertifikat.

Gibt es denn Meldungen in der Ereignissanzeige ?
 
ffischer schrieb:
Weiß nicht ob das vielleicht was bringt,
Interne Probleme hatte ich mal nach einem Update.

War dann bei Konfiguration, NoSpamProxy Komponenten, NoSpamProxy WebApp und wählte hier ein anderes Zertifikat ,speicherte ab und danach (klar ist ja das falsche) dann nochmal das ganze mit dem richtigen Zertifikat.

Gibt es denn Meldungen in der Ereignissanzeige ?

Dieser Versuch hat nichts gebracht (hierfür nutze ich ein von LetsEncrypt ausgestelltes Zertifikat, NICHT das Standardzertifikat von NSP selber).

Ereignisanzeige steht.<
Code:
Category: IdentityService.Controllers.AccountController
EventId: 1001
SpanId: 4785fa4d0ec9d182
TraceId: 3f5551de24632df1c807db5458a780cf
ParentId: 0000000000000000
RequestId: 80000087-0001-9100-b63f-84710c7967bb
RequestPath: /api/identity-service/account/login
ActionId: 3f6fced8-4140-4c78-b320-2050b342110b
ActionName: IdentityService.Controllers.AccountController.Login (NoSpamProxy.IdentityService)
Starting login for {"TenantAccessDeniedBehavior":0,"TenantId":null,"PrimaryDomain":"_global"}

Returning HTTP 403

Exception: 
IdentityService.Data.Store.ForbiddenException: Roles not configured.
   at IdentityService.Data.Store.UserStore.MapClaims(IEnumerable`1 identitySids, LoginModel model)
   at IdentityService.Data.Store.UserStore.GetClaimsAsync(WindowsPrincipal principal, LoginModel model)
   at IdentityService.Controllers.AccountController.Login(LoginModel model)
Dieser Fehler kommt täglich sehe ich gerade (die beiden JSON Files hatte ich bereits gelöscht, was in einem anderen Post erwähnt wurde).

- Diese Probleme existieren seit dem neuesten Update auf V14. (hab die V14.04.4)
 
ein Returning HTTP 403
Forbidden?

Bin jetzt mal gespannt, NSP liest ja mit ob die vielleicht noch eine Idee hierzu haben.
 
Hallo,
ist das Benutzerkonto, welches den Sensor bzw. das PowerShell Skript ausführt, auf dem Server in den Gruppen "NoSpamProxy Configuration Administrators" und "NoSpamProxy Monitoring Administrators?


Gruß,
Daniel
 
Hallo zusammen =)

mit dem Update auf v14 ist in der PowerShell die Authentifizierung ebenfalls geändert worden.
Das genutzte WebAPI Zertifikat passt nicht zum Hostnamen, was nichts besonderes ist.
Ich habe in unseren Skripten folgende Validierung eingebaut um das Problem zu umgehen:

$nspVersion = (Get-ItemProperty -Path HKLM:\SOFTWARE\NoSpamProxy\Components -ErrorAction SilentlyContinue).'Intranet Role'

if ($nspVersion -gt '14.0') {

try {

Connect-Nsp -IgnoreServerCertificateErrors -ErrorAction Stop

} catch {

$e = $_

Write-Warning "Not possible to connect with the NoSpamProxy. Please check the error message below."

$e |Format-List * -Force

EXIT

}

if ($(Get-NspIsProviderModeEnabled) -eq $true) {

if ($null -eq $TenantPrimaryDomain -OR $TenantPrimaryDomain -eq "") {

Write-Host "Please provide a TenantPrimaryDomain to run this script with NoSpamProxy v14 in provider mode."

EXIT

} else {

# NSP v14 has a new authentication mechanism, Connect-Nsp is required to authenticate properly

# -IgnoreServerCertificateErrors allows the usage of self-signed certificates

Connect-Nsp -IgnoreServerCertificateErrors -PrimaryDomain $TenantPrimaryDomain

}

}

}
Das eigentlich wichtigste ist:
Connect-Nsp -IgnoreServerCertificateErrors -PrimaryDomain $TenantPrimaryDomain
Damit sollte dein Skript also wieder laufen ;)
Connect-Nsp -IgnoreServerCertificateErrors -PrimaryDomain $TenantPrimaryDomain


Gruß
Jan
 
869288141 schrieb:
Hallo,
ist das Benutzerkonto, welches den Sensor bzw. das PowerShell Skript ausführt, auf dem Server in den Gruppen "NoSpamProxy Configuration Administrators" und "NoSpamProxy Monitoring Administrators?


Gruß,
Daniel

Hi,
das spielt keine Rolle.

LOKAL (mal Monitoring und Sensoren etc. ausgenommen) funktioniert es mit dem NSP Admin auch nicht (ja, er ist Mitglied der obigen Gruppe)
 
Guten Morgen =)

Das lässt sich relativ leicht genau so lösen.
Füg einfach folgende Zeile an den Anfang des try-catch Blocks der Abfragen einfügen (Zeile 30 in der aktuellen Version):
Invoke-Command -Session $NSPPSSession -ScriptBlock { Connect-Nsp -IgnoreServerCertificateErrors -ErrorAction Stop }

Damit wird inital der Login gemacht, im Fehlerfall wird das catch getriggert =)

Ich werde dem Frank auch einmal bescheid geben ;)


Gruß
Jan
 
Zurück
Oben