401 response from API | MDaemon Technologies Community Forum
  1. Forum
  2. MDaemon API
  3. 401 response from API

401 response from API

  • M

    I am getting a 401 response when making a post request to the XML API with message: 'A logon request contained an invalid logon type value.' A google search shows this might be related to a Windows account setting, but am not sure.

    I created an 'apiuser' account within MDaemon with global and domain administrator roles. Am using PHP and guzzle to make the HTTP POST request, below. (Simple example just to test connection functionality.) It's using basic authorizatin in the header via a base 64 encoded string of the MDaemon user and their password, e.g. "apiuser:<password>".

    Has anyone else run into this before? Any help or guidance would be greatly appreciated!

    $xmlData = "<MDaemon>
	<API productversion=\"23.5.0\" serviceversion=\"23.5.0.2\">
		<Request version=\"23.5\" echo=\"0\" verbose=\"0\">
			<Operation>GetGlobalAdminList</Operation>
			<Parameters/>
		</Request>
	</API>
</MDaemon>";

$response = $client->request('POST', $mailerDomain, [
	'headers' => [
		'Content-Type' => 'text/xml; charset=UTF8',
		'Authorization: ' . $this->getAuthorizationHeaderValue(),
	],
	'verify' => false,
	'body' => $xmlData,
]);
    0 likes
  • A

    What does the value of the Authorization header look like in the data that is posted?  It should contain the authentication type as the first paramenter.

    Is should look like the following (Obviously the encoded string will be different):

    Authorization: Basic YXJyb25AYXJyb24uYWx0lxdWU3OCEtMjAxOQ==

    --
    Arron Caruth

    0 likes
  • M

    It evaluates to:

    Authorization: Basic YXBpdXNlcjpJUXJrdFNMb2M1WXBxekc=
    0 likes
  • A

    MDaemon, by default, requires the full email address be used to login.  If you change the username to be the full email address, do you have the same issue?

    --
    Arron Caruth

    0 likes
  • M

    Still getting a 401 with the full email address 😕

    0 likes
  • A

    What do the logs show is happening? 

    The MDMgmtWS log shows the activity from the XML-API. 

    You'll also want to check the dynscrn log file to make sure the request is not being blocked by dynamic screening.

    --
    Arron Caruth

    0 likes
  • M

    Here's the content from MdMgmtWS-2023-11-15.log. I have made a few requests to the API today.

    231115 020309027 G Management Web Service (64bit) for MDaemon Messaging Server 23.5.0.2 Log file starting
231115 020309027 G 0x41350011 0x00000009
231115 020309027 G 0x41350010 C:\MDaemon\Data\MgmtWS.ini
231115 020309026 D [00000001] 0x41420012 Initializing.
231115 020309093 D [00000001] 0x4142001E Initialization Complete

    I checked the DynScrn log file and there was nothing related to the user account making the API calls.

     

    0 likes
  • A

    Looks to me like the requests are being denied before it gets to the XML API, which would lead me to believe that dynamic screening or some other security feature is blocking the request.  Is there anything in the dynamic screening log regarding the IP the requests are coming from?

    If the requests are not coming from a local IP, could location screening be blocking them?

    If you make a request from the MDamon server to 127.0.0.1, does it work?

    Is there a firewall or proxy that could be blocking requests?

    --
    Arron Caruth

    0 likes
  • M

    I checked the DynScrn log file from yesterday, and I do believe you are on to something with the dynamic screening. Not sure why this wasn't logged today, but nontheless here is a snippet from yesterday's log. My IP (below) is apparently being blocked, even though we have an Allow List for 10.10 IPs. You can see the 'apiuser' account that is being used in the request, that I mentioned earlier.

    231114 110224730 I [00000047] 0x41505017 Allow List: API: found IP:10.10.1.7 VIA:10.0.0.0/8
231114 110224732 I [00000047] 0x41502817 Auth failure: API: IP:10.10.1.7 ACCT:apiuser
231114 110224734 D [00000047] 0x41502AC7 Auth failure processing cancelled due to Allow List Exemption: API: IP:10.10.1.7 VIA:10.0.0.0/8
    0 likes
  • A

    The log indicates your local IP is on the allow list. 10.*.*.* is on the list by default.   It also shows us that authentication was failing yesterday when you were not using the full email address.

    Check to make sure the account is not frozen or disabled.  Accounts / Edit Account / select the APIUser account and click edit.

    You can also configure Dynamic screening to log more details so we can make sure the connections are getting to MDaemon.  Security / Dynamic Screening / Options|Customize, check the boxes for:

    Log allow lists hits

    Log Trusted IP list hits

    Log connections allowed

    Log black list hists

    log location screening hits

    log successful authentications

    Log connections refused

    This is probably more info that you want, but it will verify that nothing in dynamic screening is blocking the connection.

    What URL are you posting the request to?

    The XML API runs in the Remote Administration web server which runs on port 1000 by default. HTTPS is on port 444. It should be something like this:

    http://mail.domain.com:1000/mdmgmtws

    Since dynamic screening is recognizing it as a connection to the API, its probably correct, but please check it just to be sure.  

    You can double check the URL in a browser, you should get prompted for credentials.  If you enter the MD user name and password, you should be shown the XML API help.

    --
    Arron Caruth

    0 likes
  • M

    Thank you so much for the prompt and couteuous feedback, Arron. I implemented all the suggestions above. Was still getting the 401. Then, as a last resort I tried making the request outside of using PHP guzzle, and it worked! In this case, I used Postman to make the request and got back the 200 with XML data. So, I will look into an alternative solution to using guzzle as the http client. Thanks again!

    0 likes
  • A

    I'm glad you figured out that Postman was working.  Have you compared the data that is being sent by postman to the data being sent by PHP guzzle?  Perhaps there is a slight difference that is causing the issue.

    --
    Arron Caruth

    0 likes
  • M

    We figured it out to be a configuration issue with guzzle on our end. Lesson learned. But your feedback led the way.

    0 likes
  • A

    Great, I'm glad you got to the bottom of it!

    --
    Arron Caruth

    0 likes
Please login to reply to this topic!

Participants