Jamf Nation Community

wsg · ‎02-08-2018

I'm trying to authenticate against the JSS API URL with a valid login credentials and it seems to constantly fail, e.g. ../JSSResource/accounts with error 401, not authorized. The user has full admin privileges, but continue to fail on the basic auth. I've even tried cURL to see if the behavior is different:

$ curl -kvu "jss:****************" -H "Content-type: text/xml" https://jss.*********/JSSResource/accounts
*   Trying *.*.*.*...
* TCP_NODELAY set
* Connected to jss.**** (*.*.*.*) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Iterable, Inc.; CN=*.****
*  start date: Dec 20 00:00:00 2017 GMT
*  expire date: Jan  4 12:00:00 2019 GMT
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Server auth using Basic with user 'jss'
* Using Stream ID: 1 (easy handle 0x7fa10400c600)
> GET /JSSResource/accounts HTTP/2
> Host: jss.****
> Authorization: Basic anNzLWFkbWluOjdIdGt5R0hrJTNKJU4xM1RMSzBWNW1lbQ==
> User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
> Accept: */*
> Referer: 
> Content-type: text/xml
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 401 
< date: Thu, 08 Feb 2018 22:08:10 GMT
< content-type: text/html;charset=UTF-8
< content-length: 424
< set-cookie: AWSALB=EeUpRKAC4JskdDEjhyLzmc6eDemDZTbUJcQQogDvr8/hH4FmzZxRkVCI4n38u8I63VyBwNunaStiJOQShzA92up7vlHHob4DhmTOkJIhnUM8uNzPPc6MUPBLZJPU; Expires=Thu, 15 Feb 2018 22:08:10 GMT; Path=/
< x-frame-options: SAMEORIGIN
< cache-control: no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0
< accept-ranges: bytes
< server: Apache
* Authentication problem. Ignoring this.
< www-authenticate: Basic realm="Restful JSS Access -- Please supply your credentials"
< 
<html>
<head>
   <title>Status page</title>
</head>
<body style="font-family: sans-serif;">
<p style="font-size: 1.2em;font-weight: bold;margin: 1em 0px;">Unauthorized</p>
<p>The request requires user authentication</p>
<p>You can get technical details <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2">here</a>.<br>
Please continue your visit at our <a href="/">home page</a>.
</p>
</body>
</html>
* Connection #0 to host jss.**** left intact

How do I debug the issue? Is there some .htpasswd equivalent that I can look at?

steve_summers · ‎02-09-2018

So, oddly enough, this happened to me. Not sure if this will apply, but FWIW, here's what happened. I created an APIUSER account with a simple password. Worked great, then when it needed to move into production, we had to change the password to something a bit more complex. After the password change, it failed over and over again. I could log onto the JSS portal with the pw, it just wouldn't work in the code. So, after a few hours of pulling my hair out, I had a hunch that the JSS didn't like the password I changed it to. (A 20 character pw with special characters). We looked at it and then removed ampersands, percent signs and hash-tags, if it was in there. Low and behold, the 20 character pw then worked.

Not sure if this is the issue with your situation, but apparently the JSS doesn't like certain characters in passwords. Maybe you'll get lucky and they'll be in there and you can change them and it'll work. Good luck.

View solution in original post

koalatee · ‎02-08-2018

You need to specify the port in your connection address

wsg · ‎02-08-2018

Same issue, assuming it is: https://jss.:443/ - though, I'd imagine if it were a connection issue, I wouldn't have gotten as far as an auth error, right?

koalatee · ‎02-08-2018

The default port is :8443

wsg · ‎02-08-2018

Sorry, I should expand on this, we don't do 8443, it's proxied from an ALB to JSS (443 -> 8443). The termination point is an AWS ALB that's listening on 443 and handing off the traffic to the JSS instances, which do listen on 8443, but those are not directly accessible from the Internet.

I also tried this on an instance that I can directly access through 8443, same behavior.

$ curl -kvu "jss:**********************" -H "Content-type: text/xml" https://jss-master0.***********:8443/JSSResource/accounts
*   Trying 172.18.10.87...
* TCP_NODELAY set
* Connected to jss-master0.********* (172.18.10.87) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Iterable, Inc.; CN=*.*****.****
*  start date: Dec 20 00:00:00 2017 GMT
*  expire date: Jan  4 12:00:00 2019 GMT
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
*  SSL certificate verify ok.
* Server auth using Basic with user 'jss'
> GET /JSSResource/accounts HTTP/1.1
> Host: jss-master0.*************:8443
> Authorization: Basic anNzLWFkbWluOjdIdGt5R0hrJTNKJU4xM1RMSzBWNW1lbQ==
> User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
> Accept: */*
> Referer: 
> Content-type: text/xml
> 
< HTTP/1.1 401 Unauthorized
< X-FRAME-OPTIONS: SAMEORIGIN
< Cache-Control: no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0
< Date: Thu, 08 Feb 2018 22:44:37 GMT
< Accept-Ranges: bytes
< Server: Apache
* Authentication problem. Ignoring this.
< WWW-Authenticate: Basic realm="Restful JSS Access -- Please supply your credentials"
< Content-Type: text/html;charset=UTF-8
< Content-Length: 424
< 
<html>
<head>
   <title>Status page</title>
</head>
<body style="font-family: sans-serif;">
<p style="font-size: 1.2em;font-weight: bold;margin: 1em 0px;">Unauthorized</p>
<p>The request requires user authentication</p>

koalatee · ‎02-08-2018

Ah, yeah my bad. I get a different error when not specifying, still tries to do some auth though.

Someone else will have to weigh in. If your account has full admin then you shouldn't have any auth problems...

steve_summers · ‎02-09-2018

So, oddly enough, this happened to me. Not sure if this will apply, but FWIW, here's what happened. I created an APIUSER account with a simple password. Worked great, then when it needed to move into production, we had to change the password to something a bit more complex. After the password change, it failed over and over again. I could log onto the JSS portal with the pw, it just wouldn't work in the code. So, after a few hours of pulling my hair out, I had a hunch that the JSS didn't like the password I changed it to. (A 20 character pw with special characters). We looked at it and then removed ampersands, percent signs and hash-tags, if it was in there. Low and behold, the 20 character pw then worked.

Not sure if this is the issue with your situation, but apparently the JSS doesn't like certain characters in passwords. Maybe you'll get lucky and they'll be in there and you can change them and it'll work. Good luck.

ImAMicrosoftGuy · ‎05-17-2023

Hi Steve,

I know this post is old, but thank you so much. You save me the hours of pulling my own hair out over this. I was testing a script using my own account which has special characters in the password - and it wouldn't work. I made a new account with a less complex password, and boom, my API call works now. Thanks!!!

wsg · ‎02-09-2018

Well, the password complexity was the source of the problem. Really, Jamf?

blinvisible · ‎04-11-2018

I ran into this issue after upgrading to Jamf Pro 10.3. All my Python scripts that had worked with the API before the upgrade started getting HTTP Error 401: basic auth failed errors. Ultimately that issue was caused by a base64 decode of the password inserting a newline character at its end. I'm not sure what changed in version 10.3 where that was now an issue where it wasn't before, but modifying the password variable declaration from

pw = base64.b64decode("aBase64EncodedPasswordString")

to

pw = base64.b64decode("aBase64EncodedPasswordString").strip()

was all that was required to get those scripts working again.

Additionally, if a limited character set is negatively affecting your password entropy, go for length instead. I'm successfully using a 64-character password for API authentication.

Jamf Nation Community

API authentication doesn't work