search

mbegan / Okta-PSModule

Okta API Powershell Wrapper Module
Other
102 stars 31 forks source link

Module no longer works unless used in conjunction with the okta.core.automation module #27

Closed CJChristensen closed 5 years ago

CJChristensen commented 5 years ago

Unable to utilize this module anymore without utilizing the official okta powershell module and running connect-okta first.

Nothing has changed from our config side. It just stopped working last week. My Okta_Org.ps1 is set up correctly. I even use the token and URL info out of that to run the connect-okta commandlet. Please let me know what other information is needed.

Here is what it looks like when running any of the commands. As you can see I have to run connect-okta first in order for your module to function.

image

mbegan commented 5 years ago

I'm stumped.

Can you run the following (without running Connect-Okta) and share the output?

PS > $Error.Clear()
PS > $oktaVerbose=$true  
PS > oktaGetUserbyID -userName me -Verbose                                                                                                                                            
PS > $Error[0..($Error.count)]
CJChristensen commented 5 years ago

Here's what I get.

PS U:> $Error.Clear() PS U:> $oktaverbose=$true PS U:> oktaGetUserbyID -userName user@domain.com -Verbose VERBOSE: Just Made this UserAgent: Okta-PSModule/2.4 (5.1.17134.228) (UnknownPlatform) (UnknownOS) VERBOSE: GET https://oktadomain.okta.com/api/v1/users/user@domain.com with 0-byte payload WARNING: Unable to find type [Microsoft.PowerShell.Commands.HttpResponseException]. WARNING: Encountered error, returning limited or empty set VERBOSE: This Page returned: 0, we've seen: 0 results so far VERBOSE: 0 results returned, i predict an empty page coming up, lets skip it VERBOSE: We see no or an invalid next link of: False PS U:> $Error[0..($Error.count)] Unable to find type [Microsoft.PowerShell.Commands.HttpResponseException]. At C:\Users\Username\Documents\WindowsPowerShell\Modules\okta\Okta.psm1:478 char:38

Invoke-WebRequest : The request was aborted: Could not create SSL/TLS secure channel. At C:\Users\Username\Documents\WindowsPowerShell\Modules\okta\Okta.psm1:461 char:25

mbegan commented 5 years ago

Invoke-WebRequest : The request was aborted: Could not create SSL/TLS secure channel.

Looks like a TLS issue.

Take a look at this note about tls. If you run that command to force tls1.2 prior to making connections do things work?

The reason that it works after using the SDK is because it is explicitly connecting with TLS 1.2 and then the commands from this module are reusing that connection or inheriting the requirement to use tls1.2 from something it does.

aellch commented 5 years ago

Just a heads up, here is some more background. I was actually just coming to report this as well. Trying your test now :)

https://devforum.okta.com/t/could-not-create-ssl-tls-secure-channel-idx10803/1458/12

aellch commented 5 years ago

I just wanted to add my results in the hope it helps:

'PS C:\WINDOWS\system32> $Error.Clear() $oktaVerbose=$true
oktaGetUserbyID -userName me -Verbose
$Error[0..($Error.count)] VERBOSE: GET https://yes.okta.com/api/v1/users/me with 0-byte payload WARNING: Unable to find type [Microsoft.PowerShell.Commands.HttpResponseException]. WARNING: Encountered error, returning limited or empty set VERBOSE: This Page returned: 0, we've seen: 0 results so far VERBOSE: 0 results returned, i predict an empty page coming up, lets skip it VERBOSE: We see no or an invalid next link of: False Unable to find type [Microsoft.PowerShell.Commands.HttpResponseException]. At C:\Users\adam\Documents\WindowsPowerShell\Modules\okta\Okta.psm1:477 char:38

Invoke-WebRequest : The remote server returned an error: (401) Unauthorized. At C:\Users\adam\Documents\WindowsPowerShell\Modules\okta\Okta.psm1:460 char:25

After doing that, I went ahead and tried the following:

'PS C:\WINDOWS\system32> import-module okta

try {

} catch { Write-Warning $_.Exception.Message }

oktaGetActiveApps VERBOSE: GET https://yes.okta.com/api/v1/apps?limit=500&filter=status eq "ACTIVE" with 0-byte payload WARNING: Unable to find type [Microsoft.PowerShell.Commands.HttpResponseException]. WARNING: Encountered error, returning limited or empty set'

Obviously that example should be sufficient, but just for reference I have tried the following in addition to the try/catch you recommended:

'PS C:\WINDOWS\system32> [Net.ServicePointManager]::SecurityProtocol = "Tls12, Tls11, Tls, Ssl3"

