password to destination server failing

[ckemp19]

Trying to sync one server to another, destination server credentials consistently failing. Verified credentials are valid - wondering if this could be related to the last commit, that mentioned issues with special characters? The password used contains the - character.

[ckemp19]

Previous build from January fails as well, same issue

[ckemp19]

hm - testing with a different account, no special chars, auth. also fails with a known good account...

[ckemp19]

OK - also tested with a new account, removing a . in the user name (previously was like user.name so I created a user "migrator" password with no special chars) and this took. Could there be an issue with passing Destination user name?

[BIG-RAT]

Just used the following accounts migration.user and user.2 with passwords of .?!@#$%^&() and ,./!@#$%^&() - neither gave errors. Both were administrators. Still getting authentication failures?

[ckemp19]

Yeah - weird, I got them consistently on the destination server. Originally I was using my own creds, which are valid AD creds - source server never complained (still using them) but the dest. would not accept it, or our local utility account either - only by creating a new account was I able to get it to work. I can log into the web app or API fine with either of these, so I don't know what else the issue could be.

[rtrouton]

I'm also seeing the same issue with Jamf Migrator 2.7.1, where I've verified that the logins on the destination server are appear as Failed Login in the JSSAccess log.

Logins using the same credentials to the web console and via other tools which use the API are succeeding, so the problem appears to be just with Jamf Migrator. In my case the only special character used in the account password is -.

[rtrouton]

Creating a new API account on the destination server did not initially fix the problem, as the password also contained special characters. Once I set a password for the new account which used no special characters in the password, I was able to log in.

[timelost11]

Went in today to transfer some items from our Dev to Prod and started to get this error. Our Dev was just updated to 10.3.1 and it is the server that is throwing the error. Our Prod has not been updated as of yet.

There are no special characters in my password, although I do have an "_" in my username.

[Pelton]

Same problem here. 10.3.1 and 2.7.1. No special characters in username. Migrator worked until a few weeks ago with identical username and password. Problem appears with Source MDM. We have a local instance as well as two in Jamf's cloud: problem occurs with all three Jamf instances. Problem occurs with three different accounts.

[BIG-RAT]

Strange. Do you also get authentication issues is you swap source/destination servers? Basically what it's calling is something like: curl -w " %{http_code}" -ku "jamfadmin:s3cr3t" https://your.jamf.server:8443/JSSResource/buildings and checking the response code (http_code).

Perhaps launch the app in debug mode and see if there is any more info in the logs. /Applications/jamf-migrator.app/Contents/MacOS/jamf-migrator -debug

[timelost11]

After talking with my TAM, he recommended changing the password, which for my AD account would be a pain. What I did to get past the error on my 10.3.1 instance was to create a JSS account with the right permissions. The password was simplified to only characters, and I am able to now use that account on either source or destination. Still don't have the issue with authentication on my 10.2 instance.

[BIG-RAT]

Hopefully resolved the issue. I've been able to use both local and AD accounts with special characters on v10.3.1-10.4.0.

[Pelton]

Do you also get authentication issues is you swap source/destination servers?

I do. I have three servers: one on premise and two in the cloud. Matching versions. Same problem in each.

After talking with my TAM, he recommended changing the password .... The password was simplified to only characters

Didn't help me.

Note that the accounts that don't work for Migrator do work when I log into the GUI. For example, I have a local admin account named "pelton" in my on-premise environment. This is the account I had been using with Migrator, successfully. This is, also, the account I use in a daily basis for regular work. So, the account works via web authentication, but not via Migrator.

Note that I have tried Migrator on different versions of macOS and tried it on and off our LAN.

Still don't have the issue with authentication on my 10.2 instance.

While I no longer have a 10.2 instance, the problem does appear to have arrived when we moved from 10.1.x. to 10.3.x

I've been able to use both local and AD accounts with special characters on v10.3.1-10.4.0.

I've tried both to no avail.

CCing my friends @oliverlind and @krypted.

Debug mode log:

----- Debug Mode -----
[- debug -] func sectionToMigrate active tab: macOS.
[- debug -] Selectively migrating: ["computergroups"] for macOS
[- debug -] Start Migrating/Removal
[- debug -] Migrating data from https://cpsmdm.jamfcloud.com to https://cpsmdmdev.jamfcloud.com.
[- debug -] go sender tag: nil
[- debug -] Go button pressed from: selectToMigrateButton
[- debug -] Active tab: selective
[- debug -] Migration Mode (Go): selective
[- debug -] --- checking availability of server: https://cpsmdm.jamfcloud.com
[- debug -] checking: https://cpsmdm.jamfcloud.com
[- debug -] --- checking availability of server: https://cpsmdmdev.jamfcloud.com
[- debug -] checking: https://cpsmdmdev.jamfcloud.com
[- debug -] Server check: https://cpsmdm.jamfcloud.com, httpResponse: 200
checkURL2 data: []
[- debug -] Server check: https://cpsmdmdev.jamfcloud.com, httpResponse: 200
checkURL2 data: []
[- debug -] --- checking authentication to: https://cpsmdm.jamfcloud.com
[- debug -] checking: https://cpsmdm.jamfcloud.com/JSSResource/buildings
[- debug -] https://cpsmdm.jamfcloud.com/JSSResource/buildings auth check httpResponse: 401

