- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I just got a new PDI today with "Australia" release. I setup password for "admin" user account, and I can login to the "admin" account from browser successfully.
Then from a Linux VM, and also tried from macbook, I issue curl commands like these:
> curl -v -u 'admin:<pwd>' https://dev384358.service-now.com/api/now/stats/sys_user
> curl -v -u 'admin:<pwd>' https://dev384358.service-now.com/api/now/table/sys_user?sysparm_limit=1
> curl -v --user "admin:<pwd>" --header "Content-Type: application/json" --header "Accept: application/json" --request POST --data "{\"short_description\":\"incident $timestamp\",\"caller_id\":\"admin\"}" "https://dev384358.service-now.com/api/now/table/incident"
All the above got this response:
{"error":{"message":"User is not authenticated","detail":"Required to provide Auth information"},"status":"failure"}
from verbose:
* About to connect() to dev384358.service-now.com port 443 (#0)
* Trying 148.139.239.168...
* Connected to dev384358.service-now.com (148.139.239.168) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=*.service-now.com,O="ServiceNow, Inc.",L=Santa Clara,ST=California,C=US
* start date: Feb 12 00:00:00 2026 GMT
* expire date: Nov 13 23:59:59 2026 GMT
* common name: *.service-now.com
* issuer: CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1,O=DigiCert Inc,C=US
* Server auth using Basic with user 'admin'
> GET /api/now/stats/sys_user HTTP/1.1
> Authorization: Basic <xxxxx>
> User-Agent: curl/7.29.0
> Host: dev384358.service-now.com
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Server: snow_adc
< Date: Thu, 16 Jul 2026 01:36:02 GMT
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: JSESSIONID=6AFA7C03D6EB12FA6704512D996D76F8; Path=/; HttpOnly
< Server-Timing: t;desc="065c21e64702", sem_wait;dur=0, sesh_wait;dur=0
* Authentication problem. Ignoring this.
< WWW-Authenticate: Basic realm="Service-now"
< X-Content-Type-Options: nosniff
< Pragma: no-store,no-cache
< Cache-Control: no-cache,no-store,must-revalidate,max-age=-1
< Expires: 0
< Strict-Transport-Security: max-age=63072000; includeSubDomains
<
* Connection #0 to host dev384358.service-now.com left intact
{"error":{"message":"User is not authenticated","detail":"Required to provide Auth information"},"status":"failure"}
I need the PDI for integrating with our web app, so using REST API to access the PDI is needed. Please help to get the curl command working. Thanks!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello @MeiT,
Your curl syntax is fine, the password is fine, this isn't a credentials problem: on a brand new PDI provisioned this year, plain Basic Auth to the REST API is very likely being blocked outright by ServiceNow's new Basic Authentication Account Security restriction (or, less commonly, by MFA being enforced on the admin account), and neither of those care whether the password you typed is correct.
# 1. Register an OAuth API endpoint: System OAuth > Application Registry > New > # "Create an OAuth API endpoint for external clients" # 2. Get a token instead of sending Basic Auth curl -X POST "https://dev384358.service-now.com/oauth_token.do" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=password" \ -d "client_id=YOUR_CLIENT_ID" \ -d "client_secret=YOUR_CLIENT_SECRET" \ -d "username=admin" \ -d "password=YOUR_PASSWORD" # 3. Use the returned access_token as a Bearer token curl -H "Authorization: Bearer ACCESS_TOKEN_FROM_STEP_2" \ "https://dev384358.service-now.com/api/now/table/sys_user?sysparm_limit=1"
This works because the token endpoint authenticates you once through the platform's normal login stack (which can satisfy MFA and the new access checks), and every REST call after that just presents a Bearer token instead of a raw username and password on the wire, which is exactly the path the new restriction is nudging everyone toward anyway.
If you'd rather keep it simple and stay on Basic Auth for now (fine for a PDI you're just testing against), check these two things in order:
- Basic Auth Restriction: go to All > Basic Auth Restriction (backed by the sys_user_basic_auth_exception table). If admin shows up there with a pending decision, set it to "Maintain current login", which grants the account the snc_basic_auth_api_access role needed for API calls to keep working with Basic Auth.
- MFA on the admin user: open the admin user record and check the Multi-Factor Authentication related list. If MFA is enforced, Basic Auth can never satisfy it, curl has no way to supply a second factor, so you'll get exactly this 401 even with a correct password.
Either way, don't wire your web app to the admin account long term. Create a separate integration user, check Web service access only on that user record, give it only the roles the app actually needs (e.g. rest_service plus whatever table roles apply), and point your app at that account instead. It sidesteps both the MFA issue and most of the Basic Auth restriction fallout, and it's the pattern ServiceNow expects for any external integration.
One caveat: the Basic Auth Account Security rollout is being phased in per-instance (tracking mode records but doesn't block, enforcing mode blocks), so if you don't see a "Basic Auth Restriction" banner or module at all, this specific feature probably isn't what's hitting you and MFA is the more likely culprit to check first.
Thank you,
Vikram Karety
Octigo Solutions INC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello @MeiT,
Your curl syntax is fine, the password is fine, this isn't a credentials problem: on a brand new PDI provisioned this year, plain Basic Auth to the REST API is very likely being blocked outright by ServiceNow's new Basic Authentication Account Security restriction (or, less commonly, by MFA being enforced on the admin account), and neither of those care whether the password you typed is correct.
# 1. Register an OAuth API endpoint: System OAuth > Application Registry > New > # "Create an OAuth API endpoint for external clients" # 2. Get a token instead of sending Basic Auth curl -X POST "https://dev384358.service-now.com/oauth_token.do" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=password" \ -d "client_id=YOUR_CLIENT_ID" \ -d "client_secret=YOUR_CLIENT_SECRET" \ -d "username=admin" \ -d "password=YOUR_PASSWORD" # 3. Use the returned access_token as a Bearer token curl -H "Authorization: Bearer ACCESS_TOKEN_FROM_STEP_2" \ "https://dev384358.service-now.com/api/now/table/sys_user?sysparm_limit=1"
This works because the token endpoint authenticates you once through the platform's normal login stack (which can satisfy MFA and the new access checks), and every REST call after that just presents a Bearer token instead of a raw username and password on the wire, which is exactly the path the new restriction is nudging everyone toward anyway.
If you'd rather keep it simple and stay on Basic Auth for now (fine for a PDI you're just testing against), check these two things in order:
- Basic Auth Restriction: go to All > Basic Auth Restriction (backed by the sys_user_basic_auth_exception table). If admin shows up there with a pending decision, set it to "Maintain current login", which grants the account the snc_basic_auth_api_access role needed for API calls to keep working with Basic Auth.
- MFA on the admin user: open the admin user record and check the Multi-Factor Authentication related list. If MFA is enforced, Basic Auth can never satisfy it, curl has no way to supply a second factor, so you'll get exactly this 401 even with a correct password.
Either way, don't wire your web app to the admin account long term. Create a separate integration user, check Web service access only on that user record, give it only the roles the app actually needs (e.g. rest_service plus whatever table roles apply), and point your app at that account instead. It sidesteps both the MFA issue and most of the Basic Auth restriction fallout, and it's the pattern ServiceNow expects for any external integration.
One caveat: the Basic Auth Account Security rollout is being phased in per-instance (tracking mode records but doesn't block, enforcing mode blocks), so if you don't see a "Basic Auth Restriction" banner or module at all, this specific feature probably isn't what's hitting you and MFA is the more likely culprit to check first.
Thank you,
Vikram Karety
Octigo Solutions INC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Vikram, thank you for your instructions which helped me resolve the issue. Here are what I have tried:
The "admin" account in my PDI does not have MFA enabled. So I went to Basic Auth Restriction and added "admin" to Basic Auth Restriction Exception. But then I still got the same user authentication error.
Next I went to Users module and in "admin" user, add "snc_basic_auth_api_access" role to this user account. Then this curl command successfully could get back one incident record:
curl -u 'admin:<pwd>' https://dev384358.service-now.com/api/now/table/sys_user?sysparm_limit=1
{"result":[{"calendar_integration":"1","country":"","user_password": …….}]}
Thank you very much for your help!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @MeiT
- Ensure you are putting correct password in your curl command
curl -v -u 'admin:YourPasswordHere' "https://devXXXXX.service-now.com/api/now/table/sys_user?sysparm_limit=1"
Also check this post: https://www.servicenow.com/community/developer-forum/am-i-able-to-use-curl-command-on-a-developer-in...
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @Tanushree Maiti , thank you for your reply. I have put correct password in the curl command for sure. And this is also not base64 encoding problem. The problem is with the role of the account. For this PDI, the account has to have snc_basic_auth_api_access role in order to accept web access.
My problem is resolved now. Thanks for your help!