Symantec Access Management

When integrate with Office 365, the STS URL needed to be expose to Internet.  What is the best practice to protect the STS URL to avoid password failure attempt to lock the user acct?

Hi TC, 

You raised this questions under CA Directory Communit. Is this correct? If correct, can you tell me what you mean by STS URL? 

Thank you,

Marline

I think it was created under Security.

I am referring Siteminder SPS's secure token service for Office 365 integration   

HI,

As you know, we do have below STS end points and by default 1st two are already protected.

wsusername 
windowstransport
maxendpoint 

Could you please explain which STS url you want to protect?

Thanks,
Sharan

we would like to protect the ws-username as this URL is expose to Internet. attacker can use script to perform attack with user's email address

ws-username endpoint is an authentication endpoint which authenticates using basic credentials like userid/password.

Since it is already protected, I dont think there will be any problem if it is exposed to Internet.

Could you please elaborate more on how attacker can use script to perform attack with users email address?

Thanks,
Sharan

I don't think ws-username is being protected as per Office 365 integration guideline. Can you advice how can we protect this endpoint?  Any configuration change we need to perform under Office 365 tenant?

Below is the runbook for office365. You can verify the steps.

SAP Portal Services 

Thanks

Sharan

Hi Sharana,

The runbook seems does not cover any protection on the ws-username STS URL. Can you point it out if there is? Thanks

TC

This endpoint does not need protection as it is an authentication endpoint which takes credentials as input and does user authentication.

Thanks,
Sharan

In that case that will be easy for attacker to attempt login using the email account?

Attacker can attempt but he will not be successful until he knows the genuine user credentials, it is like a normal realm authentication.

Thanks,
Sharan

Then that will be a problem that all user accounts will be easily get locked for several failure attempt?

This problem is common not specific to STS.

For ex: if you protect a resource/realm using SSO, then if you access that resource in browser, login page will be displayed to user then attacker can enter wrong passwords.

if  you access gmail account, it shows login page, attacker can enter wrong login attempts using wrong pwds and whether accounts get locked or not, it depends on password policies.

hope this helps.

Thanks,
Sharan

On log in forms / auth schemes though things like CAPTCHA can be implemented, 2FA, or risk based auth etc. While nothing is perfect, these can help limit scope of mass password guessing and account locking - especially if it's combined with active monitoring.

Even on web services that authenticate users, at least for us, things like authenticating the client app in addition to the user credential provides that layer of protection. This prevents any random person from being able to use the service and mitigates the risk. Obviously Microsoft would have to support that capability here to do like mutual TLS auth + passing user creds.

If I expose just an STS with password only (that does nothing but try the bind to the directory), then it's wide open to allow someone to slow password guess or denial of service account locking.

It comes down to what, if any, mitigations can be put in place on the STS to prevent things like that. IP filtering (not super viable given Microsoft's dynamic nature on these)? Risk-based auth? Authenticate the client app? Or does it just have to be a documented accepted risk?