[- debug -] ---------- status code ----------
[- debug -] 401
[- debug -] ---------- status code ----------

[- debug -] ---------- response ----------
[- debug -] <NSHTTPURLResponse: 0x7fc3438ab3e0> { URL: https://cpsmdm.jamfcloud.com/JSSResource/buildings } { Status Code: 401, Headers {
    "Accept-Ranges" =     (
        bytes
    );
    "Cache-Control" =     (
        "no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0"
    );
    Connection =     (
        "keep-alive"
    );
    "Content-Length" =     (
        424
    );
    "Content-Type" =     (
        "text/html;charset=UTF-8"
    );
    Date =     (
        "Thu, 03 May 2018 16:39:27 GMT"
    );
    Server =     (
        "Jamf Cloud Node"
    );
    "Www-Authenticate" =     (
        "Basic realm=\"Restful JSS Access -- Please supply your credentials\""
    );
    "X-FRAME-OPTIONS" =     (
        SAMEORIGIN
    );
} }
[- debug -] ---------- response ----------

Source server authentication failure.

[rtrouton]

@BIG-RAT 2.7.2 has resolved the problem on my end. Authentication is now working with special characters in my password.

[BLRpunga]

Has anyone seen this behavior with version 2.7.2 of the Migrator?

We have a 2 Jamf cloud hosted instances, one for production, the other for testing, both are at version 10.3.1-t1522933524. Both instances are fairly new as we just recently completed the jump start session and are standing up our environment. My Jamf Customer Success specialist set up the test environment at my request with a limited number of seats. I've logged into the test instance successfully but have left it untouched otherwise. He suggested this tool as a way of migrating our configuration to the testing environment, but I have not been able to transfer and am getting a similar, though slightly different, authentication failure outlined above.

Initially, I believed the issue had to do with my user name which contained a '.' and password which contained a special character, the '@' sign, so I created another admin account, simply called 'migration' and set a password of only lowercase letters. However, it also returns the same message.

The attempts to login do not appear in the Jamf server logs, so it appears the request never gets to our environment.

Thoughts?

[Pelton]

Note: 2.7.2 appears to have solved my problem.

[BLRpunga]

That's the version I'm using, just d/l'ed this afternoon:

[BIG-RAT]

@BLRpunga - the /api shouldn't be there. Did you enter https://your.jamfcloud.com for the address?

[BLRpunga]

Yes the address with no trailing slash or additional directories. The address I've entered is: https://xxxxx.jamfcloud.com (obscured here) I am not sure why the error message is displaying the /api.

[BIG-RAT]

Perhaps remove the settings file: ~/Library/Application\ Support/jamf-migrator/settings.plist

Also, I have seen the 503 error, rarely, when the api is not accessable. When you say you logged into the gui, was the the api gui?

What does the following display (entering your credentials and server of course)? curl -w " %{http_code}" -ku "jamfadmin:s3cr3t" https://your.jamf.server:8443/JSSResource/buildings You can leave off the password if you prefer and get prompted for it.

[BLRpunga]

RE: Logging in to GUI: I was able to go the URL in the error message (/api) and see the list of API commands, but there was no option to login per say. My session with the Jamf Server was still live, so I was technically logged in.

The curl command comes back with this response: curl: (7) Failed to connect to xxxxx.jamfcloud.com port 8443: Operation timed out

Wiping out the settings file didn't resolve the issue.

As I was writing this, I received an email from Jamf's status saying that an issue which was affecting less than 1% of customers had been resolved. But my issue is still occurring.

Here is how the migration tool is configured:

[BIG-RAT]

API - no login, right, I should have been more specific. Are you able to do lookups?

My bad on the curl command, since you're cloud hosted you don't need the 8443. This should give better details: curl -w " %{http_code}" -ku "jamfadmin:s3cr3t" https://your.jamf.server/JSSResource/buildings

[BLRpunga]

Results from the curl command: [{"healthCode":2,"httpCode":503,"description":"SetupAssistant"}] 503

I'm guessing this means I have to walk through the setup assistant in the new test environment before migrating the configuration?

[BIG-RAT]

Correct.

[kotoky]

Hello, Any resolution with account authentication failure? I'm running the latest version of the migration tool.