Solved: Tracing a D101 error. - Micro Focus Community

MarkMoorhead · ‎2020-12-09

Good Afternoon!

Recently I have been discovering a TON of D101 errors in my POA log files for a former employee showing like this:

Error: User not on post office [D101] User:xxxxxx    App( SOAP )

Is there a way to trace where these request to the POA are coming from? We only have one Post Office, user is no longer in GroupWise, doesn't have any outstanding nicknames, isn't in GMS, isn't in eDirectory, etc.

I have tried rebuilding my post office database as mentioned in a TID I saw, but that didn't help either.

I discovered this because every few weeks, always on the weekend for some reason, our server bogs down and requires a restart. Since there are many more of these errors on the weekend, they may be the cause.

GroupWise 18.2.1 running on OES 2018

Thanks for any help you can provide!

laurabuckley · ‎2020-12-16

Hi,

I suggest doing a packet capture on the server filtering on the SOAP port. That could reveal the IP address that the SOAP requests are coming from. I use "tcpdump" on servers to accomplish this.

Cheers,

Laura

Laura Buckley

Views/comments expressed here are entirely my own.
If you find this post helpful, please show your appreciation and click on "Like" below...

View solution in original post

mathiasbraun · ‎2020-12-10

A simple login attempt via WebAccess would cause this. Try to login to WebAccess as "Dirk Nowitzki" (unless he has a valid account, of course) or someone else without an account in your system and check the logs.

If you like it: like it.

ketter · ‎2020-12-10

I don't recall, but can left over event configurations cause this?

See https://support.microfocus.com/kb/doc.php?id=7005743

--
Ken
Knowledge Partner

Create and vote for enhancements in the Idea Exchange forums!
Don't forget to Like helpful posts and mark Solutions!

MarkMoorhead · ‎2020-12-10

Thanks for the suggestions. This user's name wasn't in the list as described in the TID, and I did a test login with a bad username in Webaccess and did see the bad username in the log but only once. The departed user in question shows up 1064 times in a 50 minute chunk of log file. The only user I'm seeing in the logs near as much is the only user we have that works remote and uses a caching mailbox on the Windows client. I'm pretty sure the departed user didn't have the know-how to set that up.

Mark

mathiasbraun · ‎2020-12-10

Did you check apache logs for what happened at the times you get the D101 logged?

If you like it: like it.

MarkMoorhead · ‎2020-12-10

I just looked at logs in /var/log/appache2 and user's name doesn't show up in any of those, but neither did the bogus user I used for test, so maybe I'm not looking at the correct logs.

mathiasbraun · ‎2020-12-10

You wouldn't see a username there, but you'd see ip addresses of connecting devices. As you've mentioned that it happens mainly on the weekend (i.e. not too many "regular" logins) it should be fairly easy to track down.

If you like it: like it.

mathiasbraun · ‎2020-12-10

And you can see the invalid user in the webaccess log along with the timestamp.

If you like it: like it.

MarkMoorhead · ‎2020-12-10

After looking at those logs, request is definitely not coming from webaccess.

mathiasbraun · ‎2020-12-11

It could be merely anything using SOAP, which potentially means any sort of 3rd. party software. This could include smarthosts which check for the existence of the receiver of an incoming mail.

If you like it: like it.

booktrunk · ‎2020-12-11

Could the user have had access to a system that was sending automated reports at the weekend and kept trying?

MarkMoorhead · ‎2020-12-15

To be clear, it's not just on the weekends, there's just more on the weekends. Still thousands a day no matter what day it is. I'm going to look at router for SOAP access to see if it's from the outside. However, if it's internal, I was just looking to see if there was a way to trace here the requests are coming from.

Thanks for all the suggestions! I've been out of the office a few days.