[Freeipa-users] Trust Issues W/ Logins on Windows Desktops

[Alexander Bokovoy]

On Thu, 01 Oct 2015, Simo Sorce wrote:
>On 01/10/15 03:15, Petr Spacek wrote:
>>On 30.9.2015 20:36, Matt Wells wrote:
>>>Hi all, I hoped I may glean some brilliance from the group.
>>>I have a Freeipa Server sitting atop a Fedora 21 server.  The initial plan
>>>was to replicate users+passwords with Windows 2012R2 server but following
>>>some of the information in the other posts and docs we've moved to a
>>>trust.  The trust has been setup using the documentation and in short it's
>>>worked without issue.  I'm able to get principles from the Windows realm (
>>>marvel.comics.com).  So what I'm attempting and failing to do is
>>>authenticating my IPA users to the Windows 8 desktops.  Ideally I don't
>>>want any users in AD, it's simply there to deliver a GPO and in the next
>>>year it will be phased out and we'll be replacing Windows 8 with linux
>>>desktops.
>>>
>>>So
>>>marvel.comics.com = windows
>>>dc.comics.com = freeipa
>>>
>>># rpm -qi freeipa-server
>>>Name        : freeipa-server
>>>Version     : 4.1.4
>>>Release     : 1.fc21
>>>Architecture: x86_64
>>>Install Date: Tue 25 Aug 2015 08:17:56 PM UTC
>>>Group       : System Environment/Base
>>>Size        : 4521059
>>>License     : GPLv3+
>>>Signature   : RSA/SHA256, Thu 26 Mar 2015 10:58:02 PM UTC, Key ID
>>>89ad4e8795a43f54
>>>Source RPM  : freeipa-4.1.4-1.fc21.src.rpm
>>>Build Date  : Thu 26 Mar 2015 03:16:19 PM UTC
>>>Build Host  : buildhw-07.phx2.fedoraproject.org
>>>[root at freeipaServer slapd-DEV-MOSAIC451-COM]# uname -a
>>>Linux freeipaServer.dc.comics.com 4.1.6-100.fc21.x86_64 #1 SMP Mon Aug 17
>>>22:20:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>[root at freeipaServer slapd-DEV-MOSAIC451-COM]# cat /etc/redhat-release
>>>Fedora release 21 (Twenty One)
>>>
>>>To cut to the chase here's me logging into a Windows 8 desktop system.  I
>>>try to login 3 different ways; this system is a member of the marvel
>>>domain.  Time is extremely close, close enough that I feel really good
>>>about ruling it out.  Any light you all could shed on this would be
>>>outstanding.  Thank you all for your time on this, I really appreciate all
>>>the time and effort this team puts into reading these posts.
>>>
>>>Username: dc/greenlantern
>>>Password: ************
>>>
>>>[root at freeipaServer slapd-DC-COMICS-COM]# tail -f * | egrep --color -i
>>>greenlantern
>>>[30/Sep/2015:17:55:33 +0000] conn=1172 op=46 SRCH
>>>base="dc=dc,dc=comics,dc=com" scope=2
>>>filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc
>>>)(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName
>>>krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey
>>>krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration
>>>krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange
>>>krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth
>>>krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences
>>>krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock
>>>passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink
>>>objectClass"
>>>
>>>Username: greenlanter at dc
>>>Password: ************
>>>
>>>
>>>[30/Sep/2015:17:59:48 +0000] conn=1172 op=86 SRCH
>>>base="dc=dc,dc=comics,dc=com" scope=2
>>>filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc
>>>)(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName
>>>krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey
>>>krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration
>>>krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange
>>>krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth
>>>krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences
>>>krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock
>>>passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink
>>>objectClass"
>>>
>>>
>>>Username: greenlanter at dc.comics.com
>>>Password: ************
>>>
>>>[30/Sep/2015:17:59:35 +0000] conn=1172 op=84 SRCH
>>>base="dc=dc,dc=comics,dc=com" scope=2
>>>filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern\5C at dc.COMICS.com
>>>@DC.COMICS.COM <http://dc.comics.com/>
>>>)(krbPrincipalName=greenlantern\5C at dc.COMICS.com@DC.COMICS.COM
>>><http://dc.comics.com/>)))" attrs="krbPrincipalName krbCanonicalName
>>>ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference
>>>krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference
>>>krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases
>>>krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData
>>>krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife
>>>krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData
>>>ipaUserAuthType ipatokenRadiusConfigLink objectClass"
>>>
>>>
>>>>From what I can tell, everything looks good to wbinfo; we see the domain
>>>and he see's us.  In the AD trust I can go under the trust and validate the
>>>trust with no issues.
>>>[root at freeipaServer slapd-MARVEL-COMICS-COM]#  wbinfo --online-status
>>>BUILTIN : online
>>>DC : online
>>>MARVEL : online
>>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info
>>>marvel.comics.com
>>>Name              : MARVEL
>>>Alt_Name          : marvel.comics.com
>>>SID               : S-1-5-21-3495301974-2766379234-3984916731
>>>Active Directory  : Yes
>>>Native            : Yes
>>>Primary           : No
>>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo -n
>>>'MARVEL.COMICS.COM\Domain
>>>Admins'
>>>S-1-5-21-3495301974-2766379234-3984916731-512 SID_DOM_GROUP (2)
>>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info
>>>marvel.comics.com
>>>Name              : MARVEL
>>>Alt_Name          : marvel.comics.com
>>>SID               : S-1-5-21-3495301974-2766379234-3984916731
>>>Active Directory  : Yes
>>>Native            : Yes
>>>Primary           : No
>>
>>Unfortunately you will not be able to log into Windows workstations using IPA
>>users because FreeIPA is (at the moment) missing Global Catalog component
>>which prevents Windows from working with IPA users.
>>
>>It should work the other way around, but there is nothing you can do at the
>>moment to make it working with IPA users in Windows. Global Catalog is several
>>months away in the best case.
>
>This is not entirely true.
>There is no way to add IPA SIDs to the relevant authorization groups 
>using the GUI tools in AD, but technically you can do that using 
>command line tools and pasting in SIDs directly.
>Authentication would be possible then, however Windows clients will 
>never be able to resolve SID to Names, so looking at file permissions 
>you will not be able to see user names, but only SIDs for IPA users.
>Some tools that may depend on SID->Name translation may also fail in 
>unexpected ways.
practically, you will not be able to login into Windows workstations
because login screen will have to do Name->SID translation which it
wouldn't be able to do.

>This is why we do not recommend to try this, but it is technically 
>possible if you know very well how to handle everything through 
>Windows CLIs (I don't so don't ask :-)
It will not work for Name->SID translations, thus making it practially
unusable.
-- 
/ Alexander Bokovoy