[Freeipa-users] One way trusts

Wed Jan 15 00:29:06 UTC 2014

On 01/14/2014 05:23 PM, Nordgren, Bryce L -FS wrote:
>> Both AD integration solutions we have (synchronization and
>> cross-forest domain trusts) assume having higher level access
>> privileges at the time integration is set up.
> My problem here is that I'm too ignorable. :) There's over 15000 users in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD is being absorbed into the next level up the chain (Forest Service AD is going to become a part of the overall USDA AD). Then I'm an even smaller fish, relatively speaking.
>
>> I'm unaware of other
>> mechanisms that would give you the same flexibility and level of
>> privilege separation between the AD and IPA domains.
> ?? The current solution using the LDAP interface to AD (and a metadirectory to merge "external users") provides privilege separation and the flexibility to add external users. I don't need more; I just need it to be less clunky. It weakens security, of course, as my AD password is stored in various plaintext configuration files for each application needing binding credentials to search for users in AD. I also have an index to which files contain my password, as it forms a "password-change-checklist" which I need to run thru every 60 days.
>
> If I might try to repeat the problem back to you to see if I got it right...the factor which requires access to the corporate AD is setting up a Kerberos cross realm trust. This is required so that machines in IPA can connect directly to AD for authentication. This in turn is necessary so that identities in the AD Kerberos Realm are correctly and consistently identified as being sourced from AD. And of course, this requirement is necessary for services in AD to recognize users and groups in AD.
>
> Let me ask what is probably a series of dumb questions: What do I lose if my FreeIPA server is set up as one of the 10 machines I can join to the network as a regular user, and all the machines in IPA connect directly to IPA? Could FreeIPA (current or future) be configured to relay the credentials to AD either via Kerberos or using AD's LDAP interface (binding as itself because it's joined to the AD domain)?  If AD accepts the provided credentials can FreeIPA issue the user a ticket in the FreeIPA realm? Would this look to AD like a bunch of users are logging into the FreeIPA server machine?
>
> I know this arrangement would sacrifice access to any of the AD services by AD-users-on-the-IPA network. That's fine. If it's technically feasible, tho, it gives me one server that can authenticate both "corporate users" and "external users", and a central administration point for the external network. It also plainly differentiates between corporate users logged in on the corporate network, and corporate users logged in on the "external network". I'd consider that a good thing. Finally, if this is possible, it seems to me that this stands a chance of reducing the number of places my password is stored in plaintext.
>
> Bryce
>
You might be able to do one of the following hacks. I am saying hack
because no one tried to do it and it might not work and hit some bugs
and issues.

1) Use pam proxy capability. If you bind to IPA DS via LDAP you can
configure users to authenticate using pam proxy feature of DS and via
pam point to AD. This has limitation that it works only for LDAP binds
but not for kerberos so your clients would be deprived off SSO.
Alternatively you can separate external and internal users. Internal
users would be able to do LDAP only while external users since they
would be stored in IPA would be able to do both. AFAIU this is not what
you want.
2) IPA in 3.3 uses compat tree to present AD data to legacy clients and
allow bind to that tree. This is just LDAP so has similar limitations. I
suspect it would also rely on the presence of trust to be able to bind
to AD but I am not sure. Alexander, CCed would have more details to
share for this case.
3) Finally the grand hack that actually might work. IPA 3.3 and 3.4 that
is being worked on have OTP support. You will setup winsync to sync AD
users (one way from AD), you will make sure that these users can't be
modified in IPA via permissions and ACIs so that you do not get into the
situation when users become different in IPA and AD. Since you own IPA
you will have full control so this part is really up to you. When users
are synced in you will add a way of setting additional attributes for
the synced in users. I am not sure if this can be done without adding a
DS or Winsync plugin but I think it would not be a lot of code for you
to do (may be there is a trick that I do not know that might be done to
avoid writing a plugin, see below). As a result the synced in users will
have following attributes set:
**ipatokenRadiusConfigLink - this attribute should point to a RADIUS
server configuration object. There will be one such object (see below).
All synced in users will point to its DN via this attribute.
ipaUserAuthTypeClass - this attribute should specify that the user
should use RADIUS for his authentication. I.e. the value should be "radius".
Corresponding object classes that these attributes belong to should
already be a part of user object by default in 3.4 (Nathaniel?)
Now back to plugin. Since all the synced users will have the same values
for these two attributes it might be possible to avoid writing a plugin.
I just do not know how.

Now you add the RADIUS object via UI or CLI. You actually do it first
before setting up winsync. Some hints can be found here:
http://www.freeipa.org/page/V3/OTP. The RADIUS configuration should
point to some RADIUS server. If there is a RADIUS server in your
organization you might point to it. Otherwise you can setup FreeRADIUS
and use its LDAP or pam configuration to do an LDAP bind against AD.

You can then add "external" users  as normal IPA users without setting
any extra attributes for them.
It might be possible to avoid writing a plugin by actually not setting
anything for synced users, defining a global ipaUserAuthTypeClass as
"radius" and defining ipaUserAuthTypeClass as "passord" for any manually
added external user. However I am not sure if that would work (I suspect
there might be a bug there). Nathaniel, when you set global policy to
"radius"

ipa config-mod --user-auth-type=radius

which radius configuration would it pick? How would it work?

So let us assume that the bug is not there and things would work. Let me
summarize my thinking...

1) Install IPA
2) Install RADIUS server, configure it to authenticate against AD
3) Add RADIUS server configuration to IPA using 'ipa radiusproxy-add'
command
4) Set ipaUserAuthTypeClass attribute to 'password' for your admin user.
You can do it using 'ipa user-mod ... --setattr...' command. If you do
not do it I suspect you lock yourself out by the next step.
5) Set global IPA policy 'ipa config-mod --user-auth-type=radius' - that
will force all users without ipaUserAuthTypeClass explicitly set to
authenticate using RADIUS.
6) Setup one way winsync agreement with AD (that might require some
tweaking of the winsync configuration, Rich?). Follow docs.
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html
7) Always set ipaUserAuthTypeClass to 'password' when you add users (you
can probably wrap 'ipa user-add' command with a specific shell script to
always add it in your case.

That seems to be it. External and internal users would be able to
authenticate using kerberos while internal users will use their AD
passwords but it will be IPA that would issue the tickets.

I suggest you start will latest bits from a nightly repo as I know there
have been bug fixes in this area that are not released yet.

>
>
>
>
> This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140114/6911f0cd/attachment.htm>