<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 01/14/2014 05:23 PM, Nordgren, Bryce L -FS wrote: <blockquote cite="mid:82E7C9A01FD0764CACDD35D10F5DFB6E66C358@001FSN2MPN1-044.001f.mgd2.msft.net" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">I'm unaware of other mechanisms that would give you the same flexibility and level of privilege separation between the AD and IPA domains. </pre> </blockquote> <pre wrap=""> ?? 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 </pre> </blockquote> 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: <a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/V3/OTP">http://www.freeipa.org/page/V3/OTP</a>. 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" <pre>ipa config-mod --user-auth-type=radius </pre> 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. <a class="moz-txt-link-freetext" href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html</a> 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. <blockquote cite="mid:82E7C9A01FD0764CACDD35D10F5DFB6E66C358@001FSN2MPN1-044.001f.mgd2.msft.net" type="cite"> <pre wrap=""> 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 <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-users">https://www.redhat.com/mailman/listinfo/freeipa-users</a> </pre> </blockquote> <pre class="moz-signature" cols="72">-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? <a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a> </pre> </body> </html>