Issues with basicauth on SMTP on a user account (same stuff works fine on others)

Question

Hi,

we inherited a tenant from another company. They might have been messing around with settings already, so far haven't been able to find what though.

Have create an AuthenticationPolicy which is assigned to users:

PS C:\Windows\system32> get-user |ft Name, AuthenticationPolicy

Name                                                         AuthenticationPolicy
----                                                         --------------------
admin                                                        BLOCK-BasicAuth
boris                                                        BLOCK-BasicAuth
info                                                         ALLOW-BasicAuth
kosten                                              ALLOW-BasicAuth

Now, kosten is a new mailbox recently created and it works fine there.

I test this with:

openssl s_client -connect smtp.office365.com:587 -crlf -starttls smtp
<stripped a lot of tls info>
250 SMTPUTF8
helo domain.com
250 AM0PR10CA0049.outlook.office365.com Hello [<IP>]
auth login
334 VXNlcm5hbWU6
<base64 username>
334 UGFzc3dvcmQ6
<base64 password>
235 2.7.0 Authentication successful
mail from: <******@address.com>
250 2.1.0 Sender OK
rcpt to: <******@otheraddress.com>
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
Subject: test
test
.
250 2.0.0 OK <******@YADA.eurprd09.prod.outlook.com> [Hostname=YADA.eurprd09.prod.outlook.com]

And all is well.

Do the same thing with the info account however and after authentication part it says:

RENEGOTIATING
write:errno=0

Instead of:

235 2.7.0 Authentication successful

Like if it's trying to renegotiate TLS settings. I have no clue why this happens. It only happens if correct credentials for the info box are entered.

Have compared output from get-user, get-mailbox and get-casmailbox between the 2 accounts and don't see anything obvious (besides the obvious stuff like names being different there are no differences)

Kinda stumped.

Can log onto portal.office.com with just username/password just fine with the info account btw, the tenant doesn't have any conditional access policies.

Any ideas what might be causing this?

Answer 1

Is SMTP auth enabled on that user?

Get-CASMailbox info | select SmtpClientAuthenticationDisabled

Also make sure that the device/app you are testing with supports TLS1.2

Answer 2

No it isn't:

PS C:\Windows\system32> get-casmailbox | ft name, smtpclientauthenticationdisabled

Name                                                         SmtpClientAuthenticationDisabled
----                                                         --------------------------------
boris                                                                                    True
info                                                                                    False
kosten                                                                         False

That also wasn't enough btw, had to enable SMTP authentication on the transport as well (without that I got a temporary error after authenticating on the now functioning mailbox - the info already tried to renogatiate at that point but if I remember correctly it already did that before enabling basicauth as well) and as I had to do that I've set the BLOCK-BasicAuth authenticationpolicy default via Set-OrganizationConfig.

OpenSSL supports TLS1.2 (and 1.3) and that same client works fine for the other mailbox. Quite a curious thing this.

Answer 3

Hi @Ferry van Steen ,

Any luck if reassigning the authentication policy to the user info?

Set-User -Identity info -AuthenticationPolicy $null   
Set-User -Identity info -AuthenticationPolicy ALLOW-BasicAuth   
Set-User -Identity info -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)  

---

If an Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 4

Hi,

thanks for the re'.

Tried reassigning the policy, but it hasn't made any difference I'm afraid. It's still trying to renegotiate the TLS connection.

Considering it's trying to alter the TLS policy I'm guessing there's probably something different in security requirements on the account. Just don't have a clue what.

Any ideas on what I could check? Don't see any differences on the accounts in Azure AD through the webportal, but that's probably severely limited to what it shows vs powershell.

Answer 5

I ran up against this issue today and found this epic answer: https://stackoverflow.com/a/77386509/2146624

Basically, if you're using openssl, base64 encoded strings cannot start with an R, otherwise you will need to pass the -nocommands option.

- openssl s_client -connect smtp.office365.com:587 -crlf -starttls smtp
+ openssl s_client -connect smtp.office365.com:587 -crlf -starttls smtp -nocommands

Hopefully you were able to figure this out :)