Password Expiring issue when using REST

We use windows authentication for single sign on with our Epicor instances. We are on 10.2.200.3.
We have set up an AD user in Epicor which will act as the account from which we are calling REST services.

Each time I pass the username and credentials into Postman to make a call, I am returning this error:

.

As a workaround, I go into the user account maintenance and I click “Expire Password”.
Without changing the credentials I pass, I then can perform another GET request and I get back data.

I am able to send a couple of requests, but then I am back to the “Password has expired” exception.

I am not entirely sure what is causing this or how to make it “stick”. The user account password policy is set to never expire in AD.

Any ideas?

Not sure if it’s the same bug but we have run into similar issues with the task agent since it appears to require some settings related to the user that only get set when using Epicor username/password to login. The two ways we’ve found to fix this:
1 - Set up an app server that uses Epicor user / password and login as that user.
2 - Update fields on the Ice.SysUserFile and Erp.UserFile that get set during this activity (LastDate on Erp.UserFile and PwdLastChanged and LastLogonAttempt on Ice.SysUserFile)

Hope this helps,
Tanner

1 Like

In Postman you use Epicor name and password, not Windows. That is why it checks expiration.

Thanks Olga.
What is their Epicor password though, since we are using windows auth for everything?
Not sure why it works once and then fails to work again…

i think there are 3 attempts for new user (or after Reset passwrod) before he must change his password. Probably this is what happens for you.
You need to define password for the user. Or you should not use normal password for the user in Postman. Though i don’t know if Postman supports Windows auth…

1 Like

It looks like you are using both Windows AUth and Username/Password for that user. I assume you want to exclusively use Windows Auth?
e.g. - ERP 10 is not going to reset anything in Active Directory for passwords. I don’t think any decent AD Admin would allow a random app to play in AD logic :slight_smile:

So once you disable Epicor password management, you need to flip in Postman from Basic Authentication to a Windows Auth approach instead. Think about how you can tell your browser to handle passwords.

1 Like

Postman support of Windows Auth is in beta:

1 Like

Yes, they will need windows auth in order to use a VPN to get into the environment to work, but the same credentials will be used to call the API from their application.
Sorry I’m a bit slow at this; when you say disable Epicor password management, what does that mean?
The same issue happens when the user calls from any rest client, so I imagine this is on the Epicor password management side as you suggest.

It definitely is behaving how you desrived that after I “expire” the password, I am able to make 3 calls to the API and then it will expire again.
How can I manually set the user password?

Well, it is easy if you login using name and password in ERP. But you use Windows auth and i am not sure how to do it in that case…

Require SSO means none of the Epicor username and password management is leveraged which is what I think you want.

Doing that gives me a new exception :slight_smile:

you successfully forbade yourself to logon other than using Windows credentials :slight_smile:

You can’t cross the streams :wink:

If you require SSO, / Windows Auth, you need to use Windows NTLM.
Basic Auth is for ‘custom authentication’ aka - Epicor Username/Password

Haha that does make sense.
I feel like I’m going around in circle on this.
So I should not select “Require Single Sign On” for the user, since they will be passing credentials in the header of the API call. The user also has an AD account, and our environment is using windows credentials to log into Epicor while inside the network. All Epicor users in my environment use windows authentication to log into Epicor with
When making the call from outside the network, there needs to be some way to authenticate the user. I plan on using basic authentication or NTLM authentication for this.
When using the users Epicor username and network password, I am allowed to make 3 calls with either Basic or NTLM Authentication before I get the “Password has expired” exception.

In the REST Implementation guide, I believe it goes over using Basic Authentication with Postman as an example. This seems straightforward, other than the problem described in this thread.

In Epicor, none of our users are marked as “Require Single Sign On”. We implement SSO via IIS (I believe).

you don;t use Require SSO flag, so you can login with username and password as well. The only problem I don’t know how you can easily setup password for such users if no ERP installation is working with name\password binding.
you can get token in swagger Help page and use it in Postman. Or you can make Postman work thought NTLM, as Bart wrote that it is supported.

The three strikes and your out functionality, password policy and account lockout policy are ONLY for Epicor username / password handling.

If you are coming in as Windows Auth they are not applicable - Windows is in charge and ICE just sits there waiting for a thumbs up from the OS if you are legit.

You indicate a need for ‘mixed mode’ - Users on the network as Windows Identity over Windows Auth and Epicor Username / password for remote access over the interwebs. Very common and no issue. You just need to keep the auth mechanisms straight and also ensure you don’t have blank passwords and let people steal identities. Ideally an admin would set all their users to not allow blank passwords but … backwards compat we kept around for them to have their servers taken over by hackers. Not a deployment I would recommend but … educate and move on.

The ‘RequireSSO’ flag is to prevent a ‘Windows Auth Only’ user from having their account stolen when the account has a blank password. Now that there is autogenerate password and mail it to the user, I hope to never see another blank password user entry.

Looks like if your user has option Allow Password Change ON, you can change the password in Classic UI menu or in Modern UI settings, regardless your current binding.

If they change their password will it “stick”, allowing us to use the REST API as I’m trying to use it?
I feel like this isn’t clear at all, at least for me…

@Aaron_Moreng when and if you get SSO Auth working with REST could you post a more detailed example of how you did it? I’m on the same battle right now and it isn’t clear how to get it to work