Ru-Board.club
← Вернуться в раздел «В помощь системному администратору»

» Microsoft Exchange Server

Автор: YuYuK
Дата сообщения: 01.05.2014 03:12
Zvuv1

Копать в сторону авторизации SMTP. Только пользователи прошедшие авторизацию на SMTP могут отправлять письма внешним получателям.

Если, конечно, Вы не хотите использовать открытый relay.
Автор: Zvuv1
Дата сообщения: 01.05.2014 05:47
Авторизацию поставил - теперь выплывает новая проблема:
Если пользователь админ на сервере - всё стало ОК, но если рядовой пользователь, то при проверке подключения:
Отправка тестового электронного сообщения: Отклик сервера: 550 5.7.1 Client does not have per
Автор: YuYuK
Дата сообщения: 01.05.2014 09:34
Zvuv1
Я правильно понимаю, что пользователь, который пытается отправить почтовое сообщение, не является владельцем почтового ящика?
Автор: pezzak
Дата сообщения: 01.05.2014 19:12
YuYuK


[PS] C:\Windows\system32>Get-ClientAccessServer | FL Auto*


AutoDiscoverServiceCN : EXCHANGE-MAIN
AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service
AutoDiscoverServiceInternalUri : https://exchange-main.****federation.com/Autodiscover/Autodiscover.xml
AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
AutoDiscoverSiteScope : {Moscow-Data-Centr}

AutoDiscoverServiceCN : exchange-geneva
AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service
AutoDiscoverServiceInternalUri : https://exchange-geneva.****federation.com/Autodiscover/Autodiscover.xml
AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
AutoDiscoverSiteScope : {Geneve}

[PS] C:\Windows\system32>Get-OutlookAnywhere | FL *Hostname*


ExternalHostname : mail2.****financial.ch

[PS] C:\Windows\system32>Get-WebServicesVirtualDirectory | FL *Url*


InternalNLBBypassUrl : https://exchange-main.****federation.com/ews/exchange.asmx
InternalUrl : https://exchange-main.****federation.com/EWS/Exchange.asmx
ExternalUrl : https://****financial.ch/ews/exchange.asmx

[PS] C:\Windows\system32>Get-EcpVirtualDirectory | FL *Url*


InternalUrl : https://exchange-main.****federation.com/ecp
ExternalUrl :


[PS] C:\Windows\system32>Get-OabVirtualDirectory | FL *Url*


InternalUrl : http://exchange-main.****federation.com/OAB
ExternalUrl : https://****financial.ch/OAB
Автор: YuYuK
Дата сообщения: 01.05.2014 19:35
pezzak

Не знаю, что Вам сказать.
Остаюсь с идеей, что Ваши клиенты идут через какой-то реверсный прокси.
Запустите через Outlook проверку автоконфигурации электронной почты и посмотрите в какие IP адреса разименовываются имена серверов.
Чудес не бывает. Если OWA показывает правильный сертификат, то скорей всего Outlook’и лезут на какие-то web-службы на которых используется самоподписанный сертификат. Такое может быть, если используется Split DNS, например.
Для большего понимания надо смотреть глазами.
Автор: Zvuv1
Дата сообщения: 02.05.2014 09:04

Цитата:
Zvuv1
Я правильно понимаю, что пользователь, который пытается отправить почтовое сообщение, не является владельцем почтового ящика?

Да, получается так. Странное дело - даёшь на ящик права для SELF - и всё начинает работать. Правда через некоторое время права для SELF опять пропадают.
Буду разбираться, кто там что накрутил до меня.
Автор: YuYuK
Дата сообщения: 02.05.2014 12:09
Zvuv1
Дайте этому пользователю на чужой ящик SendAs
Автор: Zvuv1
Дата сообщения: 04.05.2014 05:53
Не получается:
Общие сведения: всего элементов: 1. Успешно: 0, с ошибками: 1.
Прошло времени: 00:00:00


MYDOMAIN\test3
Ошибка

Ошибка:
Операция Active Directory над server не выполнена. Данная ошибка не допускает повторения попытки. Дополнительные сведения: Отказано в доступе.
Отклик Active Directory: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0


У пользователя недостаточно прав.
Щелкните здесь для справки... http://technet.microsoft.com/ru-RU/library/ms.exch.err.default(EXCHG.141).aspx?v=14.1.438.0&t=exchgf1&e=ms.exch.err.Ex6AE46B

Попытка выполнения команды командной консоли Exchange:
Add-ADPermission -Identity 'CN=Test,OU=Users,OU=external,DC=mydomain,DC=ru' -User 'mydomain\test3' -ExtendedRights 'Send-as'

Прошло времени: 00:00:00

