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

Simo Sorce simo at redhat.com
Thu Oct 1 16:08:08 UTC 2015


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.
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 :-)

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-users mailing list