K
Короче у Егора отмазы, нихуя не может и вот все проблемы
Size: a a a
2020 December 27
エ
Действительно, хочу бесплатно, не хочу ничего изучать
И вообще, я изучаю постоянно. Но извините, не маркетинговые тексты Microsoft.
KZ
А зачем это делать, что вебпочты нет?
мб хочется в аутлук... я хз
SG
И вообще, я изучаю постоянно. Но извините, не маркетинговые тексты Microsoft.
а что изучаете ?
K
мб хочется в аутлук... я хз
А что сложно сделать оутлуе на другой машине?
K
D
И вообще, я изучаю постоянно. Но извините, не маркетинговые тексты Microsoft.
Оно же как на базаре
Дорого? Иди походи, поищи похожее, но дешевле
Не нашёл? Ну тогда покупай
Дорого? Иди походи, поищи похожее, но дешевле
Не нашёл? Ну тогда покупай
IB
Давайте начнём с текущего.
Почему, например, нельзя развернуть AzureAD на Google Cloud или AWS?
Почему, например, нельзя развернуть AzureAD на Google Cloud или AWS?
Нифига вы тут нафигачили. Но я начну отсюда, где остановились.
Почему? By design. Потому что Azure AD - это неотчуждаемый публичный облачный сервис, то есть такая штука, которая размещается, обслуживается и развивается его разработчиком. Вы же не спрашиваете, почему нельзя разместить Google Apps в AWS? Потому что. Кроме того, есть и несколько чисто технических моментов. Во-первых, минимальный штамп, в который AAD - теоретически! - могла бы влезть, это порядка тысячи физических серваков, будет очень дорого и сложно. Во-вторых, весь смысл его в его централизованности и нахождении в облаке. Фактически, инфраструктура AAD это один большой распределенный сенсор, который позволяет обеспечивать ту самую "киберустойчивость" - возможность противостоять современным атакам. Например, "с земли" вы не увидите атаку password spray никак, а AAD отловит ее на изи.
Теперь вопрос второй: а нахрена вам это собственно надо? Возможный ответ: ну, мне нравится как AAD работает, нравится Conditional Access, я хочу его использовать для входа в Google Apps/AWS/you name it. Ответ: не вопрос, вы можете это сделать. В AAD есть прямо каталог веб-приложений с уже настроенным SSO, и их там что-то очень много, тысячи три было когда я последний раз смотрел. Больше того, вы можете интегрироваться со всем, что понимает стандартные протоколы веб-аутентификации (SAML, OAuth...), либо вообще просто имеет форму логина и кнопку "войти". Если это ваше собственное приложение - есть SDK (MAL, Microsoft Authentication Library, aka ADAL), который можно туда интегрировать.
Либо вот: я странный парень, я хочу чтобы точка аутентификации пользователя при использовании AAD находилась непременно в AWS. Не вопрос: поднимаем там контроллер домена (новый, или в существующем лесу) и настраиваем аутентификацию через ADFS или PTA.
Можно еще повысасывать из пальца. Потеря сетевой связности - не ваша проблема, кроме того у МС собственная глобальная сеть передачи данных, если не крупнейшая, то точно в топ-3. Если ее положат, недоступность AAD будет не самой большой из проблем всего мира. Санкции! В этом случае сервис перестанет для вас работать независимо от его гео-расположения. Напоминаю, SAP "Силовых машин" был в датацентре Ростелекома, где успешно превратился в тыкву.
На этом у меня фантазия заканчивается, если у вас есть сценарий, который прямо вот требует развернуть AAD где-то еще, не там где она развернута, то выкладывайте его сюда.
Почему? By design. Потому что Azure AD - это неотчуждаемый публичный облачный сервис, то есть такая штука, которая размещается, обслуживается и развивается его разработчиком. Вы же не спрашиваете, почему нельзя разместить Google Apps в AWS? Потому что. Кроме того, есть и несколько чисто технических моментов. Во-первых, минимальный штамп, в который AAD - теоретически! - могла бы влезть, это порядка тысячи физических серваков, будет очень дорого и сложно. Во-вторых, весь смысл его в его централизованности и нахождении в облаке. Фактически, инфраструктура AAD это один большой распределенный сенсор, который позволяет обеспечивать ту самую "киберустойчивость" - возможность противостоять современным атакам. Например, "с земли" вы не увидите атаку password spray никак, а AAD отловит ее на изи.
Теперь вопрос второй: а нахрена вам это собственно надо? Возможный ответ: ну, мне нравится как AAD работает, нравится Conditional Access, я хочу его использовать для входа в Google Apps/AWS/you name it. Ответ: не вопрос, вы можете это сделать. В AAD есть прямо каталог веб-приложений с уже настроенным SSO, и их там что-то очень много, тысячи три было когда я последний раз смотрел. Больше того, вы можете интегрироваться со всем, что понимает стандартные протоколы веб-аутентификации (SAML, OAuth...), либо вообще просто имеет форму логина и кнопку "войти". Если это ваше собственное приложение - есть SDK (MAL, Microsoft Authentication Library, aka ADAL), который можно туда интегрировать.
Либо вот: я странный парень, я хочу чтобы точка аутентификации пользователя при использовании AAD находилась непременно в AWS. Не вопрос: поднимаем там контроллер домена (новый, или в существующем лесу) и настраиваем аутентификацию через ADFS или PTA.
Можно еще повысасывать из пальца. Потеря сетевой связности - не ваша проблема, кроме того у МС собственная глобальная сеть передачи данных, если не крупнейшая, то точно в топ-3. Если ее положат, недоступность AAD будет не самой большой из проблем всего мира. Санкции! В этом случае сервис перестанет для вас работать независимо от его гео-расположения. Напоминаю, SAP "Силовых машин" был в датацентре Ростелекома, где успешно превратился в тыкву.
На этом у меня фантазия заканчивается, если у вас есть сценарий, который прямо вот требует развернуть AAD где-то еще, не там где она развернута, то выкладывайте его сюда.
KZ
А что сложно сделать оутлуе на другой машине?
так там сложнее
"Директор хочет заходить в свою учётную запись дома так же, как он это делает и на работе"
"Директор хочет заходить в свою учётную запись дома так же, как он это делает и на работе"
SG
Нифига вы тут нафигачили. Но я начну отсюда, где остановились.
Почему? By design. Потому что Azure AD - это неотчуждаемый публичный облачный сервис, то есть такая штука, которая размещается, обслуживается и развивается его разработчиком. Вы же не спрашиваете, почему нельзя разместить Google Apps в AWS? Потому что. Кроме того, есть и несколько чисто технических моментов. Во-первых, минимальный штамп, в который AAD - теоретически! - могла бы влезть, это порядка тысячи физических серваков, будет очень дорого и сложно. Во-вторых, весь смысл его в его централизованности и нахождении в облаке. Фактически, инфраструктура AAD это один большой распределенный сенсор, который позволяет обеспечивать ту самую "киберустойчивость" - возможность противостоять современным атакам. Например, "с земли" вы не увидите атаку password spray никак, а AAD отловит ее на изи.
Теперь вопрос второй: а нахрена вам это собственно надо? Возможный ответ: ну, мне нравится как AAD работает, нравится Conditional Access, я хочу его использовать для входа в Google Apps/AWS/you name it. Ответ: не вопрос, вы можете это сделать. В AAD есть прямо каталог веб-приложений с уже настроенным SSO, и их там что-то очень много, тысячи три было когда я последний раз смотрел. Больше того, вы можете интегрироваться со всем, что понимает стандартные протоколы веб-аутентификации (SAML, OAuth...), либо вообще просто имеет форму логина и кнопку "войти". Если это ваше собственное приложение - есть SDK (MAL, Microsoft Authentication Library, aka ADAL), который можно туда интегрировать.
Либо вот: я странный парень, я хочу чтобы точка аутентификации пользователя при использовании AAD находилась непременно в AWS. Не вопрос: поднимаем там контроллер домена (новый, или в существующем лесу) и настраиваем аутентификацию через ADFS или PTA.
Можно еще повысасывать из пальца. Потеря сетевой связности - не ваша проблема, кроме того у МС собственная глобальная сеть передачи данных, если не крупнейшая, то точно в топ-3. Если ее положат, недоступность AAD будет не самой большой из проблем всего мира. Санкции! В этом случае сервис перестанет для вас работать независимо от его гео-расположения. Напоминаю, SAP "Силовых машин" был в датацентре Ростелекома, где успешно превратился в тыкву.
На этом у меня фантазия заканчивается, если у вас есть сценарий, который прямо вот требует развернуть AAD где-то еще, не там где она развернута, то выкладывайте его сюда.
Почему? By design. Потому что Azure AD - это неотчуждаемый публичный облачный сервис, то есть такая штука, которая размещается, обслуживается и развивается его разработчиком. Вы же не спрашиваете, почему нельзя разместить Google Apps в AWS? Потому что. Кроме того, есть и несколько чисто технических моментов. Во-первых, минимальный штамп, в который AAD - теоретически! - могла бы влезть, это порядка тысячи физических серваков, будет очень дорого и сложно. Во-вторых, весь смысл его в его централизованности и нахождении в облаке. Фактически, инфраструктура AAD это один большой распределенный сенсор, который позволяет обеспечивать ту самую "киберустойчивость" - возможность противостоять современным атакам. Например, "с земли" вы не увидите атаку password spray никак, а AAD отловит ее на изи.
Теперь вопрос второй: а нахрена вам это собственно надо? Возможный ответ: ну, мне нравится как AAD работает, нравится Conditional Access, я хочу его использовать для входа в Google Apps/AWS/you name it. Ответ: не вопрос, вы можете это сделать. В AAD есть прямо каталог веб-приложений с уже настроенным SSO, и их там что-то очень много, тысячи три было когда я последний раз смотрел. Больше того, вы можете интегрироваться со всем, что понимает стандартные протоколы веб-аутентификации (SAML, OAuth...), либо вообще просто имеет форму логина и кнопку "войти". Если это ваше собственное приложение - есть SDK (MAL, Microsoft Authentication Library, aka ADAL), который можно туда интегрировать.
Либо вот: я странный парень, я хочу чтобы точка аутентификации пользователя при использовании AAD находилась непременно в AWS. Не вопрос: поднимаем там контроллер домена (новый, или в существующем лесу) и настраиваем аутентификацию через ADFS или PTA.
Можно еще повысасывать из пальца. Потеря сетевой связности - не ваша проблема, кроме того у МС собственная глобальная сеть передачи данных, если не крупнейшая, то точно в топ-3. Если ее положат, недоступность AAD будет не самой большой из проблем всего мира. Санкции! В этом случае сервис перестанет для вас работать независимо от его гео-расположения. Напоминаю, SAP "Силовых машин" был в датацентре Ростелекома, где успешно превратился в тыкву.
На этом у меня фантазия заканчивается, если у вас есть сценарий, который прямо вот требует развернуть AAD где-то еще, не там где она развернута, то выкладывайте его сюда.
エ
Короче у Егора отмазы, нихуя не может и вот все проблемы
Сделай мне вход в домен c корпоративной почтой из настроек
K
Сделай мне вход в домен c корпоративной почтой из настроек
А что сложного?
KZ
Нифига вы тут нафигачили. Но я начну отсюда, где остановились.
Почему? By design. Потому что Azure AD - это неотчуждаемый публичный облачный сервис, то есть такая штука, которая размещается, обслуживается и развивается его разработчиком. Вы же не спрашиваете, почему нельзя разместить Google Apps в AWS? Потому что. Кроме того, есть и несколько чисто технических моментов. Во-первых, минимальный штамп, в который AAD - теоретически! - могла бы влезть, это порядка тысячи физических серваков, будет очень дорого и сложно. Во-вторых, весь смысл его в его централизованности и нахождении в облаке. Фактически, инфраструктура AAD это один большой распределенный сенсор, который позволяет обеспечивать ту самую "киберустойчивость" - возможность противостоять современным атакам. Например, "с земли" вы не увидите атаку password spray никак, а AAD отловит ее на изи.
Теперь вопрос второй: а нахрена вам это собственно надо? Возможный ответ: ну, мне нравится как AAD работает, нравится Conditional Access, я хочу его использовать для входа в Google Apps/AWS/you name it. Ответ: не вопрос, вы можете это сделать. В AAD есть прямо каталог веб-приложений с уже настроенным SSO, и их там что-то очень много, тысячи три было когда я последний раз смотрел. Больше того, вы можете интегрироваться со всем, что понимает стандартные протоколы веб-аутентификации (SAML, OAuth...), либо вообще просто имеет форму логина и кнопку "войти". Если это ваше собственное приложение - есть SDK (MAL, Microsoft Authentication Library, aka ADAL), который можно туда интегрировать.
Либо вот: я странный парень, я хочу чтобы точка аутентификации пользователя при использовании AAD находилась непременно в AWS. Не вопрос: поднимаем там контроллер домена (новый, или в существующем лесу) и настраиваем аутентификацию через ADFS или PTA.
Можно еще повысасывать из пальца. Потеря сетевой связности - не ваша проблема, кроме того у МС собственная глобальная сеть передачи данных, если не крупнейшая, то точно в топ-3. Если ее положат, недоступность AAD будет не самой большой из проблем всего мира. Санкции! В этом случае сервис перестанет для вас работать независимо от его гео-расположения. Напоминаю, SAP "Силовых машин" был в датацентре Ростелекома, где успешно превратился в тыкву.
На этом у меня фантазия заканчивается, если у вас есть сценарий, который прямо вот требует развернуть AAD где-то еще, не там где она развернута, то выкладывайте его сюда.
Почему? By design. Потому что Azure AD - это неотчуждаемый публичный облачный сервис, то есть такая штука, которая размещается, обслуживается и развивается его разработчиком. Вы же не спрашиваете, почему нельзя разместить Google Apps в AWS? Потому что. Кроме того, есть и несколько чисто технических моментов. Во-первых, минимальный штамп, в который AAD - теоретически! - могла бы влезть, это порядка тысячи физических серваков, будет очень дорого и сложно. Во-вторых, весь смысл его в его централизованности и нахождении в облаке. Фактически, инфраструктура AAD это один большой распределенный сенсор, который позволяет обеспечивать ту самую "киберустойчивость" - возможность противостоять современным атакам. Например, "с земли" вы не увидите атаку password spray никак, а AAD отловит ее на изи.
Теперь вопрос второй: а нахрена вам это собственно надо? Возможный ответ: ну, мне нравится как AAD работает, нравится Conditional Access, я хочу его использовать для входа в Google Apps/AWS/you name it. Ответ: не вопрос, вы можете это сделать. В AAD есть прямо каталог веб-приложений с уже настроенным SSO, и их там что-то очень много, тысячи три было когда я последний раз смотрел. Больше того, вы можете интегрироваться со всем, что понимает стандартные протоколы веб-аутентификации (SAML, OAuth...), либо вообще просто имеет форму логина и кнопку "войти". Если это ваше собственное приложение - есть SDK (MAL, Microsoft Authentication Library, aka ADAL), который можно туда интегрировать.
Либо вот: я странный парень, я хочу чтобы точка аутентификации пользователя при использовании AAD находилась непременно в AWS. Не вопрос: поднимаем там контроллер домена (новый, или в существующем лесу) и настраиваем аутентификацию через ADFS или PTA.
Можно еще повысасывать из пальца. Потеря сетевой связности - не ваша проблема, кроме того у МС собственная глобальная сеть передачи данных, если не крупнейшая, то точно в топ-3. Если ее положат, недоступность AAD будет не самой большой из проблем всего мира. Санкции! В этом случае сервис перестанет для вас работать независимо от его гео-расположения. Напоминаю, SAP "Силовых машин" был в датацентре Ростелекома, где успешно превратился в тыкву.
На этом у меня фантазия заканчивается, если у вас есть сценарий, который прямо вот требует развернуть AAD где-то еще, не там где она развернута, то выкладывайте его сюда.
грят лимит есть в телеге 😂
K
У меня все так и работает на красноглазом говне
SK
туннельный режим впн чтль, или как оно там называется. когда впн поднимается системой, чтоб входить в комп с корп учеткой
DA / AoVPN Device tunnel
K
Сделай мне вход в домен c корпоративной почтой из настроек
Что ты в автодискавери не смог, в активсинк смог?
KZ
DA / AoVPN Device tunnel
да да, это самое
IB
грят лимит есть в телеге 😂
ну я поэтому вот так, коротенечко. Вообще правильный ответ на этот вопрос - это беседа примерно минут на 40, плюс рисование относительно красивой схемы. :)
SG
DA - ну не надо изврата )