我想在Windows Server 2012上运行AD FS 2.0来发送objectGUID 。 我知道我可以为“依赖方信任”创build颁发转换规则，但AD FS 2.0如何知道objectGUID ？ 我是否需要在AD FS \ Service \ Claim Descriptions下为objectGUID添加声明描述？
ADFS v2服务器可以独立安装，还是与AD服务器紧密耦合？
使用客户端来configurationADFS，只需在电子邮件中获取： “我们使用Server 2008 Enterprise，在同一个盒子上运行AD，GP，DNS和DHCP。” 而现在他表示他也想在同一个盒子上安装ADFS。 我甚至不确定ADFS和AD是否可以在同一台服务器上，但是如果可以的话，我也不知道这是不是一个好主意。
我的同事和我正在尝试在ADFS 2.2中启用OAuth。 一切正常，除了服务器只传递一个访问令牌（w / expiration）并且在成功login后不包含刷新令牌。 这方面的文档很less，但是有谁知道什么设置需要更新才能返回刷新令牌？ 编辑： build议的OAuth 2.0规范指出： 颁发刷新令牌是可选的，由授权服务器决定。 如果授权服务器发出刷新令牌，则在发出访问令牌时将包含该令牌 由于我正在接收访问令牌，但没有刷新令牌，并且由于ADFS当前仅实现OAuth的代码stream，所以我的猜测是ADFS团队select不返回刷新令牌。 尽pipe如此，我很乐意听到这个消息。 编辑：像特拉维斯下面说的，确保 RP的IssueOAuthRefreshTokensTo设置正确 RP的AlwaysRequireAuthentication为false RP的TokenLifetime低于ADFS的SSOLifetime
我正在configuration服务提供商以使用SSO身份validation。 我将为此使用AD FS 2.0。 什么是我需要给IdP的SAML Assertion Consumer的URL？ 我认为这可能是这样的事情之一： https://abc.com/adfs/ls/ https://abc.com/_trust/ 但我不确定。 有任何想法吗？
默认情况下，ADFS 3响应包含“X-Frame-Options：DENY”HTTP标头。 这可以防止ADFS在iframe中运行，因为这提供了点击劫持攻击的机会。 目前我的公司正在实现一个集成，这个安全规则应该是一个例外：某个域上的页面应该能够将ADFSembedded到iframe中。 但似乎ADFS不允许改变这个开箱即用的方式。 那么修改这个HTTP头的最好方法是什么？ 例如RFC（ https://tools.ietf.org/html/rfc7034#section-2.3.2.3 ）中所build议的？ 想要在帧中呈现所请求的内容的页面将其自己的起源信息提供给提供要经由查询string参数成帧的内容的服务器。 服务器validation主机名是否符合其标准，以便允许页面被目标资源框起。 例如，这可以通过查找被允许构build页面的可信域名白名单来实现。 例如，对于Facebook的“Like”button，服务器可以检查提供的主机名是否与该“Like”button所期望的主机名匹配。 如果在步骤＃2中符合适当的条件，则服务器返回“X-Frame-Options：ALLOW-FROM”中的主机名。 浏览器强制执行“X-Frame-Options：ALLOW-FROM”标题。
我已经将us.mycompany.local中的所有用户UPN后缀的公司名称更改为mycompany.com，以便使用声明感知的应用程序。 在更改之前的testing中，我发现即使更改了UPN后缀，用户也可以使用旧的后缀成功进行身份validation。 我不明白的是为什么这仍然有效。
我刚刚实施了一个ADFS服务器，通过SAML 2.0将第三方聊天工具与我们的Active Directory连接起来。 一切正常，但有一个小问题：只要用户login，聊天工具自动为他创build一个帐户。 这是一个问题，因为每个帐户都会产生费用。 有没有办法将ADFS的使用限制在AD组中？
所以我被告知我们的PHP应用程序可能需要支持使用ADFS的身份validation。 对于一个非微软的人来说，什么是ADFS？ 它与LDAP之类的东西有什么不同？ 它是如何工作的？ 在ADFS服务器的典型请求中将包含哪些types的信息？ 它是否为authentication和授权而devise？ ADFS服务器通常可以从互联网访问（而公司AD域控制器不会）？ 我已经尝试阅读一些Technet文档，但它充满了微软，说这不是很有帮助。 维基百科更好（见下文），但也许一些ServerFault社区可以填补一些空白。 Active Directory联合身份validation服务（ADFS）是由Microsoft开发的一种软件组件，可安装在Windows Server操作系统上，为用户提供跨组织边界的系统和应用程序的单一login访问。 它使用基于声明的访问控制授权模型来维护应用程序安全性并实施联合身份。 基于声明的身份validation是基于关于包含在受信任的令牌中的身份的一组声明来对用户进行身份validation的过程。 在ADFS中，通过build立两个安全领域之间的信任，在两个组织之间build立联合身份。 一侧的联合服务器（帐户侧）通过Active Directory域服务中的标准方法对用户进行身份validation，然后发出包含一系列关于用户的声明（包括其身份）的令牌。 另一方面，资源方面，另一个联邦服务器validation令牌，并为本地服务器发出另一个令牌来接受声明的身份。 这允许系统向属于另一安全领域的用户提供对其资源或服务的受控访问，而不要求用户直接向系统authentication，也不需要两个系统共享用户身份或密码的数据库。 在实践中，这种方法通常被用户认为如下： 用户login到他们的本地PC（正如他们通常在早上开始工作时那样） 用户需要获取合作伙伴公司的外联网网站上的信息，例如获取定价或产品详细信息 用户导航到合作伙伴公司的外部网站 – 例如： http ： //example.com 合作伙伴网站现在不需要键入任何密码，而是使用AD FS将用户凭据传递给合作伙伴Extranet站点 用户现在login到合作伙伴网站，并可以与网站“login” 从https://en.wikipedia.org/wiki/Active_Directory_Federation_Services
从这个问题分离出来： 我真的需要MS Active Directory吗？ 在2014年新的方向。 考虑到基本的Windows基础结构： 域控制器 Exchange 2007/2010/2013 的SharePoint SQL 文件服务器/打印服务器 AD集成DNS ADauthentication的第三方设备（比如802.1X用于networking连接，也可能是一些内容过滤等） AD / LDAP在IT应用程序/硬件等上validation了“pipe理”function。 也许一些KMS的东西 如果你愿意，可以投入CA. 家庭应用程序 第三方内部应用程序 现在，让我们把所有的东西全部搞定，并决定我们要去云端。 我们已经签约将Exchange / Sharepoint /文件服务迁移到Office 365中。现在，SQL也将托pipe在Azure之类的东西上。 我们已经不再需要AD-DNS，只需通过一个简单的Windows DNS服务器就可以运行所有的事情。 我们仍然需要802.1X，如果可能的话，也希望SSO能够用于我们的各种云应用。 本土和第三方内部应用程序可能会停留，但有能力使用内部用户数据库，而不是ADauthentication 问题是…我们真的需要Active Directory吗？ 或者更重要的是，AD内部部署，甚至通过Azure或类似的（ADFS）托pipe，或通过Azure或类似的方式在托pipe的虚拟机上运行ADDS。 我们是否可以/我们应该看看像第三方SSO选项，如http://www.onelogin.com/partners/app-partners/office-365/或类似的，可以提供SSOfunction，即使它是一样简单LastPass或类似的每个用户？ 如果云中的其他东西都能满足AD的合理需求， 如果一个以MS为中心的基础设施能够将以前依赖于AD的所有东西移动到不依赖于AD身份validation的SaaS产品中，那么它们是否可以摆脱？