New-WebServiceProxy failing to authenticate with NTLM

You're mixing two fundamentally different techniques here.

$proxy = New-WebServiceProxy -Uri "$site/_vti_bin/Lists.asmx" -UseDefaultCredential$proxy.PreAuthenticate = $TRUE$proxy.Credentials = $credentials

UseDefaultCredential will attempt to pass your currently logged in Windows domain user to the site. However, you're setting Credentials as well. Normally, you would use -Credential $credentials (see http://technet.microsoft.com/en-us/library/hh849841.aspx )

The curl command you're running is more akin to using -Credential: -u is equivalent.

Try using something like $proxy = New-WebServiceProxy -Uri "$site/_vti_bin/Lists.asmx" -Credential $credentials instead.

If that doesn't work, please edit your question to include the headers being returned from the Oracle SSO connection - it could be that it simply isn't even asking for credentials.

I never ended up coming up with a solution for this, but I can explain why. In our environment we use Forms Based Authentication against our Oracle Identity Foundation SSO with SAML v1.1.

When you attempt to authenticate, it redirects you to the SSO, but the client is attempting to use NTLM against the actual Web Front Ends instead of the SSO. To make this work, you need to include the X-FORMS_BASED_AUTH_ACCEPTED: f header in your request for it to actually authenticate using NTLM against the WFE (and not the SSO).

Here's the issue: You can't add headers to New-WebServiceProxy in PowerShell (up to 4.0 -- I haven't rolled out 5 yet). The only recommendation I can make for others having issues is to follow HighlyUnavailable's suggestions, or use Invoke-WebRequest and build your SOAP calls by hand.

The only issue is that Invoke-WebRequest can chew up your encoding, so here's how I've worked around it. If anybody has a suggestion for working around the encoding issue, I'm all ears.

# Set your credentials here.$UserName = 'BartSimpson'$Password = '3atmMySh0rtz!'$Domain   = 'SF'$SecurePassword = ConvertTo-SecureString -String $Password -AsPlainText -Force$Credentials = New-Object System.Management.Automation.PSCredential (($Domain + "\" + $UserName), $SecurePassword)# SOAP request headers and body$BaseHeaders = @{"X-FORMS_BASED_AUTH_ACCEPTED" = 'f';                 "SOAPAction" = "`"http://schemas.microsoft.com/sharepoint/soap/GetListCollection`"";                 "Content-Type" = "text/xml; charset=utf-8"}$SOAP = @"<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">  <soap:Body>    <GetListCollection xmlns="http://schemas.microsoft.com/sharepoint/soap/" />  </soap:Body></soap:Envelope>"@# Gives us a random temp file to pipe output to$TmpFile = [System.IO.Path]::GetTempFileName()Invoke-WebRequest -Uri $URL -Headers $BaseHeaders -Credential $Credentials -Method POST -Body $SOAP -OutFile $TmpFile# Get the outfile with UTF8 encoding[xml]$Result = Get-Content -Raw -Path $TmpFile -Encoding UTF8# Remove the temporary fileRemove-Item $TmpFile

Seems like a long way to go, which it is, but it works if you insist on using PowerShell.

I switched to python-suds and was able to do what I needed to.