Re: [Freeipa-users] IPA-server and conrainers
On Wed, Jun 11, 2014 at 07:41:11AM +0600, Arthur Fayzullin wrote: Running IPA as a bunch of containers can reduce size of each one. Of Possibly. But FreeIPA is currently configured using ipa-server-install and there is no support in the installer for having / assuming the individual components on different hosts (be it containters or true hosts). That's why the initial effort goes into moving what we have with ipa-server-install to container as one block. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External collaboration edits
On Sat, Jun 07, 2014 at 09:21:29PM +, Nordgren, Bryce L -FS wrote: Dimitri, thanks for the reply! Pls forgive my lateness. I fear I am not currently up to fighting with MS Outlook to convince it to let me respond inline. It wants to block quote your entire message and if I type in the middle it keeps the quoted style. In any case: #1] Making small things work first and accumulating functionality is definitely the way to go. If it were simple and straightforward, everyone would be doing it already. #2] I looked at views (Ticket 3979 as well as http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust). I think I follow most of it (a default view which applies to the whole domain, custom views which may be applied to particular targets). +1 +1 +1. One concern I have is that the design page seems to be written around a single upstream source (trust with AD). What happens if there are many upstreams? All in all, though, it sounds like my current RFE is a duplicate of views. If we could add in my use case to the Views ticket/design, we can close mine out. It's not only about AD, but use-case and examples in the design page currently all refer to AD. The key is to find a unique reference to the upstream object which in the AD case is obviously the SID. In a previous version of the page there were a bit more details who the original/upstream objects can be referenced, e.g. it can a fully qualified name or Kerberos principal. bye, Sumit #3] Kerberos based auto provisioning will fall apart if the authentication path cannot be walked by the client (not the FreeIPA server). When I'm sitting in my office, I can see my KDC as well as the collaboration environment, and I can walk the path. However, if I cannot convince my CIO to poke a hole in the firewall so that FreeIPA in the collaboration domain can get to the internal AD (to query attributes, etc), then an AD trust is not possible and a vanilla Kerberos trust is all that is available. Kerberos-trust based auto-provisioning may be able to handle situations that AD trusts can't. By and large, I need my boxes to know my username, and could care less if they know my givenName, sn, mail, telephoneNumber, etc. As long as FreeIPA can synthesize a uidNumber for me in the absence of an SID, the rest is gravy. #4] One user/Many Accounts. This is an unavoidable reality. Also, there's a namespace collision issue here. My Kerberos cname@crealm is bnordg...@ds.fs.fed.usmailto:bnordg...@ds.fs.fed.us as issued from my AD. My SAML uid is bnordgren@fs from https://www.eauth.usda.gov/Login/login.aspx. My Google OpenID is bnordgren from wherever. There is also a bnordgren from a university out of SLC, Utah. I occasionally get mis-addressed email for him. Typically spam, but once from his mom. Fundamentally, whenever multiple domains are consolidated into a single namespace (as is already a use case for views), one typically tries to avoid username collisions just as vigilantly as they try to avoid uidNumber collisions. What is needed here is a method for the users to override the default collision avoidance such that they allow all of their accounts to be mapped onto their One True Username for the domain. In the spirit of point #1, implementing collision avoidance will be require! d for views, so it needs to happen now even without external collaboration. Figuring out how to let users override it can happen in the future. Bryce From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal Sent: Wednesday, May 14, 2014 4:13 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] External collaboration edits On 04/19/2014 07:46 PM, Nordgren, Bryce L -FS wrote: I've run out of time for today, but the external collaboration pages are slowly evolving. http://www.freeipa.org/page/External_Users_in_IPA Dimitri observed that my RFE page was too long. I observe it also has too much stuff unrelated to the actual meat of the RFE. So I factored out most of the Kerberos stuff into a different page. I also tried to focus the RFE to just creating entries in LDAP for external users so they can: a] participate in POSIX groups; and b] have locally-defined POSIX attributes. http://www.freeipa.org/page/Collaboration_with_Kerberos This is where all the Kerberos stuff went. I also added in Option A from Petr's email. Option B will come along later, when I pick this up again. Mechanism three has more to do with Ipsilon than IPA, and basic functions required of the Ipsilon gateway server are articulated there (regardless of the particular authentication method.) Send comments to the list. I really appreciate Option A! Send more stuff I didn't think of. Hello, I finally read the pages, sorry for the delay. great writeup! Here are some comments. 1) You are right that we need to
Re: [Freeipa-users] Getting Samba3 and FreeIPAv3 working together
Hi Sumit, Thanks for your reply. I shall await the fruits of Alexander's labour over the summer with interest. It seems that it's all so close to working and would be great for an organisation in our situation with a mixed Samba/NFS Linux/Windows environment. Do you think the work on compatibility will be for Samba 3, 4 or both? I need to look at the slapi-nis functionality anyway as the current feeling is that we need to get the NFS side of things working with as little user pain as possible and that Samba will have to go onto the back-burner for now. I'll come back with anything new I find. As RHEL7 has just been released I'm going to have to rebuild my test environment anyway... Thanks for your help so far, Dylan. On 4 June 2014 14:47, Sumit Bose sb...@redhat.com wrote: On Tue, Jun 03, 2014 at 03:37:05PM +0100, Dylan Evans wrote: Hello again, Just realised by re-reading this thread that I still needed to create the DNA plugin. I've now done that and I can add users, sorry for being stupid... I think the issue is on my side :-) I forgot that samba uses a hardcoded LDAP schema and requires specific objectclass and attribute names. By enabling the DNA plugin the needed values are added to the user object, but with the negative side effect that there are now two attributes containing a different SID, one create by the DNA plugin the other by a plugin activated by ipa-adtrust-install. I guess the proper solution would be to not enable the DNS plugin to create the SIDs in the user object but use the Schema Compatibility plugin from slapi-nis to create a compat tree where samba can find the needed data with the expected schema. But I'm afraid I am not aware of any howto about this. Even better would be to use ipasam instead of ldapsam in samba itself. But I cannot say how good or bad it will currently work because as mentioned below Alexander is planning to check it in summer. bye, Sumit Dylan. On 3 June 2014 14:44, Dylan Evans devan...@gmail.com wrote: Hi Petr Sumit, I've been trying to get further with my setup. 1. Thanks Petr, the groups.js plugin seems to work fine, it shows the correct info on the GUI screen and seems to be ok. 2. Sumit, I'm afraid that I'm having a few more problems after running ipa-adtrust-install --add-sids. I cannot now add any users on the server (Fedora 20, ipa-server 3.3.5-1) via the command-line or GUI. I get the following error: GUI: IPA Error 4205 missing attribute: sambaSID required by object class sambaSamAccount Command-line: ipa user-add test1234 . ipa: ERROR: missing attribute sambaSID required by object class sambaSamAccount Also, when editing an existing user, there is no sambaSID field available to edit. If you have any ideas, please let me know. Thanks, Dylan. On 26 May 2014 11:40, Petr Vobornik pvobo...@redhat.com wrote: On 23.5.2014 16:31, Dylan Evans wrote: Hi Sumit and Petr, Thanks both of you for your replies, I've now got to go and try to implement all your suggestions but I have some more questions, sorry! The guide at techslaves was fine, I just got stuck with the changes in the JavaScript packages and the Samba server questions. 1. Petr, I put your samba.js plugin into /usr/share/ipa/ui/js/plugins/samba but you'll have to pardon my lack of JS knowledge, anything more than simple Bash scripts tends to leave me confused! Do I need to do anything else apart from restart the IPA service? I read your info at http://pvoborni.fedorapeople.org/doc/#!/guide/Plugins which says the plugins have to be registered, but I couldn't work out if it's a manual process or if it's done by /usr/share/ipa/wsgi/plugins.py on restart? I'll add the relevant bits to /usr/share/ipa/wsgi/plugins.py for the CLI as well. Should be automatically handled by the plugin.py wsgi handler and related logic in Web UI. Just make sure that the file and the directory have same names (except the extension in file's case of course). 2. Sumit, thanks for the info on Samba, I'll have to leave that now and try it next week. BTW, the version of Samba I'm testing against is 3.6.9-168 on CentOS 6.5. Thanks again for your information and patience, Dylan. On 22 May 2014 14:19, Petr Vobornik pvobo...@redhat.com wrote: On 22.5.2014 14:19, Sumit Bose wrote: On Tue, May 20, 2014 at 02:00:18PM +0100, Dylan Evans wrote: Hello, I need some help with getting Samba and FreeIPA working together. I’ve been following the guide at http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration but that seems quite out of date for IPAv3 and I need some help: yes, it is a bit outdated but still useful. Please note that we are currently working on making the integration of samba more easy. Recently I send a patch to the samba-technical mailing list with a library which would allow samba to use SSSD
