目前,我的域名由MS AD管理,由独立的组控制.假设由于政治原因,改变MS AD中的任何内容将变得困难或不可能.
对于Linux,我最近配置系统使用MS AD直接提供的Kerberos密码身份验证,在Enterprise Linux上使用SSSD.身份信息仍在本地系统上提供.
我现在最大的困难是弄清楚如何提出新的域名空间.
我可以使用MS AD域的子域并将其控制委托给FreeIPA吗？
我认为可能需要让Kerberos配置直接指向MS AD,它已经非常有弹性,为什么不利用现有的基础设施呢？但是这会比我的价值更麻烦吗？我不确定事情会如何整合.
考虑到这一点：
我们的主机命名标准类似于“app-id-dev / prd.domain.com”.例如：“server01dev.domain.com”
根据策略,我们不会在dev / prd环境之间复制服务器ID,因此我认为使用子域的一种很好的方法是将前面的示例转换为“server01.dev.domain.com”.一个很好的功能是,当指定主机的短名称时,如果我们的域搜索顺序在客户端上正确设置,我们将不再需要指定dev / prd.
感知优势：这将允许我成为这些子域的CA.这应该简化任何与之相关的证书.
感知缺点：这对认证意味着什么？我仍然希望用户使用原始域中已存在的用户名进行身份验证.示例：user0321@DOMAIN.COM不是user0321@DEV.DOMAIN.COM
我的另一个疑问是,直接使用MS AD Kerberos是否有任何意义,因为如果FreeIPA LDAP无法提供身份信息,它仍然会阻止用户正常登录,除非他们在客户端系统上具有本地身份.
如果这是一个真正的问题,它让我想知道是否可以将FreeIPA LDAP信息与AD同步,但我认为用户必须在子域中创建.
或者,我是否应该抛弃任何直接使用MS AD来实现弹性的概念,并接受我需要创建一个弹性的FreeIPA / RH IdM环境？
解决方法
FreeIPA应该是来自Active Directory的单独Kerberos领域,并且应该使用与Krb5领域相对应的单独DNS区域.如果您的AD域使用带有子区域“dev”和“prd”的DNS区域“domain.com”,您可能希望创建一个名为“idm.domain.com”的新DNS区域,以及下面的任何子域它.您可能希望创建一个名为“IDM.DOMAIN.COM”的Krb5领域,所有UPN为USER@IDM.DOMAIN.COM,所有SPN为HOST / SERVER123.IDM.DOMAIN.COM等(可能是WWW / SERVER123. PRD.IDM.DOMAIN.COM).
您可以使用与AD相同的DNS区域,但这是一个非常糟糕的主意.您不仅使用DNS丢失服务发现,还必须进行手动映射,并且可能难以解决客户端尝试传递不适合IdM领域中服务器的Krb令牌的问题
您至少需要与AD团队合作,让他们设置跨域信任.他们可能希望它是单向信任,其中AD是可信域,FreeIPA是信任域.在大多数情况下,这应该不是问题.
目前,RHEL 7附带的FreeIPA版本不支持与forest-apex AD域建立信任,并且向下遍历子域以进行身份验证.我在RHEL 7u1中被告知,这将得到补救,因为可传递信任支持将被添加到FreeIPA,但是在我在代码冻结后一天看到功能列表之前,我并没有屏住呼吸.作为解决方法,您应该能够将信任设置到用户主体所在的子域.
我正在做类似的努力.祝你好运,让我们知道这是如何运作的.我很幸运能够将AD团队作为我团队中的一个元素(他们坐在我对面).我们在团队层面(团队规模的单位)汇集到同一个领导者,我们得到了我们的部门负责人的大力支持,他们希望看到这种集成成功.
