The authorization issue in Exchange 2013 for pop3/imap?

Hello!


Asking for help from the community as it broke all available in the office of the head :)

There is Exchange 2013, there is a domain on a separate server, there are accounts in the domain. Exchange 2013 in same domain.


Users uchetok no problem go to mail Exchange 2013 via the web interface OWA. Mail also works fine.


But these users can't work with your e-mail clients. Authorization via POP3/IMAP irrespective of the type of encryption the server throws an error with incorrect data access: in the case POP3 says that invalid username/password, and in the case of IMAP says "NO LOGIN".


There is a suspicion that the case the user rights on a domain controller... But what could be the problem — is not clear. Who knows, prompt where to look for the cause.


PS. tried the option to install domain controller and exchange on the same machine — everything worked without problems on all of the available POP3/IMAP/HTTPS.

P. p.s. use Windows 2012 with all updates.
October 3rd 19 at 03:43
4 answers
October 3rd 19 at 03:45
After a long analysis of the problem... bought UCшный SSL certificate (instead of self-signed) — it worked at the time.
Conclusion: use enterprisename ON, please be kind and purchase the correct certificates.

PS. if anyone finds/knows how to circumvent the need to purchase the certificate, write here, please.
habrahabr.ru/post/106252 - anjali.Maye commented on October 3rd 19 at 03:48
And to add yourself to the trusted root certification authorities? - pearl_Web commented on October 3rd 19 at 03:51
October 3rd 19 at 03:47
POP3S (SSL version ) works ?
No, also not working. - anjali.Maye commented on October 3rd 19 at 03:50
October 3rd 19 at 03:49
Had a similar problem. Helped the following command in power shell: Set-popsettings –server CAS01 –LoginType 1
after that you must restart the POP3 service
October 3rd 19 at 03:51
It certainly has deathtopic, but still. You are in this situation just turn off the encrypted authorization including logintype 1 - good no SB such audit will not allow it.
The LoginType parameter specifies the authentication method for IMAP4 connections. Valid values are:
1 or PlainTextLogin.
2 or PlainTextAuthentication.
3 or SecureLogin. This is the default value.
I am now faced with the same problem. Only with IMAP. On the server are SAN certificates issued by our CA abortivnym. Everything worked, but after any failure ceased. And tests show that somehow used Samovodene certificate, although the findings show commands that are used in common.

Mysticism and only. Now dig in and write a decision.
logintype not need to change. I helped Set-IMAPSettings –EnableGSSAPIAndNTLMAuth:$FALSE
Read more here blogs.technet.com/b/mspfe/archive/2015/08/24/excha... - anjali.Maye commented on October 3rd 19 at 03:54

Find more questions by tags E-mailMicrosoft Exchange