Автор: YuYuK
Дата сообщения: 04.05.2014 13:17
Zvuv1

Скорей всего, надо включить наследование разрешений на учетную запись Test
Автор: Zvuv1
Дата сообщения: 05.05.2014 08:58
Спасибо большое, всё получилось!
Только вопрос - а почему так? Наследование по умолчанию не включено? Или поковырялся кто-то?
Автор: YuYuK
Дата сообщения: 05.05.2014 09:11
Zvuv1
Не за что. Рад был помочь.
Наследование по умолчанию включено, но бывают ситуации, когда его бывает необходимо отключить. Например, если Вы делегируете управление учетными записями и группами отделу технической поддержке, но при этом не хотите, чтобы они управляли учетными записями руководителей отделов и департаментов.
Так же некоторые учетные записи защищаются самим AD. Это учетные записи администраторов домена. Это тоже может привести к некоторым последствиям. Например, у таких учетных записей может не работать ActiveSync.

UPD. Что у Вас было я сказать, конечно, не могу. Тут Вам надо с предшественниками разбираться.
Автор: Zvuv1
Дата сообщения: 05.05.2014 11:24
Как то странно - у меня у пользователей права Send As пропадают через какое-то время....
Автор: Esida
Дата сообщения: 05.05.2014 14:39
Доброго времени суток.

Кто сталкивался с такой проблемой:

Стоит Exchange 2003, настроен домен ххх.ru, почта ходит хорошо, всё работает.
Потребовалось подцепить второй домен yyy.ru, имя пользователя к прмиеру test. Т.е. test@xxx.ru и test@yyy.ru, ящик настроен по POP3, т.к. на этом ящике сидят несколько юзверей из домена.
Подключили отдельный IP,всё хорошо, если не одно НО... Почта задваивается! Если приходит почта на один из доменов, то на второй ящик другого домена приходит это же письмо, при том что написано что это письмо предназначено первому домену.
Может где надо поставить галочку?
Подскажите кто знает пожалуйста.
Автор: YuYuK
Дата сообщения: 05.05.2014 19:13
Zvuv1

Если у Вас что-то там третье не используется, то права на учетные запись могут измениться, если учетная запись является членом защищенных групп.

Раз.
http://btsc.webapps.blackberry.com/btsc/viewdocument.do;jsessionid=14F86D6B29C7C05D426830262D27DBC9?externalId=KB04707&sliceId=2&cmd=displayKC&docType=kc&noCount=true&ViewedDocsListHelper=com.kanisa.apps.common.BaseViewedDocsListHelperImpl

Два.
http://theessentialexchange.com/blogs/michael/archive/2008/10/22/admincount-adminsdholder-sdprop-and-you.aspx


Добавлено:
Esida
Ничего не понятно. У Вас два отдельных ящика или один ящик у которого два SMTP адреса? Если второе, то понятно почему письма “задваивается”.
Автор: Zvuv1
Дата сообщения: 05.05.2014 22:38
YuYuK - спасибо огромное!
Автор: YuYuK
Дата сообщения: 05.05.2014 23:04
Zvuv1

Не за что.

Помогли статьи?
Автор: Zvuv1
Дата сообщения: 06.05.2014 00:45
Первая мой случай.
Автор: NumberI
Дата сообщения: 12.05.2014 09:15
Здравствуйте, подскажите по коннекторам приема. В организации есть DAG с 2 CAS, возникает ошибка:

Цитата:
Microsoft Exchange could not find a certificate that contains the domain name cas01.*.ru in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default_new with a FQDN parameter of cas01.*.ru. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.


Я так понимаю неправильно настроен Default коннектор приема и нужно поменять его FQDN на имя внешней почты (коннектора отправки). Но там отмечена Проверка подлинности Exchange Server, в связи с чем это сделать невозможно. Так ли все настроено в следующем примере?


Цитата:
AuthMechanism : Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer
Banner :
BinaryMimeEnabled : True
Bindings : {0.0.0.0:25}
ChunkingEnabled : True
DefaultDomain :
DeliveryStatusNotificationEnabled : True
EightBitMimeEnabled : True
BareLinefeedRejectionEnabled : False
DomainSecureEnabled : False
EnhancedStatusCodesEnabled : True
LongAddressesEnabled : False
OrarEnabled : False
SuppressXAnonymousTls : False
AdvertiseClientSettings : False
Fqdn : CAS01.*.ru
PermissionGroups : AnonymousUsers, ExchangeUsers
PipeliningEnabled : True
ProtocolLoggingLevel : None
RemoteIPRanges : {0.0.0.0-255.255.255.255}
RequireEHLODomain : False
RequireTLS : False
EnableAuthGSSAPI : False
ExtendedProtectionPolicy : None
LiveCredentialEnabled : False
TlsDomainCapabilities : {}
Server : CAS01
Name : Default CAS01
IsValid : True

