10.06.2013, 02:27 | #1 |
Чайный пьяница
|
IFD + сертификаты в CRM 2011
Как правильно объяснить заказчику какие сертификаты ему необходимы для публикации CRM через IFD. Я задачу выполнил через Self-Signed сертификаты наивно полагая, что этого хватит. Да, после публикации и танцев с бубном я добился, чтобы связка заработала, но при попытке настроить Outlook клиент получил ошибку, что доверенное соединение не установлено.
Я так понимаю, что для корректной работы потребуется сертификат на домен + вайлдкарт сертификат на субдомены вроде такого: contoso.com + *.contoso.com
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством. Подписывайтесь на мой блог, twitter и YouTube канал. Пользуйтесь моим Ultimate Workflow Toolkit |
|
10.06.2013, 07:36 | #2 |
Moderator
|
Чтобы проверка безопасности соединения отработала корректно, издатель сертификата должен быть помещен в список доверенных для компьютера (не пользователя). Это может быть любой сертификат, в том числе и самовыданный.
В меню run запусти команду mmc затем добавь в консоль оснастку с сертификатами (CTRL + M). При подключении выбери удостоверение компьютера. Далее следует добавить сертификат, например, в каталог Enterprise Trust. Если все сделано правильно, IE перестанет выдавать предупреждение безопасности при открытии страницы. Разумеется, для доменных машин это может быть сделано через GPO, однако подход будет работать не для всех клиентов. Например, Java реализует собственное хранилище сертификатов, куда самопальный сертификат придется помещать отдельно. Свое хранилище так же реализует браузер Firefox. Что бы сертификат был совсем уж доверенный, он должен быть выдан одним из авторитетных центров сертификации, но это платная и не быстрая процедура.
__________________
http://fixrm.wordpress.com, снятие/наведение порчи. Быстро, дорого, гарантия. MS Certified Dirty Magic Professional Последний раз редактировалось Артем Enot Грунин; 10.06.2013 в 07:42. |
|
|
За это сообщение автора поблагодарили: a33ik (5). |
11.06.2013, 14:26 | #3 |
Участник
|
А вопрос только в сертификате? Недавно работал с публикацией CRM через IFD, и основные проблемы при подключении с помощью Outlook клиента связаны были с настройкой ADFS. И да, как сказал Артем, для того чтобы клиентская машинка смогла подсоединиться нормально из вне, необходимо на каждом компе установить сертификаты (включая рутовый).
Ну а что касаемо заказчика, то основной мотивацией является, что сертификат полученный от авто.центров сертификации могут быть использованы не только в рамках публикации CRM, но и в принципе всех сервисов (почта, сайты, веб-сервисы и т.п.) Последний раз редактировалось scint; 11.06.2013 в 14:31. |
|
11.06.2013, 14:32 | #4 |
Чайный пьяница
|
[QUOTE=scint;291946основные проблемы при подключении с помощью Outlook клиента связаны были с настройкой ADFS.[/QUOTE]
Для одного клиента всё взлетело, для другого - через веб работает, через Outlook нет. Можете, пожалуйста, поподробнее рассказать в чём заключалась проблема?
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством. Подписывайтесь на мой блог, twitter и YouTube канал. Пользуйтесь моим Ultimate Workflow Toolkit |
|
11.06.2013, 15:07 | #5 |
Участник
|
Если один из вне полностью доступ имеет, а у другого Outlook клиент не подключается, то
серверная часть как Вы понимаете не при чем. Сертификаты на обоих компах установлены и в Root и в Personal (доверенные корневые центры/ личные)? При доступе по web на обоих компах наблюдаете claims-based аутентификацию (формочка такая серая)? И еще, компы в домене или нет? Возможно, что комп не может получить тикет для доступа в домен. У меня была проблема, что компы не могли получить нормально тикет. Внешне это выражалось так. Пытаюсь завести новую организацию при конфигурировании Outlook клиента, он запрашивает у меня имя и пароль, а дальше получаю ошибку, что доступ запрещен. Оказалось, что проблемы была с неверной настройкой фаервола и часть траффика зарезалась. Но в вашем случае как минимум одна машинка работает, а значит все в инфраструктуре хорошо( Ищите разницу между клиентскими компами. Ну и посмотрите еще раз логи Outlook клиента |
|
11.06.2013, 15:33 | #6 |
Чайный пьяница
|
Вероятно не совсем корректно выразился. У одного клиента (1-й IFD) всё заработало. У второго (другой клиент, другой сервер, другой IFD) не заработало. Разворачивал всё аналогично.
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством. Подписывайтесь на мой блог, twitter и YouTube канал. Пользуйтесь моим Ultimate Workflow Toolkit |
|
11.06.2013, 15:38 | #7 |
Еда - топливо, Одежда - н
|
У меня были похожие проблемы.
Вот что писал админ: 1. [критично]убедиться что с машины на которой выполняется вход резолвятся имена зоны corp.ХХХ.ua, если машина в локальной сети то поставить днс сервером 192.168.ХХ.Х - на этом хосте находится зона. Для доступа извне 2. [необходимо]добавить в исключения браузера: https://*.corp.ХХХ.ua 3. [желательно для браузера и критично для аутглюка] сделать импорт сертификата corp-SERVAD-CA, обязательно положить в хранилище "Доверенные корневые центры сертификации". Но у нас были проблемы с AD и DNS. Серваки и машины были в разных AD, с DNS тоже какие-то были проблемы. Может поможет |
|
11.06.2013, 15:50 | #8 |
Участник
|
Понятно в таком случае кончено "идеального" решения не существует.
1. Добейтесь, чтобы internal acces заработал при включенной на сервере Claims-based аутентификации (проверьте, что сертификат установлен на CRM сервере, что разрешение к данному сертификату имеет учетная запись из под которой запущен iis app pool, ну то есть все в соответствии с ms). Статей много, но при настройке лично я использовал http://www.interactivewebs.com/blog/...-hosted-setup/ и вот это видео http://www.youtube.com/watch?v=ZD5qaa-G99E 2. После того, как заработает внутренний доступ, запустите IFD на CRM ну и настройте уже external access Нюансов может быть много, но вот этими двумя шагами вы сможете отсечь проблемы связанные с внешними dns, правилами на ADFS и т.п. от просто внутренних (сертификат, работа ADFS с DC и т.п.) |
|
11.06.2013, 16:30 | #9 |
Чайный пьяница
|
Я ж пишу. Доступ через браузер к IFD деплойменту есть. Т.е. проблемы с DNS, сертификатами и прочее не должны быть причиной неработоспособности.
При попытке подключить Outlook к CRM получаю следующую ошибку: Код: 08:25:16|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ServerForm._testConnectionButton_Click 08:25:16|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ServerForm.TestConnection 08:25:16|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm.TestConnection 08:25:16|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm._testConnectionButton_Click 08:25:18| Error| Error connecting to URL: https://something.com:444/XRMServices/2011/Discovery.svc Exception: System.InvalidOperationException: Metadata contains a reference that cannot be resolved: 'https://something.com:444/XRMServices/2011/Discovery.svc?wsdl'. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure. at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception) at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.TlsStream.CallProcessAuthentication(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result) at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.ConnectStream.WriteHeaders(Boolean async) --- End of inner exception stack trace --- at System.Net.HttpWebRequest.GetResponse() at System.ServiceModel.Description.MetadataExchangeClient.MetadataLocationRetriever.DownloadMetadata(TimeoutHelper timeoutHelper) at System.ServiceModel.Description.MetadataExchangeClient.MetadataRetriever.Retrieve(TimeoutHelper timeoutHelper) --- End of inner exception stack trace --- at System.ServiceModel.Description.MetadataExchangeClient.MetadataRetriever.Retrieve(TimeoutHelper timeoutHelper) at System.ServiceModel.Description.MetadataExchangeClient.ResolveNext(ResolveCallState resolveCallState) at System.ServiceModel.Description.MetadataExchangeClient.GetMetadata(MetadataRetriever retriever) at System.ServiceModel.Description.MetadataExchangeClient.GetMetadata(Uri address, MetadataExchangeClientMode mode) at Microsoft.Xrm.Sdk.Client.ServiceMetadataUtility.RetrieveServiceEndpointMetadata(Type contractType, Uri serviceUri, Boolean checkForSecondary) at Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1..ctor(Uri serviceUri, Boolean checkForSecondary) at Microsoft.Xrm.Sdk.Client.ServiceConfigurationFactory.CreateConfiguration[TService](Uri serviceUri) at Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.GetAuthProviderForDeployment(Uri endPoint, Credential credentials, Uri webEndPoint) at Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo.DeploymentInfo.ValidateAuthProvider() at Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo.SortAndValidateDeployments() 08:25:18| Error| Exception : Metadata contains a reference that cannot be resolved: 'https://something.com:444/XRMServices/2011/Discovery.svc?wsdl'. at Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo.LoadOrganizations(AuthUIMode uiMode, Form parentWindow) at Microsoft.Crm.Application.Outlook.Config.ServerForm.LoadOrganizations(Boolean forceUI) at Microsoft.Crm.Application.Outlook.Config.ServerForm.<InitializeBackgroundWorkers>b__0(Object sender, DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument) 08:25:18| Error| Exception : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. at System.Net.HttpWebRequest.GetResponse() at System.ServiceModel.Description.MetadataExchangeClient.MetadataLocationRetriever.DownloadMetadata(TimeoutHelper timeoutHelper) at System.ServiceModel.Description.MetadataExchangeClient.MetadataRetriever.Retrieve(TimeoutHelper timeoutHelper) Это может означать, что есть проблемы с сертификатом, но сертификат помещён в указанные хранилища компьютера, с которого запускаю Outlook (Личные и Доверенные центры сертификации). Возможно я упускаю что-либо?
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством. Подписывайтесь на мой блог, twitter и YouTube канал. Пользуйтесь моим Ultimate Workflow Toolkit |
|
13.06.2013, 13:31 | #10 |
Участник
|
https://something.com:444/XRMService...overy.svc?wsdl
а эта ссылка из вне открывается вообще через браузер? и ошибок нет в IE? Нужно добиться, чтобы с клиентской машины через IE был нормальный доступ, то есть без запроса типа "Ошибка в сертификате...." "Продолжить" http://clip2net.com/s/5dLWXZ http://clip2net.com/s/5dLYeV Вопрос в том, что в IE вы можете нажать "Продолжить" и спокойно дальше проаутентифицироваться. При подключении по Outlook клиенту, это не прокатит. Не произойдет нормальной аутентификации при доступе к службе Discovery.svc. Пока только такие мысли ( |
|
13.06.2013, 17:04 | #11 |
Moderator
|
Цитата:
Так же, не забывай что Outlook ищет Discovery сервис. Убедись что он доступен по адресу. Возможно что-то криво настроено и IIS адресует страницу куда-то не туда.
__________________
http://fixrm.wordpress.com, снятие/наведение порчи. Быстро, дорого, гарантия. MS Certified Dirty Magic Professional |
|
|
|