PS C:\WINDOWS\system32> oktaGetActiveApps VERBOSE: GET https://yes.okta.com/api/v1/apps?limit=500&filter=status eq "ACTIVE" with 0-byte payload WARNING: Unable to find type [Microsoft.PowerShell.Commands.HttpResponseException]. WARNING: Encountered error, returning limited or empty set'

In addition I tried adding the try/catch to the org file, none of which had differing results. I have tried this on 3 devices and confirmed the API key is valid as well

aellch commented 5 years ago

Just to add some additional information, unfortunately when I connect with the okta.core.automation connect-okta cmdlet, I am still unable to utilize your wrapper:

mbegan commented 5 years ago

Can you run that same loop to spit out the errors encountered?

In one of the results above I see a 401 error which would indicate that you aren't experiencing a TLS issue anymore.

weigh2tall commented 5 years ago

I wanted to add that adding the try/catch to force TLS 1.2 to my okta_org.ps1 script did work for us.
I know that Okta upgraded our tenant to TLS1.2 about 2 weeks ago because it broke a different application. Edit: fixed spelling And a thank you for maintaining the script!

aellch commented 5 years ago

Sorry for the late reply mbegan, it's been one of those nightmare weeks. I had to delete the original screenshot as I left in unobfucated info. Heres a rundown though, and it does look like it is no longer TLS related... but the problem surfaced at the same time so I'm a little confused as to what's going on. Everything worked fine before the TLS change.

I added the try/catch to okta_org.ps1, which doesn't throw any exceptions: image -- by all appearances it seems to resolve the TLS problem.

So after doing that, I made sure I could connect with the official okta-connect cmdlet, as a means to verify the token is correct in my okta_org file. After connecting that way, I did a cut and paste and confirmed there was not a mismatch in the okta_org file vs the connect-okta cmdlet. Here is a demonstration of the okta.coreautomation working with the same token obfuscated above: image

Immediately after running that succesfully, I attempted (unsuccesfully) to run a command from your module, shown here: image

After doing that, I attempted to re-load powershell, doublchecked the tokens again (which definitely match the one that works with connect-okta), and ran the followng:

image

So it does appear to be returning an 'unauthorized' 401 error -- but it is definitely utilizing the same token which works with okta.core.automation.

Any and all advice is appreciated -- your module has made life so much easier, and I dread the idea of trying to re-work our scripts for the more limited core.automation release.

Here is a cut and paste output of the final 401 error above in case you prefer something cut and pasteable:

PS C:\WINDOWS\system32> C:\Users\adam\Documents\WindowsPowerShell\Scripts\mbegan_oktatest.ps1 VERBOSE: GET https://yes.okta.com/api/v1/apps?limit=500&filter=status eq "ACTIVE" with 0-byte payload WARNING: Unable to find type [Microsoft.PowerShell.Commands.HttpResponseException]. WARNING: Encountered error, returning limited or empty set Unable to find type [Microsoft.PowerShell.Commands.HttpResponseException]. At C:\Users\adam\Documents\WindowsPowerShell\Modules\okta\Okta.psm1:477 char:38

Invoke-WebRequest : The remote server returned an error: (401) Unauthorized. At C:\Users\adam\Documents\WindowsPowerShell\Modules\okta\Okta.psm1:460 char:25

mbegan commented 5 years ago

can we run a few tests just to confirm that the right okta_org file is be loaded and there aren't any typos.

aellch commented 5 years ago

This is now resolved! Thank you so much for your assistance.

Long story short - someone put the sec token into the psm1 file rather than the org, so it needed updated there. Not 100% sure why atm, but I'm just happy to have things working again.

Thank you so much for taking the time to help with this!

mbegan commented 5 years ago

happy to help

Wq3VDUAK29DdpZZkQTSnGYFY3E commented 2 years ago

In my case I had to open Internet Explorer once and use default settings:

Invoke-WebRequest : The response content cannot be parsed because the Internet Explorer engine is not available, or Internet Explorer's first-launch configuration is not complete. Specify the UseBasicParsing parameter   
and try again.
FFFreak commented 2 years ago

For anyone in the future - it seems to be stepping over the conjoined catch options involving what looks like it would be for [Microsoft.PowerShell.Commands.HttpResponseException] even after TLS and other edits. I just changed the long catch to the catch all and remarked the catch all under it.

Then it became an error message of: WARNING: Okta Request ID: YZVt44exxxxxx@xxxxxxxxxxxx WARNING: Your request was bad! WARNING: The remote server returned an error: (400) Bad Request.

Mine is when trying to set sms factor. like nearly everything else has been fine merging the other github suggestions from others. I added in a multi-tency ability to move between domains - which means be careful as you can send code to TEST and PROD if you adopt mine.