AuthMechanism : Tls, Integrated, BasicAuth, BasicAuthRequireTLS
Banner :
BinaryMimeEnabled : True
Bindings : {0.0.0.0:9587, :::9587}
ChunkingEnabled : True
DefaultDomain :
DeliveryStatusNotificationEnabled : True
EightBitMimeEnabled : True
BareLinefeedRejectionEnabled : False
DomainSecureEnabled : False
EnhancedStatusCodesEnabled : True
LongAddressesEnabled : False
OrarEnabled : False
SuppressXAnonymousTls : False
AdvertiseClientSettings : False
Fqdn : CAS01.*.ru
PermissionGroups : AnonymousUsers, ExchangeUsers
PipeliningEnabled : True
ProtocolLoggingLevel : None
RemoteIPRanges : {0.0.0.0-255.255.255.255}
RequireEHLODomain : False
RequireTLS : False
EnableAuthGSSAPI : True
ExtendedProtectionPolicy : None
LiveCredentialEnabled : False
TlsDomainCapabilities : {}
Server : CAS01
Name : Client CAS01
IsValid : True


AuthMechanism : ExternalAuthoritative
Banner :
BinaryMimeEnabled : True
Bindings : {192.168.1.63:25, 192.168.2.254:25, 192.168.1.204:25}
ChunkingEnabled : True
DefaultDomain :
DeliveryStatusNotificationEnabled : True
EightBitMimeEnabled : True
BareLinefeedRejectionEnabled : False
DomainSecureEnabled : False
EnhancedStatusCodesEnabled : True
LongAddressesEnabled : False
OrarEnabled : False
SuppressXAnonymousTls : False
AdvertiseClientSettings : False
Fqdn : CAS01.*.ru
PermissionGroups : AnonymousUsers, ExchangeUsers, ExchangeServers, ExchangeLegacyServers, Custom
PipeliningEnabled : True
ProtocolLoggingLevel : None
RemoteIPRanges : {192.168.2.0/24, 192.168.1.0/24, 10.0.201.0/24, 10.0.2.0/24}
RequireEHLODomain : False
RequireTLS : False
EnableAuthGSSAPI : False
ExtendedProtectionPolicy : None
Server : CAS01
Name : Anonymous Relay
IsValid : True


Второй CAS настроен идентично.
Автор: Hubo
Дата сообщения: 12.05.2014 16:57
нет ничего общего с cas array name тут нет (т.к. используется имя hubtransport role server)
ругань что нет локального сертификата в хранилище как я понимаю, создайте его
Автор: YuYuK
Дата сообщения: 12.05.2014 18:17
NumberI

1.Если у Вас в ближайшее время нет задачи по шифрованию SMTP с помощью TLS, то может просто забить на это сообщение.
2.Если Вас раздражает это сообщение, то может убрать из AuthMechanism значение TLS.
3.Если хотите понять, как используются сертификаты в Exchange (в том числе и в SMTP), то http://technet.microsoft.com/ru-ru/library/bb851505%28v=exchg.80%29.aspx
Автор: NumberI
Дата сообщения: 13.05.2014 13:12
Hubo
Разве, коннектор приема не должен содержать внешнее имя, прописанное в коннекторе отправки?

сертификат есть, но сделанный на внешнее и внутреннее общее имя, а данная ошибка возникает на обоих CAS

Спасибо за ответ
Автор: YuYuK
Дата сообщения: 13.05.2014 15:26
NumberI

Цитата:
Разве, коннектор приема не должен содержать внешнее имя, прописанное в коннекторе отправки?

Необязательно. Это имя будет использоваться в HELO/EHLO, но на прием это не важно.


Цитата:
сертификат есть, но сделанный на внешнее и внутреннее общее имя, а данная ошибка возникает на обоих CAS

Издайте новый сертификат, добавив в SAN имена обоих CAS.

Автор: silver06
Дата сообщения: 14.05.2014 12:36
Доброго времени суток

Столкнулся с абсолютно странной проблемой. =( Она вроде на столько простая... Но я
"клина" похоже словил =)

Ситуация следующая:

На виртуалке (hyper-v) поставил домен контроллер (Stardart 2012). На вторую поставил 2012 Data center и Exchange 2013 Enterprise. Все остальное, что необходимо (центр сертификации и прочее так же имеется).
На серваке будут сидеть 2 абсолютно независимые друг от друга компании... Никаких проблем сделать разные OAB и прочее нет... Проблема тривиальная... Добавляю второй домен (Accepted Domain). Он добавляется, все ок...
При создании нового пользователя нет выпадающего списка для выбора доп. домена. Только основной. Хотя я помню, когда exchange 2013 только вышел и я его тестировал, то обратил внимание и еще подумал, как удобно, что добавляешь доп. домены и можно сразу пользователя в нем делать.
Не проблема нужные адреса через Email address polices, но в этом случае, созданный пользователь через web-доступ не может залогиниться как имя_пользователя@дополнительный_домен (дополнительный_доме\имя_пользователя - тоже).

