[Freeipa-users] Joining a Windows Workstation to an IPA realm (It works better than expected!)

[Alexander Bokovoy]

On Fri, 20 Sep 2013, Dmitri Pal wrote:
>On 09/20/2013 11:01 AM, Alexander Bokovoy wrote:
>> On Fri, 20 Sep 2013, Loris Santamaria wrote:
>>> Hi all,
>>>
>>> yesterday I was going to try puppet on windows, so I fired up a Windows
>>> 7 VM, and just for curiosity, instead of joining it to the AD realm, i
>>> decided to try the instructions outlined in the wiki to join the machine
>>> to the IPA realm:
>>> http://www.freeipa.org/page/Windows_authentication_against_FreeIPA
>>>
>>> So I went with the instructions, on the windows Workstation.
>>>
>>> ksetup /setdomain [REALM NAME]
>>> ksetup /addkdc [REALM NAME] [kdc DNS name]
>>> ksetup /addkpassword [REALM NAME] [kdc DNS name]
>>> ksetup /setcomputerpassword [MACHINE_PASSWORD] (the one used above)
>>> ksetup /mapuser * *
>>>
>>> Next, the instructions tell you to create Windows local users
>>> corresponding to the IPA kerberos realm users, because you know,
>>> kerberos only does authentication and it can tell nothing to the windows
>>> workstation about the identity of the user... However, just for kicks, I
>>> rebooted the VM and _without creating any local user_ I tried to login
>>> with myuser at IPA.REALM … And it worked! It created a profile directory,
>>> showed my full name on the start menu. Then I tried to browse the web
>>> and SSO with squid worked like a charm, SSO with putty worked and I even
>>> logged in to the IPA administration page with my ticket.
>>>
>>> But it wasn't supposed to work without creating a local user... why it
>>> was working then?
>>>
>>> Please notice this, the IPA realm has a trust with the AD realm, so
>>> samba 4 is running on the IPA servers and every user in the IPA realm
>>> has a SID assigned... and its ticket comes with a PAC, I think that is
>>> the important part.
>> Exactly. You actually don't need to create the trust, just run
>> ipa-adtrust-install to make sure IPA's infrastructure is configured to
>> issue SIDs and accept them.
>>
>>>
>>> Finally, what worked and what don't:
>>>
>>>      * I was able to login on Win 7 with an IPA user and having a local
>>>        profile created automatically
>>>      * I was able to perform SSO authentication with IPA services
>>>      * I was able to add my IPA user to the "Administrators" group in
>>>        windows, with the NET LOCALGROUP command.
>>>      * I couldn't add the IPA "admins" group to the "Administrators"
>>>        group. With "NET LOCALGROUP Administrators IPA\admins /add" it
>>>        tells me that it doesn't recognise the IPA\admins group.
>> Right, because it doesn't know where to look up translation between
>> IPA\admins string and SID as you haven't really configured Windows PC to
>> be part of the domain and IPA domain doesn't provide services Windows PC
>> expect to be there by default for resolving user/group to SIDs in Active
>> Directory.
>>
>>>      * I couldn't add other IPA users to the Administrators group, only
>>>        my logged in user.
>> Same here.
>>
>>>      * I can't add IPA users to group with the graphical administration
>>>        tools, they won't show the IPA realm, only the NET command
>>>        worked somehow
>> Same here. Windows UIs rely on AD global catalog service which we don't
>> implement.
>>
>>
>>> I'm investigating why Windows can't see IPA users and group other than
>>> the currently logged in user, but I suspect that is simply because
>>> Windows takes the logged in user SID from the PAC and it doesn't really
>>> talk to samba4.
>> Yep, only that it doesn't know where to talk as there is no proper
>> service available.
>>
>>
>Loris,
>
>This is a great input! Thanks for investigation, it is really helpful!
>
>Alexander,
>
>So when we add GC support in IPA how would the picture change?
For AD domains trusted by IPA, this would solve all problems stated
above (they are the same for both in-domain and out-of-domain Windows
PCs). For out-of-domain Windows PC I'd like to see some network traces
to identify whether it tries to search for a GC server associated with
the Kerberos domain or not. If it does, we can be closer to the
solution. If not, then a local mapping will have to happen somehow.


-- 
/ Alexander Bokovoy