В чем может быть проблема? Куда копать?
Автор: YuYuK
Дата сообщения: 14.05.2014 12:46
silver06


Цитата:
созданный пользователь через web-доступ не может залогиниться как имя_пользователя@дополнительный_домен (дополнительный_доме\имя_пользователя - тоже).


Все правильно. Вводите имя пользователя как domain\user_name, где domain - это NetBIOS имя AD домена, а не accept domain.

Если хотите, чтобы пользователи проходили авторизацию как user_name@accept_domain. то надо fqdn имя accept domain добавить в Alternative UPN suffixes (ADDT).

Добавлено:
silver06

Например, чтобы было понятней.

Имеются один лес из одного домена - contoso.local

В этом лесу развернут Exchange. который обслуживает два SMTP домена: contoso.ru и fabrikan.ru. Вообще он будет еще обслуживать contoso.local тоже, т.к. это имя корневого домена леса и оно добавляется по умолчанию.

Есть пользователь Вася Пупкин. Его имя пользователя - vasya (именно это имя он указывает входя на компьютер). Он имеет почтовый ящик с SMTP адресом - v.pupkin@fabrikan.ru.

Вот чтобы он попал в свой почтовый ящик через OWA, Outlook Anywhere или ActiveSync, учетные данные он должен вводить в виде contoso\vasya
Автор: pezzak
Дата сообщения: 14.05.2014 17:49
YuYuK
решилась проблема!
вообщем дело было в следующем:
внешний домен имеет тоже имя, что и домен active-directory. есть вебсервер, на котором настроен хитрый реврайт и на нем же висел этот самоподписанный сертификат. а у 2013 отлука какая-то другая логика работы автодисковера, вот он и ругался постоянно на него. решилось закрытием 443 порта в сторону веб-сервера.

спасибо за участие!
Автор: YuYuK
Дата сообщения: 14.05.2014 18:50
pezzak

Не за что.
Рад был помочь. Хотя, должен признаться, для меня звучит всё это как-то странно. Т.е. было понятно, что у Вас клиенту идут не на CAS сервера, но логика работы autodiscover осталась та же. Что для доменных клиентов (через SCP), что для недоменных (через autodiscover в DNS).
Решение меня удивляет. Раз у вас Split DNS (внешний домен имеет тоже имя, что и домен active-directory), то не проще бы было на внутренних DNS указать для autodiscover и cas IP адрес не реверсного прокси (хитрый реврайт), а IP адреса CAS серверов?
Ну, это ладно. Это я так. Ради чистого искусства. )))
Автор: life_so_good
Дата сообщения: 15.05.2014 13:54

Цитата:
всем доброго дня, есть проблема с отправкой от имени в Outlook 2010, Exchange 2010 SP3
 
если при выборе "от", где в списке сохранен e-mail от имени которого ранее отправлял почту - "Нельзя отправить сообщение от лица этого пользователя без соответствующего разрешения. Убедитесь, что отправка..."
 
если выбираю "от", "другой адрес электронной почты..." и пишу в форме тоже самое (как в примере ниже), все нормально отправляется

к уже имеющимся send as permissions добавить в mail flow settings / delivery options / send on behalf
Автор: itepower
Дата сообщения: 22.05.2014 05:48
Ошибки IIS вот такие, подскажите.

Процесс, обслуживающий пул приложений "MSExchangeSyncAppPool", обнаружил неустранимую ошибку связи со службой активации Windows. Идентификатор процесса "8024". Поле данных содержит номер ошибки.

Неожиданное завершение процесса обслуживающего пул приложений "MSExchangeMapiMailboxAppPool". ID процесса "8940". Код выхода процесса "0xffffffff".
Автор: artemk
Дата сообщения: 22.05.2014 06:48
itepower
почитай
http://social.technet.microsoft.com/Forums/ru-RU/2e26d0d9-629a-462d-bfb3-c3b8316ff1dd/-exchange?forum=exchange2010ru
http://social.technet.microsoft.com/Forums/ru-RU/7f9e58d1-9f6d-4a2b-ad9e-c318025d300c/-?forum=exchange2013ru
Автор: itepower
Дата сообщения: 26.05.2014 06:32
Не помогает, ошибка HTTP 500

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115

Предыдущая тема: Проблема с доверием


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.