From Steven.Jones at vuw.ac.nz Sun Oct 2 20:11:56 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 2 Oct 2011 20:11:56 +0000 Subject: [Freeipa-users] backing up and restoring the backend In-Reply-To: <1317389281.15918.255.camel@willson.li.ssimo.org> References: <833D8E48405E064EBC54C84EC6B36E404461A1D5@STAWINCOX10MBX1.staff.vuw.ac.nz> , <20110929213446.GD12370@zeppelin.brq.redhat.com> <833D8E48405E064EBC54C84EC6B36E404461A233@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E84ECD6.1020900@redhat.com> <833D8E48405E064EBC54C84EC6B36E404461A2B5@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1317389281.15918.255.camel@willson.li.ssimo.org> Message-ID: <833D8E48405E064EBC54C84EC6B36E404461D77A@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, "save a copy of the disk image" When you have 500 servers and the average is 90gb that's a bit of a space problem to copy multiple images of.....but VMWare can clone live.....you dont have to switch off. Also for management purposes you want one way to back everything up or you cant scale your backup system/capability..... Snapshots are really like db logs its not something you leave for long because of the disk space impacts and disk i/o impacts, you also cant live migrate VMs while a snapshot is in place....I'd be surprised in LVM is more effective/efficient than VMWare in this respect..... If the backupdb.pl gives me a sane export into a flat file that is fine....many dbs are done that way anyway, its very unlikely it will ever be needed. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Simo Sorce [simo at redhat.com] Sent: Saturday, 1 October 2011 2:28 a.m. To: Steven Jones Cc: dpal at redhat.com; freeipa-users at redhat.com; Deon Lackey Subject: Re: [Freeipa-users] backing up and restoring the backend On Thu, 2011-09-29 at 22:58 +0000, Steven Jones wrote: > VM? > > VMWare snapshot? > > VMWare snapshots are best described as spawn of the devil, they should > have a life of 2 or 3 days max.... I use KVM so I can't tell how good/bad VMWare fares in this regard, but I didn't mean VM snapshot, sorry if I was unclear. I literally meant you turn off the VM and save a copy of the disk image. It may not be the most efficient way of course, and you can also simply use normal backup software with disaster recovery functionality. As long as it is able to properly deal with dirsrv database it should be fine. > One of my next Qs was what else needs backing up....however I assumed > that everything else outside the database is simple to back up.....its > just "files" > > or is this not the case? Everything but dirsrv databases is just files, that is correct. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Sun Oct 2 22:40:44 2011 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 02 Oct 2011 18:40:44 -0400 Subject: [Freeipa-users] backing up and restoring the backend In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404461D77A@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404461A1D5@STAWINCOX10MBX1.staff.vuw.ac.nz> , <20110929213446.GD12370@zeppelin.brq.redhat.com> <833D8E48405E064EBC54C84EC6B36E404461A233@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E84ECD6.1020900@redhat.com> <833D8E48405E064EBC54C84EC6B36E404461A2B5@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1317389281.15918.255.camel@willson.li.ssimo.org> <833D8E48405E064EBC54C84EC6B36E404461D77A@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E88E86C.9010900@redhat.com> On 10/02/2011 04:11 PM, Steven Jones wrote: > Hi, > > "save a copy of the disk image" > > When you have 500 servers and the average is 90gb that's a bit of a space problem to copy multiple images of.....but VMWare can clone live.....you dont have to switch off. Also for management purposes you want one way to back everything up or you cant scale your backup system/capability..... > > Snapshots are really like db logs its not something you leave for long because of the disk space impacts and disk i/o impacts, you also cant live migrate VMs while a snapshot is in place....I'd be surprised in LVM is more effective/efficient than VMWare in this respect..... > > If the backupdb.pl gives me a sane export into a flat file that is fine....many dbs are done that way anyway, its very unlikely it will ever be needed. > Number of servers is orthogonal to the goal in this scenario. You need to backup one or couple IPA replicas. You do not need to back up all IPA replicas and clients. This should not be a big impact on your storage capacities. You are welcome to try to create a backup script for IPA but we decided to back away from this effort as it is a much bigger effort that might seem on the surface. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Simo Sorce [simo at redhat.com] > Sent: Saturday, 1 October 2011 2:28 a.m. > To: Steven Jones > Cc: dpal at redhat.com; freeipa-users at redhat.com; Deon Lackey > Subject: Re: [Freeipa-users] backing up and restoring the backend > > On Thu, 2011-09-29 at 22:58 +0000, Steven Jones wrote: >> VM? >> >> VMWare snapshot? >> >> VMWare snapshots are best described as spawn of the devil, they should >> have a life of 2 or 3 days max.... > I use KVM so I can't tell how good/bad VMWare fares in this regard, but > I didn't mean VM snapshot, sorry if I was unclear. > > I literally meant you turn off the VM and save a copy of the disk image. > > It may not be the most efficient way of course, and you can also simply > use normal backup software with disaster recovery functionality. > As long as it is able to properly deal with dirsrv database it should be > fine. > >> One of my next Qs was what else needs backing up....however I assumed >> that everything else outside the database is simple to back up.....its >> just "files" >> >> or is this not the case? > Everything but dirsrv databases is just files, that is correct. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ondrejv at s3group.cz Mon Oct 3 08:03:12 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Mon, 03 Oct 2011 10:03:12 +0200 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E896C40.3010004@s3group.cz> Just wondering why would anyone want to sync freeIPA and AD - both can serve Linux systems fine, so if I already have AD, I no longer require IPA. My 2 cents... Ondrej On 09/29/2011 10:35 PM, Steven Jones wrote: > Hi, > > In the documentation it says that new accounts in AD are syncd over to freeIPA, so IPA sets the UID as it "arrives"? > > What happens if the user is an existing one and has a UID they want to retain, does that transfer over and get used? > > Also how do you set permissions and groups? does the new user just go into a default group and then you login to freeIPA and set them up? or can you put the GIDs into AD and they get transferred and the user put into the "right" groups" automagically? > > Looks like I can set this sort of thing "how I want" in the sync agreement? > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chorn at fluxcoil.net Mon Oct 3 06:08:08 2011 From: chorn at fluxcoil.net (Christian Horn) Date: Mon, 3 Oct 2011 08:08:08 +0200 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <4E896C40.3010004@s3group.cz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E896C40.3010004@s3group.cz> Message-ID: <20111003060808.GA29863@fluxcoil.net> On Mon, Oct 03, 2011 at 10:03:12AM +0200, Ondrej Valousek wrote: > Just wondering why would anyone want to sync freeIPA and AD - both > can serve Linux systems fine, so if I already have AD, I no longer > require IPA. - the error messages of an AD might be strange to deal with for unix/linux admins - While I expect Microsoft to test AD patches with Windows clients I do not expect them to test linux/unix clients. Resulting in possi- bility that patches of the AD break the communication to linux/unix clients. - Having important infrastructure like idendification/directory services running on OpenSource software is a good thing, apply all the OpenSource advantages here like beeing able to audit the code etc. Christian From ondrejv at s3group.cz Mon Oct 3 10:45:36 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Mon, 03 Oct 2011 12:45:36 +0200 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <20111003060808.GA29863@fluxcoil.net> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E896C40.3010004@s3group.cz> <20111003060808.GA29863@fluxcoil.net> Message-ID: <4E899250.8080304@s3group.cz> Well, I think these advantages won't outweigh the extra complexity of having two systems for the same thing. But it is up to everyone's decision... Ondrej > - the error messages of an AD might be strange to deal with for > unix/linux admins > > - While I expect Microsoft to test AD patches with Windows clients > I do not expect them to test linux/unix clients. Resulting in possi- > bility that patches of the AD break the communication to linux/unix > clients. > > - Having important infrastructure like idendification/directory services > running on OpenSource software is a good thing, apply all the OpenSource > advantages here like beeing able to audit the code etc. > > > Christian The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Mon Oct 3 12:07:29 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 03 Oct 2011 08:07:29 -0400 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <4E896C40.3010004@s3group.cz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E896C40.3010004@s3group.cz> Message-ID: <1317643650.2366.11.camel@sgallagh520.bos.redhat.com> On Mon, 2011-10-03 at 10:03 +0200, Ondrej Valousek wrote: > Just wondering why would anyone want to sync freeIPA and AD - both can > serve Linux systems fine, so if I already have AD, I no longer require > IPA. > My 2 cents... AD can serve Linux systems with a very limited definition of "fine". All support in Active Directory for POSIX compliance is an afterthought to Microsoft. It exists solely to try and migrate customers from UNIX to Windows, and really isn't designed for the purpose. One of the major problems with using AD for Linux support is that it violates the LDAP and Kerberos standards in several key places, meaning that the experience on Linux is significantly degraded from that of Windows machines. For example, in order to support very large group memberships (>1000 members), Active Directory requires the use of a special LDAP control to retrieve the members list a page at a time in several LDAP communications. The way it does this is expressly violating the LDAP protocol standard, which means that without rewriting all clients on Linux to break the standard in the same way, Linux and UNIX machines are capable of only seeing the first thousand members of a group. Another problem with Active Directory is its limited support for LDAP authentication. AD expects that all of its clients are Windows machines, and therefore capable of using Kerberos and/or NTLM for all authentication. However, some applications (especially Linux-powered web applications) can only authenticate using LDAP simple bind authentication. While AD does have some support for this, LDAP auth breaks completely in the case of expired users (it has no support for a password-change grace period with LDAP authentication). Yet further, in many environments, there are two very different organizations in the IT departments: one group that manages Windows systems and one that manages Linux/UNIX systems. By having FreeIPA be capable of acting as a bridge between the two (either by the current mechanism of user-syncing or by the forthcoming FreeIPA v3 mechanism of Kerberos trusted realms), it allows IT departments to continue to hire staff that knows one system well. It's very hard to find people with a deep knowledge of both systems; people tend to specialize. It's much better to let your Linux admins work on the Linux machines, rather than trying to force your MCSEs to learn the intricacies of a LAMP setup. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From simo at redhat.com Mon Oct 3 12:07:58 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 03 Oct 2011 08:07:58 -0400 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <4E899250.8080304@s3group.cz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E896C40.3010004@s3group.cz> <20111003060808.GA29863@fluxcoil.net> <4E899250.8080304@s3group.cz> Message-ID: <1317643678.17819.6.camel@willson.li.ssimo.org> Ondrej, it depends on your company structure, complexity and goals and flexibility. If you join your Linux machines to an AD directory then you are tied very strictly, administratively and functionally to that directory. Given Windows Administration and Linux Administration are very diverse skills set, and very few admins are capable of doing both with maximum proficiency on both system we think that splitting your support organization between the Windows admin and Linux admins is a good thing. Each group can concentrate on its own tasks w/o too much interference and less need for coordinating. Also FreeIPA is targeted at serving Linux machines and has integrated HBAC, Sudo support and other goodies that are simply missing in the AD side as they are alien concepts in the Windows world. Of course small organization were a single admin group controlling both platfroms may decide having just one directory is the way to go. You have the freedom to choose. Simo. On Mon, 2011-10-03 at 12:45 +0200, Ondrej Valousek wrote: > Well, I think these advantages won't outweigh the extra complexity of > having two systems for the same thing. > But it is up to everyone's decision... > > Ondrej > > > - the error messages of an AD might be strange to deal with for > > unix/linux admins > > > > - While I expect Microsoft to test AD patches with Windows clients > > I do not expect them to test linux/unix clients. Resulting in possi- > > bility that patches of the AD break the communication to linux/unix > > clients. > > > > - Having important infrastructure like idendification/directory services > > running on OpenSource software is a good thing, apply all the OpenSource > > advantages here like beeing able to audit the code etc. > > > > > > Christian > > > ______________________________________________________________________ > The information contained in this e-mail and in any attachments is > confidential and is designated solely for the attention of the > intended recipient(s). If you are not an intended recipient, you must > not use, disclose, copy, distribute or retain this e-mail or any part > thereof. If you have received this e-mail in error, please notify the > sender by return e-mail and delete all copies of this e-mail from your > computer system(s). Please direct any additional queries to: > communications at s3group.com. Thank You. Silicon and Software Systems > Limited (S3 Group). Registered in Ireland no. 378073. Registered > Office: South County Business Park, Leopardstown, Dublin 18 > > ______________________________________________________________________ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From ondrejv at s3group.cz Mon Oct 3 12:45:02 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Mon, 03 Oct 2011 14:45:02 +0200 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <1317643678.17819.6.camel@willson.li.ssimo.org> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E896C40.3010004@s3group.cz> <20111003060808.GA29863@fluxcoil.net> <4E899250.8080304@s3group.cz> <1317643678.17819.6.camel@willson.li.ssimo.org> Message-ID: <4E89AE4E.5070409@s3group.cz> Hi Simo, Stephen, I agree that in larger organisations there might be a need to keep both systems separate. In our case (~300 users) AD works just fine - but true is that apart of the identity & password management we require nothing else. That's said I appreciate your hard work and support even for the scenario below. I also hope that you won't dislike me if I continue to bombard you with questions/problems regarding Linux/Windows interoperability. :-) Eventually, even Microsoft has its own bright moments - last time they surprised me when I contacted microsoft support reporting that their LDAP servers (AD controllers) responds to connections via SASL/MD5 auth the way which breaks RFC (I could not get Linux automounter to work with AD). They admitted the bug and unveiled a patch for it. Ondrej On 10/03/2011 02:07 PM, Simo Sorce wrote: > Ondrej, > it depends on your company structure, complexity and goals and > flexibility. > > If you join your Linux machines to an AD directory then you are tied > very strictly, administratively and functionally to that directory. > Given Windows Administration and Linux Administration are very diverse > skills set, and very few admins are capable of doing both with maximum > proficiency on both system we think that splitting your support > organization between the Windows admin and Linux admins is a good thing. > > Each group can concentrate on its own tasks w/o too much interference > and less need for coordinating. > Also FreeIPA is targeted at serving Linux machines and has integrated > HBAC, Sudo support and other goodies that are simply missing in the AD > side as they are alien concepts in the Windows world. > > Of course small organization were a single admin group controlling both > platfroms may decide having just one directory is the way to go. You > have the freedom to choose. > > Simo. > > On Mon, 2011-10-03 at 12:45 +0200, Ondrej Valousek wrote: >> Well, I think these advantages won't outweigh the extra complexity of >> having two systems for the same thing. >> But it is up to everyone's decision... >> >> Ondrej >> >>> - the error messages of an AD might be strange to deal with for >>> unix/linux admins >>> >>> - While I expect Microsoft to test AD patches with Windows clients >>> I do not expect them to test linux/unix clients. Resulting in possi- >>> bility that patches of the AD break the communication to linux/unix >>> clients. >>> >>> - Having important infrastructure like idendification/directory services >>> running on OpenSource software is a good thing, apply all the OpenSource >>> advantages here like beeing able to audit the code etc. >>> >>> >>> Christian >> >> ______________________________________________________________________ >> The information contained in this e-mail and in any attachments is >> confidential and is designated solely for the attention of the >> intended recipient(s). If you are not an intended recipient, you must >> not use, disclose, copy, distribute or retain this e-mail or any part >> thereof. If you have received this e-mail in error, please notify the >> sender by return e-mail and delete all copies of this e-mail from your >> computer system(s). Please direct any additional queries to: >> communications at s3group.com. Thank You. Silicon and Software Systems >> Limited (S3 Group). Registered in Ireland no. 378073. Registered >> Office: South County Business Park, Leopardstown, Dublin 18 >> >> ______________________________________________________________________ >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbingram at gmail.com Mon Oct 3 18:45:22 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Mon, 3 Oct 2011 11:45:22 -0700 Subject: [Freeipa-users] ipa user/group-mod --setattr can't remove objectclass Message-ID: I've successfully used ipa user-mod --setattr to remove custom attributes that I've added by simply setting the attribute equal to nothing. However, it does not work in the case of objectclasses since there are several and the command does not support multiple arguments. I've seen references to --delattr in older v1 documentation. Obviously, this could be easily accomplished with an ldapmodify command, but it would be nice to have directly in ipa. Is this already supported and I simply don't know the correct command? Steve From rcritten at redhat.com Mon Oct 3 18:48:46 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 03 Oct 2011 14:48:46 -0400 Subject: [Freeipa-users] ipa user/group-mod --setattr can't remove objectclass In-Reply-To: References: Message-ID: <4E8A038E.6020402@redhat.com> Stephen Ingram wrote: > I've successfully used ipa user-mod --setattr to remove custom > attributes that I've added by simply setting the attribute equal to > nothing. However, it does not work in the case of objectclasses since > there are several and the command does not support multiple arguments. > I've seen references to --delattr in older v1 documentation. > Obviously, this could be easily accomplished with an ldapmodify > command, but it would be nice to have directly in ipa. Is this already > supported and I simply don't know the correct command? > > Steve There is currently not a delattr equivalent in v2 though we are looking into it. What you'd need to do is a setattr with the full list of objectclasses you want it to be set to. This will replace the current value(s). rob From sbingram at gmail.com Mon Oct 3 18:58:12 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Mon, 3 Oct 2011 11:58:12 -0700 Subject: [Freeipa-users] ipa user/group-mod --setattr can't remove objectclass In-Reply-To: <4E8A038E.6020402@redhat.com> References: <4E8A038E.6020402@redhat.com> Message-ID: Rob- I tried that, but I couldn't figure out the correct format: ipa user-mod --setattr=objectclass=oc1, oc2, oc3 ipa user-mod --setattr=objectclass=oc1 oc2 oc3 ipa user-mod --setattr=objectclass=oc1, objectclass=oc2, objectclass=oc3 and some others. Nothing seemed to work all reporting that multiple arguments were not supported. Steve On Mon, Oct 3, 2011 at 11:48 AM, Rob Crittenden wrote: > Stephen Ingram wrote: >> >> I've successfully used ipa user-mod --setattr to remove custom >> attributes that I've added by simply setting the attribute equal to >> nothing. However, it does not work in the case of objectclasses since >> there are several and the command does not support multiple arguments. >> I've seen references to --delattr in older v1 documentation. >> Obviously, this could be easily accomplished with an ldapmodify >> command, but it would be nice to have directly in ipa. Is this already >> supported and I simply don't know the correct command? >> >> Steve > > There is currently not a delattr equivalent in v2 though we are looking into > it. > > What you'd need to do is a setattr with the full list of objectclasses you > want it to be set to. This will replace the current value(s). > > rob > From rcritten at redhat.com Mon Oct 3 19:05:39 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 03 Oct 2011 15:05:39 -0400 Subject: [Freeipa-users] ipa user/group-mod --setattr can't remove objectclass In-Reply-To: References: <4E8A038E.6020402@redhat.com> Message-ID: <4E8A0783.8050602@redhat.com> Stephen Ingram wrote: > Rob- > > I tried that, but I couldn't figure out the correct format: > > ipa user-mod --setattr=objectclass=oc1, oc2, oc3 > > ipa user-mod --setattr=objectclass=oc1 oc2 oc3 > > ipa user-mod --setattr=objectclass=oc1, objectclass=oc2, objectclass=oc3 > > and some others. Nothing seemed to work all reporting that multiple > arguments were not supported. This should work ipa user-mod --setattr=objectclass=oc1 --addattr=objectclass=oc2 --addattr=objectclass=oc3 ... rob > > Steve > > On Mon, Oct 3, 2011 at 11:48 AM, Rob Crittenden wrote: >> Stephen Ingram wrote: >>> >>> I've successfully used ipa user-mod --setattr to remove custom >>> attributes that I've added by simply setting the attribute equal to >>> nothing. However, it does not work in the case of objectclasses since >>> there are several and the command does not support multiple arguments. >>> I've seen references to --delattr in older v1 documentation. >>> Obviously, this could be easily accomplished with an ldapmodify >>> command, but it would be nice to have directly in ipa. Is this already >>> supported and I simply don't know the correct command? >>> >>> Steve >> >> There is currently not a delattr equivalent in v2 though we are looking into >> it. >> >> What you'd need to do is a setattr with the full list of objectclasses you >> want it to be set to. This will replace the current value(s). >> >> rob >> From Steven.Jones at vuw.ac.nz Mon Oct 3 20:51:44 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 3 Oct 2011 20:51:44 +0000 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <4E896C40.3010004@s3group.cz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E896C40.3010004@s3group.cz> Message-ID: <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Just how many Linux desktops and servers do you have? sure with say 5 or so linux and if you dont care about security its easy to AD ie access no authorisation...however I cant see any method to manage large quantities of Linux via AD without expensive addon tools. I have 200+servers and 250 linux desktops and growing.....cant manage those with local access with 1.5 admins....you also cant manage them with AD unless you buy centrify/likewise or quest software or similar and thats very expensive and a pain in the ass. Unless Ive missed something? Now looking a IPA its management interface is simple, usable, yet very powerful....AD for Linux and its brain dead simple, and i have whats known as "useradmins" they ad users, they are not IT capable.... So it takes us in excess of a day to add an admin to the servers, 5 mins in IPA....the time saving is substantial. We have disparate groups so a single lookup for an AD group isnt going to do it. "Just wondering why would anyone want to sync freeIPA and AD" As per usual ppl cant think of real life situations where such things are necessary, well its known as life its sometimes complex and messy. I work in a predominantly Windows environment. So I have windows architects, windows security ppl, windows derived managers, windows derived directors and (mostly) windows admins. They simply dont understand linux/unix, dont care, and would like it removed to make their life "simple" and cheaper. Also I manage 30% of our environment and the most mission critical on Linux and it rarely falls over. The clients love it, and I do it with 1.5 linux staff v 9 windows admins. Clients now ask for linux servers from choice....Im getting under windows ppls skin. It makes my day. ;] So I need to work in such a framework/constraint and have a workable and no cost solution. My need to sync with AD is becasue we provision to AD, so if I can pull a lot of data across it means less resistance from the Windows trained identity ppl, the security ppl and the managers. Tis simple, they will happily spend $50k on a AD review and $500k on an identity system that hasnt worked in 3 years but wont spend $5k on linux LDAP.....so I have to fight battles with little....makes winning sweeter.... :) regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Ondrej Valousek [ondrejv at s3group.cz] Sent: Monday, 3 October 2011 9:03 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Question on AD to freeipa sync Just wondering why would anyone want to sync freeIPA and AD - both can serve Linux systems fine, so if I already have AD, I no longer require IPA. My 2 cents... Ondrej On 09/29/2011 10:35 PM, Steven Jones wrote: Hi, In the documentation it says that new accounts in AD are syncd over to freeIPA, so IPA sets the UID as it "arrives"? What happens if the user is an existing one and has a UID they want to retain, does that transfer over and get used? Also how do you set permissions and groups? does the new user just go into a default group and then you login to freeIPA and set them up? or can you put the GIDs into AD and they get transferred and the user put into the "right" groups" automagically? Looks like I can set this sort of thing "how I want" in the sync agreement? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ________________________________ The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 ________________________________ From Steven.Jones at vuw.ac.nz Mon Oct 3 20:53:37 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 3 Oct 2011 20:53:37 +0000 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <1317643650.2366.11.camel@sgallagh520.bos.redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E896C40.3010004@s3group.cz>, <1317643650.2366.11.camel@sgallagh520.bos.redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40446209F4@STAWINCOX10MBX1.staff.vuw.ac.nz> exactly......... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Stephen Gallagher [sgallagh at redhat.com] Sent: Tuesday, 4 October 2011 1:07 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Question on AD to freeipa sync On Mon, 2011-10-03 at 10:03 +0200, Ondrej Valousek wrote: > Just wondering why would anyone want to sync freeIPA and AD - both can > serve Linux systems fine, so if I already have AD, I no longer require > IPA. > My 2 cents... AD can serve Linux systems with a very limited definition of "fine". All support in Active Directory for POSIX compliance is an afterthought to Microsoft. It exists solely to try and migrate customers from UNIX to Windows, and really isn't designed for the purpose. One of the major problems with using AD for Linux support is that it violates the LDAP and Kerberos standards in several key places, meaning that the experience on Linux is significantly degraded from that of Windows machines. For example, in order to support very large group memberships (>1000 members), Active Directory requires the use of a special LDAP control to retrieve the members list a page at a time in several LDAP communications. The way it does this is expressly violating the LDAP protocol standard, which means that without rewriting all clients on Linux to break the standard in the same way, Linux and UNIX machines are capable of only seeing the first thousand members of a group. Another problem with Active Directory is its limited support for LDAP authentication. AD expects that all of its clients are Windows machines, and therefore capable of using Kerberos and/or NTLM for all authentication. However, some applications (especially Linux-powered web applications) can only authenticate using LDAP simple bind authentication. While AD does have some support for this, LDAP auth breaks completely in the case of expired users (it has no support for a password-change grace period with LDAP authentication). Yet further, in many environments, there are two very different organizations in the IT departments: one group that manages Windows systems and one that manages Linux/UNIX systems. By having FreeIPA be capable of acting as a bridge between the two (either by the current mechanism of user-syncing or by the forthcoming FreeIPA v3 mechanism of Kerberos trusted realms), it allows IT departments to continue to hire staff that knows one system well. It's very hard to find people with a deep knowledge of both systems; people tend to specialize. It's much better to let your Linux admins work on the Linux machines, rather than trying to force your MCSEs to learn the intricacies of a LAMP setup. From sbingram at gmail.com Tue Oct 4 05:03:33 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Mon, 3 Oct 2011 22:03:33 -0700 Subject: [Freeipa-users] ipa user/group-mod --setattr can't remove objectclass In-Reply-To: <4E8A0783.8050602@redhat.com> References: <4E8A038E.6020402@redhat.com> <4E8A0783.8050602@redhat.com> Message-ID: Rob- I think this works. I'm not totally sure because I keep getting strange schema violation errors. Perhaps it is the way each --setattr option is evaluated by the directory. I'm going to have to dig deeper to find out. Needless to say thought, a --delattr option would make it much easier to say quickly remove an objectclass or one of a list of email addresses. Steve On Mon, Oct 3, 2011 at 12:05 PM, Rob Crittenden wrote: > Stephen Ingram wrote: >> >> Rob- >> >> I tried that, but I couldn't figure out the correct format: >> >> ipa user-mod --setattr=objectclass=oc1, oc2, oc3 >> >> ipa user-mod --setattr=objectclass=oc1 oc2 oc3 >> >> ipa user-mod --setattr=objectclass=oc1, objectclass=oc2, objectclass=oc3 >> >> and some others. Nothing seemed to work all reporting that multiple >> arguments were not supported. > > This should work > > ipa user-mod --setattr=objectclass=oc1 --addattr=objectclass=oc2 > --addattr=objectclass=oc3 ... > > rob > >> >> Steve >> >> On Mon, Oct 3, 2011 at 11:48 AM, Rob Crittenden >> ?wrote: >>> >>> Stephen Ingram wrote: >>>> >>>> I've successfully used ipa user-mod --setattr to remove custom >>>> attributes that I've added by simply setting the attribute equal to >>>> nothing. However, it does not work in the case of objectclasses since >>>> there are several and the command does not support multiple arguments. >>>> I've seen references to --delattr in older v1 documentation. >>>> Obviously, this could be easily accomplished with an ldapmodify >>>> command, but it would be nice to have directly in ipa. Is this already >>>> supported and I simply don't know the correct command? >>>> >>>> Steve >>> >>> There is currently not a delattr equivalent in v2 though we are looking >>> into >>> it. >>> >>> What you'd need to do is a setattr with the full list of objectclasses >>> you >>> want it to be set to. This will replace the current value(s). >>> >>> rob >>> > > From ondrejv at s3group.cz Tue Oct 4 07:32:17 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 04 Oct 2011 09:32:17 +0200 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E896C40.3010004@s3group.cz> <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E8AB681.5080103@s3group.cz> I have ~50 servers and yes, we are using Centrify now - and yes, it is pain in the ass (need to take care of the licenses). But I have found out recently that sssd can do much of the Centrify's duty (authorization & authentication) - well, it is not so polished, but it seems to work well. Ondrej On 10/03/2011 10:51 PM, Steven Jones wrote: > I have 200+servers and 250 linux desktops and growing.....cant manage those with local access with 1.5 admins....you also cant manage them with AD unless you buy centrify/likewise or quest software or similar and thats very expensive and a pain in the ass. > The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Duncan.Innes at virginmoney.com Tue Oct 4 10:42:07 2011 From: Duncan.Innes at virginmoney.com (Duncan.Innes at virginmoney.com) Date: Tue, 4 Oct 2011 11:42:07 +0100 Subject: [Freeipa-users] Roadmap Update Message-ID: Hi, Is there any chance someone could do a quick update to the Roadmap? I can see from the devel mailing list that there's lots of work going on, but I'm not able to decipher a higher level direction in which things are going. An updated roadmap would help understand the direction of the project. Many thanks Duncan This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money do not accept responsibility for changes made to any e-mail after sending. Virgin Money have swept, and believe this e-mail to be free of viruses and profanity but make no guarantees to this effect. Virgin Money Personal Financial Service Ltd is authorised and regulated by the Financial Services Authority. Registered in England no. 3072766. Entered on the Financial Services Authority's Register http://www.fsa.gov.uk/register/. Register Number 179271. The Virgin Deposit Account and the Virgin Cash ISA are both personal deposit accounts with Virgin Bank Ltd administered by Virgin Money Personal Financial Service Ltd. Virgin Bank Ltd is authorised and regulated by the Financial Services Authority. Registered in England no. 980698. Entered on the Financial Services Authority's Register http://www.fsa.gov.uk/register/. Register Number 204459. Virgin Money Unit Trust Managers Ltd is authorised and regulated by the Financial Services Authority. Registered in England no. 3000482. Entered on the Financial Services Authority's Register. Register Number 171748. Virgin Money Ltd. Registered in England no. 4232392. Introducer appointed representative only of Virgin Money Personal Financial Service Ltd. Virgin Money Management Services Ltd. Registered in England no.3072772. Virgin Money Holdings (UK) Limited. Registered in England no.3087587. All the above companies have their Registered office at Discovery House, Whiting Road, Norwich NR4 6EJ. All products are open only to residents of the United Kingdom. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Tue Oct 4 12:09:28 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 04 Oct 2011 08:09:28 -0400 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <4E8AB681.5080103@s3group.cz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E896C40.3010004@s3group.cz> <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E8AB681.5080103@s3group.cz> Message-ID: <1317730169.2382.15.camel@sgallagh520.bos.redhat.com> On Tue, 2011-10-04 at 09:32 +0200, Ondrej Valousek wrote: > I have ~50 servers and yes, we are using Centrify now - and yes, it is > pain in the ass (need to take care of the licenses). > But I have found out recently that sssd can do much of the Centrify's > duty (authorization & authentication) - well, it is not so polished, > but it seems to work well. As the lead SSSD developer, I can't help but chime in here and ask what polish you'd like to see :) RFEs and bugs can be filed upstream at https://fedorahosted.org/sssd (Requires a Fedora account, you can get one at https://admin.fedoraproject.org/accounts) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From rcritten at redhat.com Tue Oct 4 12:52:59 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 04 Oct 2011 08:52:59 -0400 Subject: [Freeipa-users] ipa user/group-mod --setattr can't remove objectclass In-Reply-To: References: <4E8A038E.6020402@redhat.com> <4E8A0783.8050602@redhat.com> Message-ID: <4E8B01AB.3000107@redhat.com> Stephen Ingram wrote: > Rob- > > I think this works. I'm not totally sure because I keep getting > strange schema violation errors. Perhaps it is the way each --setattr > option is evaluated by the directory. I'm going to have to dig deeper > to find out. setattr are evaluated first, so the setattr wipes out objectclass and sets it to a single value. addattr then adds the other values. > > Needless to say thought, a --delattr option would make it much easier > to say quickly remove an objectclass or one of a list of email > addresses. Yes. rob > > Steve > > On Mon, Oct 3, 2011 at 12:05 PM, Rob Crittenden wrote: >> Stephen Ingram wrote: >>> >>> Rob- >>> >>> I tried that, but I couldn't figure out the correct format: >>> >>> ipa user-mod --setattr=objectclass=oc1, oc2, oc3 >>> >>> ipa user-mod --setattr=objectclass=oc1 oc2 oc3 >>> >>> ipa user-mod --setattr=objectclass=oc1, objectclass=oc2, objectclass=oc3 >>> >>> and some others. Nothing seemed to work all reporting that multiple >>> arguments were not supported. >> >> This should work >> >> ipa user-mod --setattr=objectclass=oc1 --addattr=objectclass=oc2 >> --addattr=objectclass=oc3 ... >> >> rob >> >>> >>> Steve >>> >>> On Mon, Oct 3, 2011 at 11:48 AM, Rob Crittenden >>> wrote: >>>> >>>> Stephen Ingram wrote: >>>>> >>>>> I've successfully used ipa user-mod --setattr to remove custom >>>>> attributes that I've added by simply setting the attribute equal to >>>>> nothing. However, it does not work in the case of objectclasses since >>>>> there are several and the command does not support multiple arguments. >>>>> I've seen references to --delattr in older v1 documentation. >>>>> Obviously, this could be easily accomplished with an ldapmodify >>>>> command, but it would be nice to have directly in ipa. Is this already >>>>> supported and I simply don't know the correct command? >>>>> >>>>> Steve >>>> >>>> There is currently not a delattr equivalent in v2 though we are looking >>>> into >>>> it. >>>> >>>> What you'd need to do is a setattr with the full list of objectclasses >>>> you >>>> want it to be set to. This will replace the current value(s). >>>> >>>> rob >>>> >> >> From ondrejv at s3group.cz Tue Oct 4 12:53:58 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 04 Oct 2011 14:53:58 +0200 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <1317730169.2382.15.camel@sgallagh520.bos.redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E896C40.3010004@s3group.cz> <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E8AB681.5080103@s3group.cz> <1317730169.2382.15.camel@sgallagh520.bos.redhat.com> Message-ID: <4E8B01E6.5000805@s3group.cz> Well, small things like sssd can not renew machine credentials / sssd can not detect local site automatically in AD domain (no "DC locator" implemented) / sssd can not detect/guess AD schema automatically / sssd won't configure the krb5 library for me. Support for group policies & central management & auditing (Centrify nicely fills the OperatingSystem attribute for me) would be also nice. Most of this is understandable as much of these requests are either AD-specific (hard to blame sssd here) or a RFE is already opened for such a functionality. Anyway, it is still a way better than the classic libnss_ldap.so. :-) Ondrej On 10/04/2011 02:09 PM, Stephen Gallagher wrote: > As the lead SSSD developer, I can't help but chime in here and ask what > polish you'd like to see:) > The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jzeleny at redhat.com Tue Oct 4 13:19:08 2011 From: jzeleny at redhat.com (Jan =?iso-8859-1?q?Zelen=FD?=) Date: Tue, 4 Oct 2011 15:19:08 +0200 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <4E8B01E6.5000805@s3group.cz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> <1317730169.2382.15.camel@sgallagh520.bos.redhat.com> <4E8B01E6.5000805@s3group.cz> Message-ID: <201110041519.11713.jzeleny@redhat.com> > Well, small things like sssd can not renew machine credentials Something like this is already registered as a bachelor's thesis and it should be done by the end of May. If you have any special requests or you want to know some details, write me a private email, I consult with the student on a regular basis. Jan > / sssd can > not detect local site automatically in AD domain (no "DC locator" > implemented) / sssd can not detect/guess AD schema automatically / sssd > won't configure the krb5 library for me. Support for group policies & > central management & auditing (Centrify nicely fills the OperatingSystem > attribute for me) would be also nice. > > Most of this is understandable as much of these requests are either > AD-specific (hard to blame sssd here) or a RFE is already opened for such > a functionality. > > Anyway, it is still a way better than the classic libnss_ldap.so. :-) > Ondrej > > On 10/04/2011 02:09 PM, Stephen Gallagher wrote: > > As the lead SSSD developer, I can't help but chime in here and ask what > > polish you'd like to see:) > > The information contained in this e-mail and in any attachments is > confidential and is designated solely for the attention of the intended > recipient(s). If you are not an intended recipient, you must not use, > disclose, copy, distribute or retain this e-mail or any part thereof. If > you have received this e-mail in error, please notify the sender by return > e-mail and delete all copies of this e-mail from your computer system(s). > Please direct any additional queries to: communications at s3group.com. Thank > You. > Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. > 378073. Registered Office: South County Business Park, Leopardstown, > Dublin 18 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From sgallagh at redhat.com Tue Oct 4 13:43:07 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 04 Oct 2011 09:43:07 -0400 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <4E8B01E6.5000805@s3group.cz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E896C40.3010004@s3group.cz> <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E8AB681.5080103@s3group.cz> <1317730169.2382.15.camel@sgallagh520.bos.redhat.com> <4E8B01E6.5000805@s3group.cz> Message-ID: <1317735789.2382.19.camel@sgallagh520.bos.redhat.com> On Tue, 2011-10-04 at 14:53 +0200, Ondrej Valousek wrote: > Well, small things like sssd can not renew machine credentials / As Jan said, this is being looked into. > sssd can not detect local site automatically in AD domain (no "DC > locator" implemented) / Can you provide more information here? We DO have support for automatic detection based on DNS SRV records. Does a "DC locator" use some other mechanism? > sssd can not detect/guess AD schema automatically I'm not sure what you mean by this? Do you mean you don't want to have to specify ldap_schema = rfc2307bis and have it instead auto-detected? That's trickier than it sounds. > / sssd won't configure the krb5 library for me. What features of the krb5 library do you mean? SSSD provides a locator plugin that manages several features of the krb5 library, including kinit and kpasswd. > Support for group policies & central management & auditing (Centrify > nicely fills the OperatingSystem attribute for me) would be also nice. > These are on our long-term roadmap. > Most of this is understandable as much of these requests are either > AD-specific (hard to blame sssd here) or a RFE is already opened for > such a functionality. > > Anyway, it is still a way better than the classic libnss_ldap.so. :-) That is certainly our goal :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jzeleny at redhat.com Tue Oct 4 13:55:24 2011 From: jzeleny at redhat.com (Jan =?iso-8859-1?q?Zelen=FD?=) Date: Tue, 4 Oct 2011 15:55:24 +0200 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <1317735789.2382.19.camel@sgallagh520.bos.redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E8B01E6.5000805@s3group.cz> <1317735789.2382.19.camel@sgallagh520.bos.redhat.com> Message-ID: <201110041555.30064.jzeleny@redhat.com> > On Tue, 2011-10-04 at 14:53 +0200, Ondrej Valousek wrote: > > Well, small things like sssd can not renew machine credentials / > > As Jan said, this is being looked into. > > > sssd can not detect local site automatically in AD domain (no "DC > > > > locator" implemented) / > > Can you provide more information here? We DO have support for automatic > detection based on DNS SRV records. Does a "DC locator" use some other > mechanism? > > > sssd can not detect/guess AD schema automatically > > I'm not sure what you mean by this? Do you mean you don't want to have > to specify ldap_schema = rfc2307bis and have it instead auto-detected? > > That's trickier than it sounds. > > > / sssd won't configure the krb5 library for me. > > What features of the krb5 library do you mean? SSSD provides a locator > plugin that manages several features of the krb5 library, including > kinit and kpasswd. Also some more are already scheduled for 1.8 release. See tickets 997-1001 > > Support for group policies & central management & auditing (Centrify > > nicely fills the OperatingSystem attribute for me) would be also nice. > > These are on our long-term roadmap. > > > Most of this is understandable as much of these requests are either > > AD-specific (hard to blame sssd here) or a RFE is already opened for > > such a functionality. > > > > Anyway, it is still a way better than the classic libnss_ldap.so. :-) > > That is certainly our goal :) -- Thank you Jan Zeleny Red Hat Software Engineer Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From ondrejv at s3group.cz Tue Oct 4 14:29:15 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 04 Oct 2011 16:29:15 +0200 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <1317735789.2382.19.camel@sgallagh520.bos.redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E896C40.3010004@s3group.cz> <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E8AB681.5080103@s3group.cz> <1317730169.2382.15.camel@sgallagh520.bos.redhat.com> <4E8B01E6.5000805@s3group.cz> <1317735789.2382.19.camel@sgallagh520.bos.redhat.com> Message-ID: <4E8B183B.5030808@s3group.cz> > Can you provide more information here? We DO have support for automatic > detection based on DNS SRV records. Does a "DC locator" use some other > mechanism? > Example AD domain CONTOSO.COM used on 3 sites - Prague,Cork, Dublin. I have machine in Prague and I want it to join CONTOSO.COM. Now if I used: dns_discovery_domain = contoso.com sssd would try to connect to any DC in the domain - even the one in Dublin, completely ignoring sites. I have to use: dns_discovery_domain = Prague._sites.contoso.com To force it to use Prague DCs only. My understanding is, that the "DC locator" tries to communicate with DC's first to determine local site and remote DC's are only used if no valid/working DC can be found in the local site (Prague in this case). > I'm not sure what you mean by this? Do you mean you don't want to have > to specify ldap_schema = rfc2307bis and have it instead auto-detected? > > That's trickier than it sounds. > well this is a really small one. I would say it would be perfectly sufficient to introduce something like: ldap_schema=msrfc2307bis which would be equivalent to: ldap_user_object_class = user ldap_group_object_class = group ldap_user_home_directory = unixHomeDirectory ldap_schema = rfc2307bis also, the ldap bind mechanism negotiation could be potentially improved, now I have to explicitly specify ldap_sasl_mech = GSSAPI otherwise sssd tries to use SASL/EXTERNAL which fails when communicating to AD controllers. > What features of the krb5 library do you mean? SSSD provides a locator > plugin that manages several features of the krb5 library, including > kinit and kpasswd. > The thing is that not all Linux apps are using sssd so we have to remember to configure /etc/krb5.conf. too. When using Centrify, all I need to do is: # adjoin contoso.com ..which takes care of everything - /etc/nsswitch.conf, krb5.conf, PAM modules, eeeverything. If I wanted to use sssd for the same job I have to: 1. configure (manually) /etc/samba/smb.conf 2. net ads join (- just to get machine creds) 3. configure (manually) sssd.conf 4. configure (manually) PAM modules 5. configure (manually) krb5.conf I understand that much of this is probably not sssd duty, but it would be helpful to have some script around which would do the same job. The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Tue Oct 4 14:47:40 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 04 Oct 2011 10:47:40 -0400 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <4E8B183B.5030808@s3group.cz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E896C40.3010004@s3group.cz> <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E8AB681.5080103@s3group.cz> <1317730169.2382.15.camel@sgallagh520.bos.redhat.com> <4E8B01E6.5000805@s3group.cz> <1317735789.2382.19.camel@sgallagh520.bos.redhat.com> <4E8B183B.5030808@s3group.cz> Message-ID: <1317739661.2382.21.camel@sgallagh520.bos.redhat.com> These are all great ideas, Ondrej. Would you mind opening RFE bugs for them? You can file them upstream at https://fedorahosted.org/sssd or in Red Hat Bugzilla https://bugzilla.redhat.com in the sssd component. On Tue, 2011-10-04 at 16:29 +0200, Ondrej Valousek wrote: > > > Can you provide more information here? We DO have support for automatic > > detection based on DNS SRV records. Does a "DC locator" use some other > > mechanism? > > > Example AD domain CONTOSO.COM used on 3 sites - Prague,Cork, Dublin. > I have machine in Prague and I want it to join CONTOSO.COM. Now if I > used: > > dns_discovery_domain = contoso.com > > sssd would try to connect to any DC in the domain - even the one in > Dublin, completely ignoring sites. > I have to use: > > dns_discovery_domain = Prague._sites.contoso.com > > To force it to use Prague DCs only. > My understanding is, that the "DC locator" tries to communicate with > DC's first to determine local site and remote DC's are only used if no > valid/working DC can be found in the local site (Prague in this case). > > > I'm not sure what you mean by this? Do you mean you don't want to have > > to specify ldap_schema = rfc2307bis and have it instead auto-detected? > > > > That's trickier than it sounds. > > > well this is a really small one. I would say it would be perfectly > sufficient to introduce something like: > > ldap_schema=msrfc2307bis > > which would be equivalent to: > > ldap_user_object_class = user > ldap_group_object_class = group > ldap_user_home_directory = unixHomeDirectory > ldap_schema = rfc2307bis > > also, the ldap bind mechanism negotiation could be potentially > improved, now I have to explicitly specify > > ldap_sasl_mech = GSSAPI > > otherwise sssd tries to use SASL/EXTERNAL which fails when > communicating to AD controllers. > > > What features of the krb5 library do you mean? SSSD provides a locator > > plugin that manages several features of the krb5 library, including > > kinit and kpasswd. > > > The thing is that not all Linux apps are using sssd so we have to > remember to configure /etc/krb5.conf. too. > When using Centrify, all I need to do is: > > # adjoin contoso.com > > ..which takes care of everything - /etc/nsswitch.conf, krb5.conf, PAM > modules, eeeverything. If I wanted to use sssd for the same job I have > to: > > 1. configure (manually) /etc/samba/smb.conf > 2. net ads join (- just to get machine creds) > 3. configure (manually) sssd.conf > 4. configure (manually) PAM modules > 5. configure (manually) krb5.conf > > I understand that much of this is probably not sssd duty, but it would > be helpful to have some script around which would do the same job. > > > ______________________________________________________________________ > The information contained in this e-mail and in any attachments is > confidential and is designated solely for the attention of the > intended recipient(s). If you are not an intended recipient, you must > not use, disclose, copy, distribute or retain this e-mail or any part > thereof. If you have received this e-mail in error, please notify the > sender by return e-mail and delete all copies of this e-mail from your > computer system(s). Please direct any additional queries to: > communications at s3group.com. Thank You. Silicon and Software Systems > Limited (S3 Group). Registered in Ireland no. 378073. Registered > Office: South County Business Park, Leopardstown, Dublin 18 > > ______________________________________________________________________ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From g17jimmy at gmail.com Tue Oct 4 14:50:01 2011 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 4 Oct 2011 10:50:01 -0400 Subject: [Freeipa-users] freeRADIUS? Message-ID: I've been searching and see a few references to freeRADIUS used with FreeIPA, but I don't see any substantial information on the subject. Is there a procedure to use FreeIPA with freeRADIUS? I have a standalone openldap/freeradius server that I would like to eliminate if possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Tue Oct 4 15:14:06 2011 From: jdennis at redhat.com (John Dennis) Date: Tue, 04 Oct 2011 11:14:06 -0400 Subject: [Freeipa-users] freeRADIUS? In-Reply-To: References: Message-ID: <4E8B22BE.8030500@redhat.com> On 10/04/2011 10:50 AM, Jimmy wrote: > I've been searching and see a few references to freeRADIUS used with > FreeIPA, but I don't see any substantial information on the subject. Is > there a procedure to use FreeIPA with freeRADIUS? I have a standalone > openldap/freeradius server that I would like to eliminate if possible. Integrating FreeRADIUS with IPA is on the long term roadmap. It's not as easy as one might imagine. The fundamental problem is that many of the RADIUS authentication methods require access to the user's cleartext password or hashes we feel are insecure. This presents a design issue for us to resolve, as such it has been pushed out. Refer to this chart for more information: http://deployingradius.com/documents/protocols/compatibility.html -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Tue Oct 4 15:29:31 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 04 Oct 2011 11:29:31 -0400 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <1317735789.2382.19.camel@sgallagh520.bos.redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E896C40.3010004@s3group.cz> <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E8AB681.5080103@s3group.cz> <1317730169.2382.15.camel@sgallagh520.bos.redhat.com> <4E8B01E6.5000805@s3group.cz> <1317735789.2382.19.camel@sgallagh520.bos.redhat.com> Message-ID: <1317742171.17819.33.camel@willson.li.ssimo.org> On Tue, 2011-10-04 at 09:43 -0400, Stephen Gallagher wrote: > > sssd can not detect local site automatically in AD domain (no "DC > > locator" implemented) / > > Can you provide more information here? We DO have support for > automatic > detection based on DNS SRV records. Does a "DC locator" use some other > mechanism? Windows domains list all servers in SRV records, but they have a deeper concept called "sites", where admins can tell which subset of controllers a client should use (local to them). In order to discover the right site you need to do additoinal CLDAP queries to AD at startup time to find out what is the site to use and then you can query site-specific DNS entries to find the list of DCs. This is more complex than what we have in current SSSD and is implemented in Samba's Winbind for example. Simo. > -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Oct 4 22:23:37 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Oct 2011 18:23:37 -0400 Subject: [Freeipa-users] Roadmap Update In-Reply-To: References: Message-ID: <4E8B8769.40306@redhat.com> On 10/04/2011 06:42 AM, Duncan.Innes at virginmoney.com wrote: > Hi, > > Is there any chance someone could do a quick update to the Roadmap? I > can see from the devel mailing list that there's lots of work going > on, but I'm not able to decipher a higher level direction in which > things are going. > = 3.0 Plans = * Beta by Christmas break * Release Feb-Mar -- 2012 * Release is time driven * Content: Cross Kerberos Trusts - Milestones start with "3.0 Trust" Core IPA enhancements - Milestones start with "3.0 Core" * Project is run is following month aligned sprints == Cross Kerberos Trusts == * Reasons: Support of mixed AD <-> IPA deployments Support of multiple IPA domains * Use cases: User is in AD; service is in IPA; user logs in against AD, gets ticket and then accesses IPA service. Same as above but IPA service then in tern needs to access other service on behalf of user (TGT forwarding) Same as above but IPA to IPA Authenticated AD user logs with SSO into Linux machine that is a part of IPA domain in the cloud over SSH. Etc. == Themes of the core 3.0 enhancements == * Support SELinux central management * Support SSH user key management * Add additional standard maps * UI enhancements and improvements * DNS improvements and better IP data handling * Performance of the admin interface = Beyond 3.0 = * Over trust use cases * Key management * User certificate management * SAML, OpenID, Oauth provider * External authentication integration (OTP) * Level of assurance * RADIUS > An updated roadmap would help understand the direction of the project. > > Many thanks > > Duncan > This e-mail is intended to be confidential to the recipient. If you > receive a copy in error, please inform the sender and then delete this > message. Virgin Money do not accept responsibility for changes made to > any e-mail after sending. Virgin Money have swept, and believe this > e-mail to be free of viruses and profanity but make no guarantees to > this effect. > > Virgin Money Personal Financial Service Ltd is authorised and > regulated by the Financial Services Authority. Registered in England > no. 3072766. Entered on the Financial Services Authority's Register > http://www.fsa.gov.uk/register/. Register Number 179271. > > The Virgin Deposit Account and the Virgin Cash ISA are both personal > deposit accounts with Virgin Bank Ltd administered by Virgin Money > Personal Financial Service Ltd. Virgin Bank Ltd is authorised and > regulated by the Financial Services Authority. Registered in England > no. 980698. Entered on the Financial Services Authority's Register > http://www.fsa.gov.uk/register/. Register Number 204459. > > Virgin Money Unit Trust Managers Ltd is authorised and regulated by > the Financial Services Authority. Registered in England no. 3000482. > Entered on the Financial Services Authority's Register. Register > Number 171748. > > Virgin Money Ltd. Registered in England no. 4232392. Introducer > appointed representative only of Virgin Money Personal Financial > Service Ltd. > > Virgin Money Management Services Ltd. Registered in England no.3072772. > > Virgin Money Holdings (UK) Limited. Registered in England no.3087587. > > All the above companies have their Registered office at Discovery > House, Whiting Road, Norwich NR4 6EJ. > > All products are open only to residents of the United Kingdom. > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Oct 5 01:06:24 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Oct 2011 21:06:24 -0400 Subject: [Freeipa-users] Roadmap Update In-Reply-To: <4E8B8769.40306@redhat.com> References: <4E8B8769.40306@redhat.com> Message-ID: <4E8BAD90.5000305@redhat.com> On 10/04/2011 06:23 PM, Dmitri Pal wrote: > On 10/04/2011 06:42 AM, Duncan.Innes at virginmoney.com wrote: >> Hi, >> >> Is there any chance someone could do a quick update to the Roadmap? >> I can see from the devel mailing list that there's lots of work >> going on, but I'm not able to decipher a higher level direction in >> which things are going. >> > > = 3.0 Plans = > > * Beta by Christmas break > * Release Feb-Mar -- 2012 > * Release is time driven > * Content: > Cross Kerberos Trusts - Milestones start with "3.0 Trust" > Core IPA enhancements - Milestones start with "3.0 Core" > * Project is run is following month aligned sprints > > == Cross Kerberos Trusts == > > * Reasons: > Support of mixed AD <-> IPA deployments > Support of multiple IPA domains > * Use cases: > User is in AD; service is in IPA; user logs in against AD, gets > ticket and then accesses IPA service. > Same as above but IPA service then in tern needs to access other > service on behalf of user (TGT forwarding) > Same as above but IPA to IPA > Authenticated AD user logs with SSO into Linux machine that is a > part of IPA domain in the cloud over SSH. > Etc. > I also created reports to easily select the relevant tickets. This one for trust work https://fedorahosted.org/freeipa/report/20 > == Themes of the core 3.0 enhancements == > > * Support SELinux central management > * Support SSH user key management > * Add additional standard maps > * UI enhancements and improvements > * DNS improvements and better IP data handling > * Performance of the admin interface And this one for core effort https://fedorahosted.org/freeipa/report/21 > > = Beyond 3.0 = > > * Over trust use cases > * Key management > * User certificate management > * SAML, OpenID, Oauth provider > * External authentication integration (OTP) > * Level of assurance > * RADIUS > >> An updated roadmap would help understand the direction of the project. >> >> Many thanks >> >> Duncan >> This e-mail is intended to be confidential to the recipient. If you >> receive a copy in error, please inform the sender and then delete >> this message. Virgin Money do not accept responsibility for changes >> made to any e-mail after sending. Virgin Money have swept, and >> believe this e-mail to be free of viruses and profanity but make no >> guarantees to this effect. >> >> Virgin Money Personal Financial Service Ltd is authorised and >> regulated by the Financial Services Authority. Registered in England >> no. 3072766. Entered on the Financial Services Authority's Register >> http://www.fsa.gov.uk/register/. Register Number 179271. >> >> The Virgin Deposit Account and the Virgin Cash ISA are both personal >> deposit accounts with Virgin Bank Ltd administered by Virgin Money >> Personal Financial Service Ltd. Virgin Bank Ltd is authorised and >> regulated by the Financial Services Authority. Registered in England >> no. 980698. Entered on the Financial Services Authority's Register >> http://www.fsa.gov.uk/register/. Register Number 204459. >> >> Virgin Money Unit Trust Managers Ltd is authorised and regulated by >> the Financial Services Authority. Registered in England no. 3000482. >> Entered on the Financial Services Authority's Register. Register >> Number 171748. >> >> Virgin Money Ltd. Registered in England no. 4232392. Introducer >> appointed representative only of Virgin Money Personal Financial >> Service Ltd. >> >> Virgin Money Management Services Ltd. Registered in England no.3072772. >> >> Virgin Money Holdings (UK) Limited. Registered in England no.3087587. >> >> All the above companies have their Registered office at Discovery >> House, Whiting Road, Norwich NR4 6EJ. >> >> All products are open only to residents of the United Kingdom. >> >> This message has been checked for viruses and spam by the Virgin >> Money email scanning system powered by Messagelabs. >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrejv at s3group.cz Wed Oct 5 08:02:35 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Wed, 05 Oct 2011 10:02:35 +0200 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <1317739661.2382.21.camel@sgallagh520.bos.redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E896C40.3010004@s3group.cz> <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E8AB681.5080103@s3group.cz> <1317730169.2382.15.camel@sgallagh520.bos.redhat.com> <4E8B01E6.5000805@s3group.cz> <1317735789.2382.19.camel@sgallagh520.bos.redhat.com> <4E8B183B.5030808@s3group.cz> <1317739661.2382.21.camel@sgallagh520.bos.redhat.com> Message-ID: <4E8C0F1B.1000203@s3group.cz> Submitted RFEs #743503,#743505,#743505 and #743509 into RedHat bugzilla (I have no login to fedorahosted.org so I could not submit to upstream). Take them as a wish-list only and feel free to close them if they do not fit into the IPA roadmap. Thanks! Ondrej On 10/04/2011 04:47 PM, Stephen Gallagher wrote: > These are all great ideas, Ondrej. Would you mind opening RFE bugs for > them? You can file them upstream at https://fedorahosted.org/sssd or in > Red Hat Bugzilla https://bugzilla.redhat.com in the sssd component. > > On Tue, 2011-10-04 at 16:29 +0200, Ondrej Valousek wrote: >>> Can you provide more information here? We DO have support for automatic >>> detection based on DNS SRV records. Does a "DC locator" use some other >>> mechanism? >>> >> Example AD domain CONTOSO.COM used on 3 sites - Prague,Cork, Dublin. >> I have machine in Prague and I want it to join CONTOSO.COM. Now if I >> used: >> >> dns_discovery_domain = contoso.com >> >> sssd would try to connect to any DC in the domain - even the one in >> Dublin, completely ignoring sites. >> I have to use: >> >> dns_discovery_domain = Prague._sites.contoso.com >> >> To force it to use Prague DCs only. >> My understanding is, that the "DC locator" tries to communicate with >> DC's first to determine local site and remote DC's are only used if no >> valid/working DC can be found in the local site (Prague in this case). >> >>> I'm not sure what you mean by this? Do you mean you don't want to have >>> to specify ldap_schema = rfc2307bis and have it instead auto-detected? >>> >>> That's trickier than it sounds. >>> >> well this is a really small one. I would say it would be perfectly >> sufficient to introduce something like: >> >> ldap_schema=msrfc2307bis >> >> which would be equivalent to: >> >> ldap_user_object_class = user >> ldap_group_object_class = group >> ldap_user_home_directory = unixHomeDirectory >> ldap_schema = rfc2307bis >> >> also, the ldap bind mechanism negotiation could be potentially >> improved, now I have to explicitly specify >> >> ldap_sasl_mech = GSSAPI >> >> otherwise sssd tries to use SASL/EXTERNAL which fails when >> communicating to AD controllers. >> >>> What features of the krb5 library do you mean? SSSD provides a locator >>> plugin that manages several features of the krb5 library, including >>> kinit and kpasswd. >>> >> The thing is that not all Linux apps are using sssd so we have to >> remember to configure /etc/krb5.conf. too. >> When using Centrify, all I need to do is: >> >> # adjoin contoso.com >> >> ..which takes care of everything - /etc/nsswitch.conf, krb5.conf, PAM >> modules, eeeverything. If I wanted to use sssd for the same job I have >> to: >> >> 1. configure (manually) /etc/samba/smb.conf >> 2. net ads join (- just to get machine creds) >> 3. configure (manually) sssd.conf >> 4. configure (manually) PAM modules >> 5. configure (manually) krb5.conf >> >> I understand that much of this is probably not sssd duty, but it would >> be helpful to have some script around which would do the same job. >> >> >> ______________________________________________________________________ >> The information contained in this e-mail and in any attachments is >> confidential and is designated solely for the attention of the >> intended recipient(s). If you are not an intended recipient, you must >> not use, disclose, copy, distribute or retain this e-mail or any part >> thereof. If you have received this e-mail in error, please notify the >> sender by return e-mail and delete all copies of this e-mail from your >> computer system(s). Please direct any additional queries to: >> communications at s3group.com. Thank You. Silicon and Software Systems >> Limited (S3 Group). Registered in Ireland no. 378073. Registered >> Office: South County Business Park, Leopardstown, Dublin 18 >> >> ______________________________________________________________________ >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Oct 5 13:31:48 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 05 Oct 2011 09:31:48 -0400 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <4E8C0F1B.1000203@s3group.cz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E896C40.3010004@s3group.cz> <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E8AB681.5080103@s3group.cz> <1317730169.2382.15.camel@sgallagh520.bos.redhat.com> <4E8B01E6.5000805@s3group.cz> <1317735789.2382.19.camel@sgallagh520.bos.redhat.com> <4E8B183B.5030808@s3group.cz> <1317739661.2382.21.camel@sgallagh520.bos.redhat.com> <4E8C0F1B.1000203@s3group.cz> Message-ID: <4E8C5C44.90200@redhat.com> On 10/05/2011 04:02 AM, Ondrej Valousek wrote: > Submitted RFEs #743503,#743505,#743505 and #743509 into RedHat > bugzilla (I have no login to fedorahosted.org so I could not submit to > upstream). > Take them as a wish-list only and feel free to close them if they do > not fit into the IPA roadmap. Thank you for taking time and doing this! > > Thanks! > Ondrej > > On 10/04/2011 04:47 PM, Stephen Gallagher wrote: >> These are all great ideas, Ondrej. Would you mind opening RFE bugs for >> them? You can file them upstream at https://fedorahosted.org/sssd or in >> Red Hat Bugzilla https://bugzilla.redhat.com in the sssd component. >> >> On Tue, 2011-10-04 at 16:29 +0200, Ondrej Valousek wrote: >>>> Can you provide more information here? We DO have support for automatic >>>> detection based on DNS SRV records. Does a "DC locator" use some other >>>> mechanism? >>>> >>> Example AD domain CONTOSO.COM used on 3 sites - Prague,Cork, Dublin. >>> I have machine in Prague and I want it to join CONTOSO.COM. Now if I >>> used: >>> >>> dns_discovery_domain = contoso.com >>> >>> sssd would try to connect to any DC in the domain - even the one in >>> Dublin, completely ignoring sites. >>> I have to use: >>> >>> dns_discovery_domain = Prague._sites.contoso.com >>> >>> To force it to use Prague DCs only. >>> My understanding is, that the "DC locator" tries to communicate with >>> DC's first to determine local site and remote DC's are only used if no >>> valid/working DC can be found in the local site (Prague in this case). >>> >>>> I'm not sure what you mean by this? Do you mean you don't want to have >>>> to specify ldap_schema = rfc2307bis and have it instead auto-detected? >>>> >>>> That's trickier than it sounds. >>>> >>> well this is a really small one. I would say it would be perfectly >>> sufficient to introduce something like: >>> >>> ldap_schema=msrfc2307bis >>> >>> which would be equivalent to: >>> >>> ldap_user_object_class = user >>> ldap_group_object_class = group >>> ldap_user_home_directory = unixHomeDirectory >>> ldap_schema = rfc2307bis >>> >>> also, the ldap bind mechanism negotiation could be potentially >>> improved, now I have to explicitly specify >>> >>> ldap_sasl_mech = GSSAPI >>> >>> otherwise sssd tries to use SASL/EXTERNAL which fails when >>> communicating to AD controllers. >>> >>>> What features of the krb5 library do you mean? SSSD provides a locator >>>> plugin that manages several features of the krb5 library, including >>>> kinit and kpasswd. >>>> >>> The thing is that not all Linux apps are using sssd so we have to >>> remember to configure /etc/krb5.conf. too. >>> When using Centrify, all I need to do is: >>> >>> # adjoin contoso.com >>> >>> ..which takes care of everything - /etc/nsswitch.conf, krb5.conf, PAM >>> modules, eeeverything. If I wanted to use sssd for the same job I have >>> to: >>> >>> 1. configure (manually) /etc/samba/smb.conf >>> 2. net ads join (- just to get machine creds) >>> 3. configure (manually) sssd.conf >>> 4. configure (manually) PAM modules >>> 5. configure (manually) krb5.conf >>> >>> I understand that much of this is probably not sssd duty, but it would >>> be helpful to have some script around which would do the same job. >>> >>> >>> ______________________________________________________________________ >>> The information contained in this e-mail and in any attachments is >>> confidential and is designated solely for the attention of the >>> intended recipient(s). If you are not an intended recipient, you must >>> not use, disclose, copy, distribute or retain this e-mail or any part >>> thereof. If you have received this e-mail in error, please notify the >>> sender by return e-mail and delete all copies of this e-mail from your >>> computer system(s). Please direct any additional queries to: >>> communications at s3group.com. Thank You. Silicon and Software Systems >>> Limited (S3 Group). Registered in Ireland no. 378073. Registered >>> Office: South County Business Park, Leopardstown, Dublin 18 >>> >>> ______________________________________________________________________ >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > ------------------------------------------------------------------------ > The information contained in this e-mail and in any attachments is > confidential and is designated solely for the attention of the > intended recipient(s). If you are not an intended recipient, you must > not use, disclose, copy, distribute or retain this e-mail or any part > thereof. If you have received this e-mail in error, please notify the > sender by return e-mail and delete all copies of this e-mail from your > computer system(s). Please direct any additional queries to: > communications at s3group.com. Thank You. Silicon and Software Systems > Limited (S3 Group). Registered in Ireland no. 378073. Registered > Office: South County Business Park, Leopardstown, Dublin 18 > ------------------------------------------------------------------------ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Oct 5 13:44:59 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 05 Oct 2011 09:44:59 -0400 Subject: [Freeipa-users] freeRADIUS? In-Reply-To: <4E8B22BE.8030500@redhat.com> References: <4E8B22BE.8030500@redhat.com> Message-ID: <4E8C5F5B.7000002@redhat.com> On 10/04/2011 11:14 AM, John Dennis wrote: > On 10/04/2011 10:50 AM, Jimmy wrote: >> I've been searching and see a few references to freeRADIUS used with >> FreeIPA, but I don't see any substantial information on the subject. Is >> there a procedure to use FreeIPA with freeRADIUS? I have a standalone >> openldap/freeradius server that I would like to eliminate if possible. > > Integrating FreeRADIUS with IPA is on the long term roadmap. It's not > as easy as one might imagine. The fundamental problem is that many of > the RADIUS authentication methods require access to the user's > cleartext password or hashes we feel are insecure. This presents a > design issue for us to resolve, as such it has been pushed out. > > Refer to this chart for more information: > > http://deployingradius.com/documents/protocols/compatibility.html > > OK. This could have created a wrong impression the freeRADIUS can't be used now with IPA. This is wrong. There is no tight integration but IPA for sure can act as an "authentication oracle" for freeRADIUS. http://deployingradius.com/documents/protocols/oracles.html You have to use: EAP-TTLS as an outer tunnel, PAP as an inner tunnel and configure freeRADIUS to do bind operation against IPA as if it is an LDAP server (or you can use pam for that if you want, with SSSD you might get offline caching if you connection between RADIUS host and IPA might be disrupted, but if they are on the same box or connection is reliable it might make sense to use direct ldap bind rather than use the PAM stack) . How to do all this can be found in the RADIUS manual. If you find some interesting gotchas related to IPA or SSSD in this setup please share with us. Also if you find this information not sufficient let us know and we will try to help you find the right documentation. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From g17jimmy at gmail.com Wed Oct 5 13:54:28 2011 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 5 Oct 2011 09:54:28 -0400 Subject: [Freeipa-users] freeRADIUS? In-Reply-To: <4E8C5F5B.7000002@redhat.com> References: <4E8B22BE.8030500@redhat.com> <4E8C5F5B.7000002@redhat.com> Message-ID: Thanks. I will look into it and get back with more info. On Wed, Oct 5, 2011 at 9:44 AM, Dmitri Pal wrote: > On 10/04/2011 11:14 AM, John Dennis wrote: > > On 10/04/2011 10:50 AM, Jimmy wrote: > >> I've been searching and see a few references to freeRADIUS used with > >> FreeIPA, but I don't see any substantial information on the subject. Is > >> there a procedure to use FreeIPA with freeRADIUS? I have a standalone > >> openldap/freeradius server that I would like to eliminate if possible. > > > > Integrating FreeRADIUS with IPA is on the long term roadmap. It's not > > as easy as one might imagine. The fundamental problem is that many of > > the RADIUS authentication methods require access to the user's > > cleartext password or hashes we feel are insecure. This presents a > > design issue for us to resolve, as such it has been pushed out. > > > > Refer to this chart for more information: > > > > http://deployingradius.com/documents/protocols/compatibility.html > > > > > OK. This could have created a wrong impression the freeRADIUS can't be > used now with IPA. This is wrong. There is no tight integration but IPA > for sure can act as an "authentication oracle" for freeRADIUS. > http://deployingradius.com/documents/protocols/oracles.html > > You have to use: EAP-TTLS as an outer tunnel, PAP as an inner tunnel and > configure freeRADIUS to do bind operation against IPA as if it is an > LDAP server (or you can use pam for that if you want, with SSSD you > might get offline caching if you connection between RADIUS host and IPA > might be disrupted, but if they are on the same box or connection is > reliable it might make sense to use direct ldap bind rather than use the > PAM stack) . > How to do all this can be found in the RADIUS manual. If you find some > interesting gotchas related to IPA or SSSD in this setup please share > with us. Also if you find this information not sufficient let us know > and we will try to help you find the right documentation. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Wed Oct 5 14:28:07 2011 From: jdennis at redhat.com (John Dennis) Date: Wed, 05 Oct 2011 10:28:07 -0400 Subject: [Freeipa-users] freeRADIUS? In-Reply-To: <4E8C5F5B.7000002@redhat.com> References: <4E8B22BE.8030500@redhat.com> <4E8C5F5B.7000002@redhat.com> Message-ID: <4E8C6977.9010308@redhat.com> On 10/05/2011 09:44 AM, Dmitri Pal wrote: > On 10/04/2011 11:14 AM, John Dennis wrote: >> On 10/04/2011 10:50 AM, Jimmy wrote: >>> I've been searching and see a few references to freeRADIUS used with >>> FreeIPA, but I don't see any substantial information on the subject. Is >>> there a procedure to use FreeIPA with freeRADIUS? I have a standalone >>> openldap/freeradius server that I would like to eliminate if possible. >> >> Integrating FreeRADIUS with IPA is on the long term roadmap. It's not >> as easy as one might imagine. The fundamental problem is that many of >> the RADIUS authentication methods require access to the user's >> cleartext password or hashes we feel are insecure. This presents a >> design issue for us to resolve, as such it has been pushed out. >> >> Refer to this chart for more information: >> >> http://deployingradius.com/documents/protocols/compatibility.html >> >> > OK. This could have created a wrong impression the freeRADIUS can't be > used now with IPA. This is wrong. There is no tight integration but IPA > for sure can act as an "authentication oracle" for freeRADIUS. > http://deployingradius.com/documents/protocols/oracles.html > > You have to use: EAP-TTLS as an outer tunnel, PAP as an inner tunnel and > configure freeRADIUS to do bind operation against IPA as if it is an > LDAP server (or you can use pam for that if you want, with SSSD you > might get offline caching if you connection between RADIUS host and IPA > might be disrupted, but if they are on the same box or connection is > reliable it might make sense to use direct ldap bind rather than use the > PAM stack) . > How to do all this can be found in the RADIUS manual. If you find some > interesting gotchas related to IPA or SSSD in this setup please share > with us. Also if you find this information not sufficient let us know > and we will try to help you find the right documentation. > Sure, but the typical stumbling block is that in the majority of cases the goal is transparent wireless authentication by supplicants in their default configuration. It's usually difficult to get users to properly configure their supplicants and for some versions of Windows it may not be possible at all without installing a different supplicant. Then there is is the issue of getting the radius CA cert into each client or telling users to disable cert validation which is not something we should be doing. In short, there are logistical problems which may not meet real world needs. It's hard to know a prori if the above will meets the needs or not, perhaps it will so it's good Dmitri posted the suggestion. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Oct 5 14:59:24 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 05 Oct 2011 10:59:24 -0400 Subject: [Freeipa-users] freeRADIUS? In-Reply-To: <4E8C6977.9010308@redhat.com> References: <4E8B22BE.8030500@redhat.com> <4E8C5F5B.7000002@redhat.com> <4E8C6977.9010308@redhat.com> Message-ID: <4E8C70CC.3090502@redhat.com> On 10/05/2011 10:28 AM, John Dennis wrote: > On 10/05/2011 09:44 AM, Dmitri Pal wrote: >> On 10/04/2011 11:14 AM, John Dennis wrote: >>> On 10/04/2011 10:50 AM, Jimmy wrote: >>>> I've been searching and see a few references to freeRADIUS used with >>>> FreeIPA, but I don't see any substantial information on the >>>> subject. Is >>>> there a procedure to use FreeIPA with freeRADIUS? I have a standalone >>>> openldap/freeradius server that I would like to eliminate if possible. >>> >>> Integrating FreeRADIUS with IPA is on the long term roadmap. It's not >>> as easy as one might imagine. The fundamental problem is that many of >>> the RADIUS authentication methods require access to the user's >>> cleartext password or hashes we feel are insecure. This presents a >>> design issue for us to resolve, as such it has been pushed out. >>> >>> Refer to this chart for more information: >>> >>> http://deployingradius.com/documents/protocols/compatibility.html >>> >>> >> OK. This could have created a wrong impression the freeRADIUS can't be >> used now with IPA. This is wrong. There is no tight integration but IPA >> for sure can act as an "authentication oracle" for freeRADIUS. >> http://deployingradius.com/documents/protocols/oracles.html >> >> You have to use: EAP-TTLS as an outer tunnel, PAP as an inner tunnel and >> configure freeRADIUS to do bind operation against IPA as if it is an >> LDAP server (or you can use pam for that if you want, with SSSD you >> might get offline caching if you connection between RADIUS host and IPA >> might be disrupted, but if they are on the same box or connection is >> reliable it might make sense to use direct ldap bind rather than use the >> PAM stack) . >> How to do all this can be found in the RADIUS manual. If you find some >> interesting gotchas related to IPA or SSSD in this setup please share >> with us. Also if you find this information not sufficient let us know >> and we will try to help you find the right documentation. >> > > Sure, but the typical stumbling block is that in the majority of cases > the goal is transparent wireless authentication by supplicants in > their default configuration. It's usually difficult to get users to > properly configure their supplicants and for some versions of Windows > it may not be possible at all without installing a different > supplicant. Then there is is the issue of getting the radius CA cert > into each client or telling users to disable cert validation which is > not something we should be doing. In short, there are logistical > problems which may not meet real world needs. It's hard to know a > prori if the above will meets the needs or not, perhaps it will so > it's good Dmitri posted the suggestion. > It really depends what is the RADIUS client. It can be a VPN case or it can be Wireless. VPN usually uses the setup that I defined above. For the Wireless case one has to use a different scheme. It really depends on the capabilities of the supplicant so one should start by looking at what supplicants are in use. Then the approach is pretty simple: * Use tunneling that your supplicant supports. It can be PEAP or EAP-TTLS which does not require client side certificate which is great. I have not been in this space for 4 years so I do not know if anything new and exciting happened and new more usable methods emerged * Inner methods can be different. Most popular are PAP and EAP-GTC. One usually uses OTP tokens for wireless access so EAP-GTC as an inner method should be used in this case. If it is just password it can be PAP. IN both cases you have a cleartext credential on the RADIUS server side that you can turn around and sent for authentication to IPA. Unfortunately IPA does not support native 2FA yet. It will within couple years. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Wed Oct 5 20:18:37 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 5 Oct 2011 20:18:37 +0000 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <4E8AB681.5080103@s3group.cz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E896C40.3010004@s3group.cz> <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E8AB681.5080103@s3group.cz> Message-ID: <833D8E48405E064EBC54C84EC6B36E40446230CB@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, The costs seem very painful....Ive not looked at them (Likewise, Quest, Centrify) in detail yet....and some of the blurb that nothing like AD exists in the Linux world is now nullified with freeIPA.... "Polished" bear in mind that this is gen 2.0 or really an advanced "PDC" in a way....the biggest thing for me so far is the ease of use, which with our limited capability staff/useradmins has to be a god send. So IPA on RHEL6.2 beta...time to play!!! :D regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Ondrej Valousek [ondrejv at s3group.cz] Sent: Tuesday, 4 October 2011 8:32 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Question on AD to freeipa sync I have ~50 servers and yes, we are using Centrify now - and yes, it is pain in the ass (need to take care of the licenses). But I have found out recently that sssd can do much of the Centrify's duty (authorization & authentication) - well, it is not so polished, but it seems to work well. Ondrej On 10/03/2011 10:51 PM, Steven Jones wrote: I have 200+servers and 250 linux desktops and growing.....cant manage those with local access with 1.5 admins....you also cant manage them with AD unless you buy centrify/likewise or quest software or similar and thats very expensive and a pain in the ass. ________________________________ The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 ________________________________ From ondrejv at s3group.cz Thu Oct 6 07:22:41 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Thu, 06 Oct 2011 09:22:41 +0200 Subject: [Freeipa-users] Question on AD to freeipa sync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40446230CB@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404461A1B8@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E896C40.3010004@s3group.cz> <833D8E48405E064EBC54C84EC6B36E40446209D8@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E8AB681.5080103@s3group.cz> <833D8E48405E064EBC54C84EC6B36E40446230CB@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E8D5741.6080000@s3group.cz> Exactly! That was the biggest advantage of Centrify/Likewise/rest, but hopefully with the latest set of RFEs I have submitted against sssd, it will no longer be any advantage. On 10/05/2011 10:18 PM, Steven Jones wrote: > ...the biggest thing for me so far is the ease of use, which with our limited capability staff/useradmins has to be a god send. The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Duncan.Innes at virginmoney.com Thu Oct 6 07:35:09 2011 From: Duncan.Innes at virginmoney.com (Duncan.Innes at virginmoney.com) Date: Thu, 6 Oct 2011 08:35:09 +0100 Subject: [Freeipa-users] Roadmap Update In-Reply-To: <4E8BAD90.5000305@redhat.com> References: <4E8B8769.40306@redhat.com> <4E8BAD90.5000305@redhat.com> Message-ID: Many thanks. That's some great work going on. And a BIG help in laying out our future technology direction. Cheers Duncan From: Dmitri Pal To: freeipa-users at redhat.com Date: 05/10/2011 02:08 Subject: Re: [Freeipa-users] Roadmap Update Sent by: freeipa-users-bounces at redhat.com On 10/04/2011 06:23 PM, Dmitri Pal wrote: On 10/04/2011 06:42 AM, Duncan.Innes at virginmoney.com wrote: Hi, Is there any chance someone could do a quick update to the Roadmap? I can see from the devel mailing list that there's lots of work going on, but I'm not able to decipher a higher level direction in which things are going. = 3.0 Plans = * Beta by Christmas break * Release Feb-Mar ? 2012 * Release is time driven * Content: Cross Kerberos Trusts - Milestones start with "3.0 Trust" Core IPA enhancements - Milestones start with "3.0 Core" * Project is run is following month aligned sprints == Cross Kerberos Trusts == * Reasons: Support of mixed AD <-> IPA deployments Support of multiple IPA domains * Use cases: User is in AD; service is in IPA; user logs in against AD, gets ticket and then accesses IPA service. Same as above but IPA service then in tern needs to access other service on behalf of user (TGT forwarding) Same as above but IPA to IPA Authenticated AD user logs with SSO into Linux machine that is a part of IPA domain in the cloud over SSH. Etc. I also created reports to easily select the relevant tickets. This one for trust work https://fedorahosted.org/freeipa/report/20 == Themes of the core 3.0 enhancements == * Support SELinux central management * Support SSH user key management * Add additional standard maps * UI enhancements and improvements * DNS improvements and better IP data handling * Performance of the admin interface And this one for core effort https://fedorahosted.org/freeipa/report/21 = Beyond 3.0 = * Over trust use cases * Key management * User certificate management * SAML, OpenID, Oauth provider * External authentication integration (OTP) * Level of assurance * RADIUS An updated roadmap would help understand the direction of the project. Many thanks Duncan This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money do not accept responsibility for changes made to any e-mail after sending. Virgin Money have swept, and believe this e-mail to be free of viruses and profanity but make no guarantees to this effect. Virgin Money Personal Financial Service Ltd is authorised and regulated by the Financial Services Authority. Registered in England no. 3072766. Entered on the Financial Services Authority's Register http://www.fsa.gov.uk/register/. Register Number 179271. The Virgin Deposit Account and the Virgin Cash ISA are both personal deposit accounts with Virgin Bank Ltd administered by Virgin Money Personal Financial Service Ltd. Virgin Bank Ltd is authorised and regulated by the Financial Services Authority. Registered in England no. 980698. Entered on the Financial Services Authority's Register http://www.fsa.gov.uk/register/. Register Number 204459. Virgin Money Unit Trust Managers Ltd is authorised and regulated by the Financial Services Authority. Registered in England no. 3000482. Entered on the Financial Services Authority's Register. Register Number 171748. Virgin Money Ltd. Registered in England no. 4232392. Introducer appointed representative only of Virgin Money Personal Financial Service Ltd. Virgin Money Management Services Ltd. Registered in England no.3072772. Virgin Money Holdings (UK) Limited. Registered in England no.3087587. All the above companies have their Registered office at Discovery House, Whiting Road, Norwich NR4 6EJ. All products are open only to residents of the United Kingdom. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Mon Oct 10 01:34:06 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 10 Oct 2011 01:34:06 +0000 Subject: [Freeipa-users] xmlrpc-c is missing or too low a version for the new ipa client in 6.2svr beta. Message-ID: <833D8E48405E064EBC54C84EC6B36E4044626CB4@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I dont know if this is the right place but I have found an issue in REHL6.2beta release. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 259614 bytes Desc: Screenshot.png URL: From rcritten at redhat.com Mon Oct 10 18:09:03 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Oct 2011 14:09:03 -0400 Subject: [Freeipa-users] xmlrpc-c is missing or too low a version for the new ipa client in 6.2svr beta. In-Reply-To: <833D8E48405E064EBC54C84EC6B36E4044626CB4@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E4044626CB4@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E9334BF.5030403@redhat.com> Steven Jones wrote: > Hi, > > I dont know if this is the right place but I have found an issue in REHL6.2beta release. I'll look into this. Can you look and see what (if any) version of xmlrpc-c is included on the DVD you have? thanks rob From g17jimmy at gmail.com Tue Oct 11 17:47:36 2011 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 11 Oct 2011 13:47:36 -0400 Subject: [Freeipa-users] disable ntp? Message-ID: Is there a way to disable ntp after installation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Oct 11 18:16:46 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Oct 2011 14:16:46 -0400 Subject: [Freeipa-users] disable ntp? In-Reply-To: References: Message-ID: <4E94880E.503@redhat.com> Jimmy wrote: > Is there a way to disable ntp after installation? /sbin/service ntpd stop /sbin/chkconfig ntpd off To install a client or server w/o ntp use -N/--no-ntp rob From g17jimmy at gmail.com Tue Oct 11 18:17:57 2011 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 11 Oct 2011 14:17:57 -0400 Subject: [Freeipa-users] disable ntp? In-Reply-To: <4E94880E.503@redhat.com> References: <4E94880E.503@redhat.com> Message-ID: I thought I tried that... I'll give it another go. On Tue, Oct 11, 2011 at 2:16 PM, Rob Crittenden wrote: > Jimmy wrote: > >> Is there a way to disable ntp after installation? >> > > /sbin/service ntpd stop > /sbin/chkconfig ntpd off > > To install a client or server w/o ntp use -N/--no-ntp > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Oct 11 22:10:43 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 11 Oct 2011 22:10:43 +0000 Subject: [Freeipa-users] setting user logins by "hand" Message-ID: <833D8E48405E064EBC54C84EC6B36E404462962E@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Looks like the IPA server on RHEL6.2beta is setting user logins, I need this to be a manually editable field so I can follow company policy So at the moment adding steven jones works out as sjones when I need jonesst1 set by hand. How do I set this please? Also in installing ipa-server the forwarder= flag would only accept one IP trying to delimit for a second with a , failed. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From mkosek at redhat.com Wed Oct 12 06:38:43 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Oct 2011 08:38:43 +0200 Subject: [Freeipa-users] setting user logins by "hand" In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404462962E@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404462962E@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1318401525.14093.4.camel@balmora.brq.redhat.com> On Tue, 2011-10-11 at 22:10 +0000, Steven Jones wrote: > Hi, > > Looks like the IPA server on RHEL6.2beta is setting user logins, I need this to be a manually editable field so I can follow company policy > > So at the moment adding steven jones works out as sjones when I need jonesst1 set by hand. > > How do I set this please? When you are adding a user, you have the possibility to change a username which we provide default to. In CLI its pretty easy: # ipa user-add --first=Foo --last=Bar User login [fbar]: barfoo ------------------- Added user "barfoo" ------------------- User login: barfoo First name: Foo Last name: Bar Full name: Foo Bar Display name: Foo Bar Initials: FB Home directory: /home/barfoo GECOS field: Foo Bar Login shell: /bin/sh Kerberos principal: barfoo at IDM.LAB.BOS.REDHAT.COM UID: 96000014 GID: 96000001 Keytab: False Password: False In current WebUI version you can change the default user name by clicking on the username field and changing the value. > > Also in installing ipa-server the forwarder= flag would only accept one IP trying to delimit for a second with a , failed. Options with multiple values should be entered the following way: # ipa-dns-install --forwarder=10.16.255.2 --forwarder=10.16.255.3 The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will setup DNS for the FreeIPA Server. This includes: * Configure DNS (bind) To accept the default shown in brackets, press the Enter key. Existing BIND configuration detected, overwrite? [no]: y Directory Manager password: Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [78.16.10.in-addr.arpa.]: Using reverse zone 78.16.10.in-addr.arpa. The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring named: [1/9]: adding DNS container [2/9]: setting up our zone [3/9]: setting up reverse zone [4/9]: setting up our own record [5/9]: setting up kerberos principal [6/9]: setting up named.conf [7/9]: restarting named [8/9]: configuring named to start on boot [9/9]: changing resolv.conf to point to ourselves done configuring named. ============================================================================== Setup complete You must make sure these network ports are open: TCP Ports: * 53: bind UDP Ports: * 53: bind Both forwarders should be set: # grep -A 4 forwarders /etc/named.conf forwarders { 10.16.255.2; 10.16.255.3; }; Martin From sigbjorn at nixtra.com Wed Oct 12 15:09:55 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 12 Oct 2011 17:09:55 +0200 (CEST) Subject: [Freeipa-users] Configure browser Message-ID: <28786.213.225.75.97.1318432195.squirrel@www.nixtra.com> Hi, I have just installed RHEL 6.2 beta, with ipa-server-2.1.1-4.el6.x86_64. I have installed firefox locally on the ipa server, for testings sake. I ran kinit, got a kerberos ticket. Started firefox, and followed the first time user instructions. Installing the cert worked fine. However when I click on the "Configure Firefox" button, nothing happens. I check about:config in another tab, nothing has been configured. Changing the network.negotiate-auth.delgation-uris and network.negotiate-auth.trusted-uris manually works fine. Is this something you're aware of, or a bug? Rgds, Siggi From sigbjorn at nixtra.com Wed Oct 12 15:13:55 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 12 Oct 2011 17:13:55 +0200 (CEST) Subject: [Freeipa-users] Default shell in Configuration in the WEBUI Message-ID: <28994.213.225.75.97.1318432435.squirrel@www.nixtra.com> Hi, What's happened with the option for default shell under ipa server -> configuration in the webui? This seem to be missing? I can still see and change the value for default shell using the CLI. Regards, Siggi From rcritten at redhat.com Wed Oct 12 15:48:46 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Oct 2011 11:48:46 -0400 Subject: [Freeipa-users] Default shell in Configuration in the WEBUI In-Reply-To: <28994.213.225.75.97.1318432435.squirrel@www.nixtra.com> References: <28994.213.225.75.97.1318432435.squirrel@www.nixtra.com> Message-ID: <4E95B6DE.1040509@redhat.com> Sigbjorn Lie wrote: > Hi, > > What's happened with the option for default shell under ipa server -> configuration in the webui? > This seem to be missing? > > I can still see and change the value for default shell using the CLI. Fixed upstream, it'll be available in the next dot release. rob From sigbjorn at nixtra.com Wed Oct 12 15:50:11 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 12 Oct 2011 17:50:11 +0200 (CEST) Subject: [Freeipa-users] Default shell in Configuration in the WEBUI In-Reply-To: <4E95B6DE.1040509@redhat.com> References: <28994.213.225.75.97.1318432435.squirrel@www.nixtra.com> <4E95B6DE.1040509@redhat.com> Message-ID: <31580.213.225.75.97.1318434611.squirrel@www.nixtra.com> On Wed, October 12, 2011 17:48, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> Hi, >> >> >> What's happened with the option for default shell under ipa server -> configuration in the >> webui? This seem to be missing? >> >> >> I can still see and change the value for default shell using the CLI. >> > > Fixed upstream, it'll be available in the next dot release. > Excellent, thanks. From rcritten at redhat.com Wed Oct 12 15:50:32 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Oct 2011 11:50:32 -0400 Subject: [Freeipa-users] Configure browser In-Reply-To: <28786.213.225.75.97.1318432195.squirrel@www.nixtra.com> References: <28786.213.225.75.97.1318432195.squirrel@www.nixtra.com> Message-ID: <4E95B748.8060802@redhat.com> Sigbjorn Lie wrote: > Hi, > > I have just installed RHEL 6.2 beta, with ipa-server-2.1.1-4.el6.x86_64. I have installed firefox > locally on the ipa server, for testings sake. > > I ran kinit, got a kerberos ticket. Started firefox, and followed the first time user > instructions. Installing the cert worked fine. However when I click on the "Configure Firefox" > button, nothing happens. > > I check about:config in another tab, nothing has been configured. > > Changing the network.negotiate-auth.delgation-uris and network.negotiate-auth.trusted-uris > manually works fine. > > Is this something you're aware of, or a bug? We'll look into this. Can you see if any javascript errors were logged? Tools->Web Development->Error console rob From Steven.Jones at vuw.ac.nz Wed Oct 12 19:00:01 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 12 Oct 2011 19:00:01 +0000 Subject: [Freeipa-users] forwarders Message-ID: <833D8E48405E064EBC54C84EC6B36E4044629971@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Forwarders Thanks but, In which case the documentationfor fedora15 page 21 example 2.5 (I assume this will become the rhel6.2? documentation) is incorrect as it shows comma de-limited regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: Wednesday, 12 October 2011 7:38 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] setting user logins by "hand" On Tue, 2011-10-11 at 22:10 +0000, Steven Jones wrote: > Hi, > > Looks like the IPA server on RHEL6.2beta is setting user logins, I need this to be a manually editable field so I can follow company policy > > So at the moment adding steven jones works out as sjones when I need jonesst1 set by hand. > > How do I set this please? When you are adding a user, you have the possibility to change a username which we provide default to. In CLI its pretty easy: # ipa user-add --first=Foo --last=Bar User login [fbar]: barfoo ------------------- Added user "barfoo" ------------------- User login: barfoo First name: Foo Last name: Bar Full name: Foo Bar Display name: Foo Bar Initials: FB Home directory: /home/barfoo GECOS field: Foo Bar Login shell: /bin/sh Kerberos principal: barfoo at IDM.LAB.BOS.REDHAT.COM UID: 96000014 GID: 96000001 Keytab: False Password: False In current WebUI version you can change the default user name by clicking on the username field and changing the value. > > Also in installing ipa-server the forwarder= flag would only accept one IP trying to delimit for a second with a , failed. Options with multiple values should be entered the following way: # ipa-dns-install --forwarder=10.16.255.2 --forwarder=10.16.255.3 The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will setup DNS for the FreeIPA Server. This includes: * Configure DNS (bind) To accept the default shown in brackets, press the Enter key. Existing BIND configuration detected, overwrite? [no]: y Directory Manager password: Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [78.16.10.in-addr.arpa.]: Using reverse zone 78.16.10.in-addr.arpa. The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring named: [1/9]: adding DNS container [2/9]: setting up our zone [3/9]: setting up reverse zone [4/9]: setting up our own record [5/9]: setting up kerberos principal [6/9]: setting up named.conf [7/9]: restarting named [8/9]: configuring named to start on boot [9/9]: changing resolv.conf to point to ourselves done configuring named. ============================================================================== Setup complete You must make sure these network ports are open: TCP Ports: * 53: bind UDP Ports: * 53: bind Both forwarders should be set: # grep -A 4 forwarders /etc/named.conf forwarders { 10.16.255.2; 10.16.255.3; }; Martin From Steven.Jones at vuw.ac.nz Wed Oct 12 19:03:47 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 12 Oct 2011 19:03:47 +0000 Subject: [Freeipa-users] setting user logins by "hand" In-Reply-To: <1318401525.14093.4.camel@balmora.brq.redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404462962E@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1318401525.14093.4.camel@balmora.brq.redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404462997D@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, CLI, is not an option for our useradmins.....I am trying to sell this as very easy to use even for those of limited linux ability.....our useradmins do AD only which is point and click...the solution has to be very simple and gui driven or it will be rejected. Also in the gui provided in 6.2 beta there is no longer that option to set the login that I can see, the old verison did allow that....unles its moved somewhere I cannot see. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: Wednesday, 12 October 2011 7:38 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] setting user logins by "hand" On Tue, 2011-10-11 at 22:10 +0000, Steven Jones wrote: > Hi, > > Looks like the IPA server on RHEL6.2beta is setting user logins, I need this to be a manually editable field so I can follow company policy > > So at the moment adding steven jones works out as sjones when I need jonesst1 set by hand. > > How do I set this please? When you are adding a user, you have the possibility to change a username which we provide default to. In CLI its pretty easy: # ipa user-add --first=Foo --last=Bar User login [fbar]: barfoo ------------------- Added user "barfoo" ------------------- User login: barfoo First name: Foo Last name: Bar Full name: Foo Bar Display name: Foo Bar Initials: FB Home directory: /home/barfoo GECOS field: Foo Bar Login shell: /bin/sh Kerberos principal: barfoo at IDM.LAB.BOS.REDHAT.COM UID: 96000014 GID: 96000001 Keytab: False Password: False In current WebUI version you can change the default user name by clicking on the username field and changing the value. > > Also in installing ipa-server the forwarder= flag would only accept one IP trying to delimit for a second with a , failed. Options with multiple values should be entered the following way: # ipa-dns-install --forwarder=10.16.255.2 --forwarder=10.16.255.3 The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will setup DNS for the FreeIPA Server. This includes: * Configure DNS (bind) To accept the default shown in brackets, press the Enter key. Existing BIND configuration detected, overwrite? [no]: y Directory Manager password: Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [78.16.10.in-addr.arpa.]: Using reverse zone 78.16.10.in-addr.arpa. The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring named: [1/9]: adding DNS container [2/9]: setting up our zone [3/9]: setting up reverse zone [4/9]: setting up our own record [5/9]: setting up kerberos principal [6/9]: setting up named.conf [7/9]: restarting named [8/9]: configuring named to start on boot [9/9]: changing resolv.conf to point to ourselves done configuring named. ============================================================================== Setup complete You must make sure these network ports are open: TCP Ports: * 53: bind UDP Ports: * 53: bind Both forwarders should be set: # grep -A 4 forwarders /etc/named.conf forwarders { 10.16.255.2; 10.16.255.3; }; Martin From Steven.Jones at vuw.ac.nz Wed Oct 12 19:12:21 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 12 Oct 2011 19:12:21 +0000 Subject: [Freeipa-users] setting user logins by "hand" In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404462997D@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404462962E@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1318401525.14093.4.camel@balmora.brq.redhat.com>, <833D8E48405E064EBC54C84EC6B36E404462997D@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <833D8E48405E064EBC54C84EC6B36E40446299C3@STAWINCOX10MBX1.staff.vuw.ac.nz> Ok duh found it I had to click on show optional fields when creating the user.... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Thursday, 13 October 2011 8:03 a.m. To: Martin Kosek Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] setting user logins by "hand" Hi, CLI, is not an option for our useradmins.....I am trying to sell this as very easy to use even for those of limited linux ability.....our useradmins do AD only which is point and click...the solution has to be very simple and gui driven or it will be rejected. Also in the gui provided in 6.2 beta there is no longer that option to set the login that I can see, the old verison did allow that....unles its moved somewhere I cannot see. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: Wednesday, 12 October 2011 7:38 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] setting user logins by "hand" On Tue, 2011-10-11 at 22:10 +0000, Steven Jones wrote: > Hi, > > Looks like the IPA server on RHEL6.2beta is setting user logins, I need this to be a manually editable field so I can follow company policy > > So at the moment adding steven jones works out as sjones when I need jonesst1 set by hand. > > How do I set this please? When you are adding a user, you have the possibility to change a username which we provide default to. In CLI its pretty easy: # ipa user-add --first=Foo --last=Bar User login [fbar]: barfoo ------------------- Added user "barfoo" ------------------- User login: barfoo First name: Foo Last name: Bar Full name: Foo Bar Display name: Foo Bar Initials: FB Home directory: /home/barfoo GECOS field: Foo Bar Login shell: /bin/sh Kerberos principal: barfoo at IDM.LAB.BOS.REDHAT.COM UID: 96000014 GID: 96000001 Keytab: False Password: False In current WebUI version you can change the default user name by clicking on the username field and changing the value. > > Also in installing ipa-server the forwarder= flag would only accept one IP trying to delimit for a second with a , failed. Options with multiple values should be entered the following way: # ipa-dns-install --forwarder=10.16.255.2 --forwarder=10.16.255.3 The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will setup DNS for the FreeIPA Server. This includes: * Configure DNS (bind) To accept the default shown in brackets, press the Enter key. Existing BIND configuration detected, overwrite? [no]: y Directory Manager password: Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [78.16.10.in-addr.arpa.]: Using reverse zone 78.16.10.in-addr.arpa. The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring named: [1/9]: adding DNS container [2/9]: setting up our zone [3/9]: setting up reverse zone [4/9]: setting up our own record [5/9]: setting up kerberos principal [6/9]: setting up named.conf [7/9]: restarting named [8/9]: configuring named to start on boot [9/9]: changing resolv.conf to point to ourselves done configuring named. ============================================================================== Setup complete You must make sure these network ports are open: TCP Ports: * 53: bind UDP Ports: * 53: bind Both forwarders should be set: # grep -A 4 forwarders /etc/named.conf forwarders { 10.16.255.2; 10.16.255.3; }; Martin _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Wed Oct 12 19:14:08 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 12 Oct 2011 19:14:08 +0000 Subject: [Freeipa-users] Configure browser In-Reply-To: <28786.213.225.75.97.1318432195.squirrel@www.nixtra.com> References: <28786.213.225.75.97.1318432195.squirrel@www.nixtra.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40446299CF@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I just had to re-configure firefox a second time, after a reboot but the wierd thing is it said it was already configured.....but it wouldnt work until I did so. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie [sigbjorn at nixtra.com] Sent: Thursday, 13 October 2011 4:09 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] Configure browser Hi, I have just installed RHEL 6.2 beta, with ipa-server-2.1.1-4.el6.x86_64. I have installed firefox locally on the ipa server, for testings sake. I ran kinit, got a kerberos ticket. Started firefox, and followed the first time user instructions. Installing the cert worked fine. However when I click on the "Configure Firefox" button, nothing happens. I check about:config in another tab, nothing has been configured. Changing the network.negotiate-auth.delgation-uris and network.negotiate-auth.trusted-uris manually works fine. Is this something you're aware of, or a bug? Rgds, Siggi _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Wed Oct 12 21:59:22 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 12 Oct 2011 17:59:22 -0400 Subject: [Freeipa-users] Configure browser In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40446299CF@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <28786.213.225.75.97.1318432195.squirrel@www.nixtra.com> <833D8E48405E064EBC54C84EC6B36E40446299CF@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E960DBA.5080008@redhat.com> On 10/12/2011 03:14 PM, Steven Jones wrote: > Hi, > > I just had to re-configure firefox a second time, after a reboot but the wierd thing is it said it was already configured.....but it wouldnt work until I did so. > > regards > Which version of the FF it is? > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie [sigbjorn at nixtra.com] > Sent: Thursday, 13 October 2011 4:09 a.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] Configure browser > > Hi, > > I have just installed RHEL 6.2 beta, with ipa-server-2.1.1-4.el6.x86_64. I have installed firefox > locally on the ipa server, for testings sake. > > I ran kinit, got a kerberos ticket. Started firefox, and followed the first time user > instructions. Installing the cert worked fine. However when I click on the "Configure Firefox" > button, nothing happens. > > I check about:config in another tab, nothing has been configured. > > Changing the network.negotiate-auth.delgation-uris and network.negotiate-auth.trusted-uris > manually works fine. > > Is this something you're aware of, or a bug? > > > Rgds, > Siggi > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Wed Oct 12 22:17:15 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 12 Oct 2011 22:17:15 +0000 Subject: [Freeipa-users] Configure browser In-Reply-To: <4E960DBA.5080008@redhat.com> References: <28786.213.225.75.97.1318432195.squirrel@www.nixtra.com> <833D8E48405E064EBC54C84EC6B36E40446299CF@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E960DBA.5080008@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E4044629E88@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, The one that ships inside RHEL 6.x 3.6.22 currently.... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Thursday, 13 October 2011 10:59 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Configure browser On 10/12/2011 03:14 PM, Steven Jones wrote: > Hi, > > I just had to re-configure firefox a second time, after a reboot but the wierd thing is it said it was already configured.....but it wouldnt work until I did so. > > regards > Which version of the FF it is? > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie [sigbjorn at nixtra.com] > Sent: Thursday, 13 October 2011 4:09 a.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] Configure browser > > Hi, > > I have just installed RHEL 6.2 beta, with ipa-server-2.1.1-4.el6.x86_64. I have installed firefox > locally on the ipa server, for testings sake. > > I ran kinit, got a kerberos ticket. Started firefox, and followed the first time user > instructions. Installing the cert worked fine. However when I click on the "Configure Firefox" > button, nothing happens. > > I check about:config in another tab, nothing has been configured. > > Changing the network.negotiate-auth.delgation-uris and network.negotiate-auth.trusted-uris > manually works fine. > > Is this something you're aware of, or a bug? > > > Rgds, > Siggi > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From sigbjorn at nixtra.com Thu Oct 13 13:44:08 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 13 Oct 2011 15:44:08 +0200 (CEST) Subject: [Freeipa-users] Extending schema Message-ID: <28897.62.148.39.180.1318513448.squirrel@www.nixtra.com> Hi, What is your recommendations for avoiding incompatability with future upgrades of IPA if extending the dirsrv schema and adding custom objects to the LDAP server is required? What considerations and precautions should be taken? Such as adding RBAC support for Solaris clients... Regards, Siggi From simo at redhat.com Thu Oct 13 14:09:53 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 13 Oct 2011 10:09:53 -0400 Subject: [Freeipa-users] Extending schema In-Reply-To: <28897.62.148.39.180.1318513448.squirrel@www.nixtra.com> References: <28897.62.148.39.180.1318513448.squirrel@www.nixtra.com> Message-ID: <1318514993.31149.124.camel@willson.li.ssimo.org> On Thu, 2011-10-13 at 15:44 +0200, Sigbjorn Lie wrote: > Hi, > > What is your recommendations for avoiding incompatability with future upgrades of IPA if extending > the dirsrv schema and adding custom objects to the LDAP server is required? What considerations > and precautions should be taken? > > Such as adding RBAC support for Solaris clients... Additional schema is unlikely to cause issues if it does not conflict with standard schema. We also tend to prefix all the attributes/objectlasses we create for FreeIPA so name clashes are unlikely. If it is custom schema I suggest you to prefix names appropriately too, so you have your own 'namespace'. As for placement I suggest you put this data in a separate container from standard FreeIPA stuff for new objects. In the base DN create a container named something like your company name or ticker: cn=ACME, and put all your customized entries there. Attaching additional data to users is not a big deal for custom schema. If it is not custom schema but standard schema not currently used by FreeIPA I would be a little bit more careful as a following version of FreeIPA might conceivably start using those attributes, and there is generally enough space to use them in a sort of 'incompatible' way. But don't let that stop you if you really need it. Simo. -- Simo Sorce * Red Hat, Inc * New York From jgalipea at redhat.com Fri Oct 14 13:14:43 2011 From: jgalipea at redhat.com (Jenny Galipeau) Date: Fri, 14 Oct 2011 09:14:43 -0400 (EDT) Subject: [Freeipa-users] Extending schema In-Reply-To: <1318514993.31149.124.camel@willson.li.ssimo.org> Message-ID: ----- Original Message ----- > On Thu, 2011-10-13 at 15:44 +0200, Sigbjorn Lie wrote: > > Hi, > > > > What is your recommendations for avoiding incompatability with > > future upgrades of IPA if extending > > the dirsrv schema and adding custom objects to the LDAP server is > > required? What considerations > > and precautions should be taken? > > > > Such as adding RBAC support for Solaris clients... > > Additional schema is unlikely to cause issues if it does not conflict > with standard schema. We also tend to prefix all the > attributes/objectlasses we create for FreeIPA so name clashes are > unlikely. > If it is custom schema I suggest you to prefix names appropriately > too, > so you have your own 'namespace'. > > As for placement I suggest you put this data in a separate container > from standard FreeIPA stuff for new objects. > > In the base DN create a container named something like your company > name > or ticker: cn=ACME, and put all your customized entries > there. > > Attaching additional data to users is not a big deal for custom > schema. > If it is not custom schema but standard schema not currently used by > FreeIPA I would be a little bit more careful as a following version > of > FreeIPA might conceivably start using those attributes, and there is > generally enough space to use them in a sort of 'incompatible' way. > > But don't let that stop you if you really need it. Please note that when adding additional objectclasses to users and/or group etc ... if there are required attributes in the new objectclasses, you will no longer be able to add these objects from Web UI and you will not be able to define values for the new attributes introduced from the Web UI withoutcustomization. You will have to use the CLI and the --setattr option with the command. ~ Jenny > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From sigbjorn at nixtra.com Sun Oct 16 20:53:21 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Sun, 16 Oct 2011 22:53:21 +0200 Subject: [Freeipa-users] Extending schema In-Reply-To: References: Message-ID: <4E9B4441.2090505@nixtra.com> On 10/14/2011 03:14 PM, Jenny Galipeau wrote: > > ----- Original Message ----- >> On Thu, 2011-10-13 at 15:44 +0200, Sigbjorn Lie wrote: >>> Hi, >>> >>> What is your recommendations for avoiding incompatability with >>> future upgrades of IPA if extending >>> the dirsrv schema and adding custom objects to the LDAP server is >>> required? What considerations >>> and precautions should be taken? >>> >>> Such as adding RBAC support for Solaris clients... >> Additional schema is unlikely to cause issues if it does not conflict >> with standard schema. We also tend to prefix all the >> attributes/objectlasses we create for FreeIPA so name clashes are >> unlikely. >> If it is custom schema I suggest you to prefix names appropriately >> too, >> so you have your own 'namespace'. >> >> As for placement I suggest you put this data in a separate container >> from standard FreeIPA stuff for new objects. >> >> In the base DN create a container named something like your company >> name >> or ticker: cn=ACME, and put all your customized entries >> there. >> >> Attaching additional data to users is not a big deal for custom >> schema. >> If it is not custom schema but standard schema not currently used by >> FreeIPA I would be a little bit more careful as a following version >> of >> FreeIPA might conceivably start using those attributes, and there is >> generally enough space to use them in a sort of 'incompatible' way. >> >> But don't let that stop you if you really need it. > Please note that when adding additional objectclasses to users and/or group etc ... if there are required attributes in the new objectclasses, you will no longer be able to add these objects from Web UI and you will not be able to define values for the new attributes introduced from the Web UI withoutcustomization. You will have to use the CLI and the --setattr option with the command. Thank you both, I will keep that in mind. Since Solaris RBAC is what I need at this point, is there any plans of including support for Solaris' RBAC at some point? Regards, Siggi From sigbjorn at nixtra.com Sun Oct 16 20:55:47 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Sun, 16 Oct 2011 22:55:47 +0200 Subject: [Freeipa-users] ipa: ERROR: Auto Membership is not configured Message-ID: <4E9B44D3.7010603@nixtra.com> Hi, When I attempt to create a automember rule, I get an error message "ipa: ERROR: Auto Membership is not configured". [root at ipa01 ~]# ipa automember-add --type=group s_serviceaccounts ipa: ERROR: Auto Membership is not configured [root at lieipa01 ~]# ipa group-add --desc="Developers" devel ------------------- Added group "devel" ------------------- Group name: devel Description: Developers GID: 698600064 [root at ipa01 ~]# ipa automember-add --type=group devel ipa: ERROR: Auto Membership is not configured [root at ipa01 ~]# I found the container for the automember by using "# ipa env" container_automember: cn=automember,cn=etc This container does not exist in my LDAP tree. I cannot find any documentation mentioning any requirement to create this container manually, and I cannot find any reported bug related to this issue. Is this a bug, or have I missed something? Regards, Siggi From mkosek at redhat.com Mon Oct 17 07:42:21 2011 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 17 Oct 2011 09:42:21 +0200 Subject: [Freeipa-users] ipa: ERROR: Auto Membership is not configured In-Reply-To: <4E9B44D3.7010603@nixtra.com> References: <4E9B44D3.7010603@nixtra.com> Message-ID: <1318837344.26757.7.camel@balmora.brq.redhat.com> On Sun, 2011-10-16 at 22:55 +0200, Sigbjorn Lie wrote: > Hi, > > When I attempt to create a automember rule, I get an error message "ipa: > ERROR: Auto Membership is not configured". > > [root at ipa01 ~]# ipa automember-add --type=group s_serviceaccounts > ipa: ERROR: Auto Membership is not configured > [root at lieipa01 ~]# ipa group-add --desc="Developers" devel > ------------------- > Added group "devel" > ------------------- > Group name: devel > Description: Developers > GID: 698600064 > [root at ipa01 ~]# ipa automember-add --type=group devel > ipa: ERROR: Auto Membership is not configured > [root at ipa01 ~]# > > > I found the container for the automember by using "# ipa env" > container_automember: cn=automember,cn=etc > > This container does not exist in my LDAP tree. I cannot find any > documentation mentioning any requirement to create this container > manually, and I cannot find any reported bug related to this issue. > > Is this a bug, or have I missed something? > > > Regards, > Siggi > Hi Sigbjorn, This functionality requires data in cn=automember,cn=etc as you have already correctly found. Unfortunately, they are only filled during fresh installs and not during upgrades. I filed a BZ for this issue: https://bugzilla.redhat.com/show_bug.cgi?id=746589 If you want to try this feature, you can either try a fresh install or add the data from /usr/share/ipa/automember.ldif to your LDAP server (of course, $SUFFIX needs to be expanded). Martin From sigbjorn at nixtra.com Mon Oct 17 12:46:51 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 17 Oct 2011 14:46:51 +0200 (CEST) Subject: [Freeipa-users] ipa: ERROR: Auto Membership is not configured In-Reply-To: <1318837344.26757.7.camel@balmora.brq.redhat.com> References: <4E9B44D3.7010603@nixtra.com> <1318837344.26757.7.camel@balmora.brq.redhat.com> Message-ID: <28561.213.225.75.97.1318855611.squirrel@www.nixtra.com> On Mon, October 17, 2011 09:42, Martin Kosek wrote: > On Sun, 2011-10-16 at 22:55 +0200, Sigbjorn Lie wrote: > >> Hi, >> >> >> When I attempt to create a automember rule, I get an error message "ipa: >> ERROR: Auto Membership is not configured". >> >> >> [root at ipa01 ~]# ipa automember-add --type=group s_serviceaccounts >> ipa: ERROR: Auto Membership is not configured >> [root at lieipa01 ~]# ipa group-add --desc="Developers" devel >> ------------------- >> Added group "devel" >> ------------------- >> Group name: devel >> Description: Developers >> GID: 698600064 >> [root at ipa01 ~]# ipa automember-add --type=group devel >> ipa: ERROR: Auto Membership is not configured >> [root at ipa01 ~]# >> >> >> >> I found the container for the automember by using "# ipa env" >> container_automember: cn=automember,cn=etc >> >> >> This container does not exist in my LDAP tree. I cannot find any >> documentation mentioning any requirement to create this container manually, and I cannot find any >> reported bug related to this issue. >> >> Is this a bug, or have I missed something? >> >> >> >> Regards, >> Siggi >> >> > > Hi Sigbjorn, > > > This functionality requires data in cn=automember,cn=etc as you have > already correctly found. Unfortunately, they are only filled during fresh installs and not during > upgrades. I filed a BZ for this issue: > > https://bugzilla.redhat.com/show_bug.cgi?id=746589 > > > If you want to try this feature, you can either try a fresh install or > add the data from /usr/share/ipa/automember.ldif to your LDAP server (of course, $SUFFIX needs to > be expanded). > Ok, thanks. I will try to add that LDIF. Regards, Siggi From g17jimmy at gmail.com Mon Oct 17 13:18:56 2011 From: g17jimmy at gmail.com (Jimmy Caldwell) Date: Mon, 17 Oct 2011 09:18:56 -0400 Subject: [Freeipa-users] Preauth pkinit failed to initialize Message-ID: <4671765086289583095@unknownmsgid> Freeipa will not start, suddenly. To my knowledge nothing changed since the time I knew it to start and now I'm getting these errors: In the krb5kdc log- (error): Preauth pkinit failed to initialize: no realms configured correctly for pkinit support In /var/log/messages- [named] failed to init credentials (client 'DNS/realm' not found in Kerberos database) Sent from my mobile device From simo at redhat.com Mon Oct 17 14:18:06 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 17 Oct 2011 10:18:06 -0400 Subject: [Freeipa-users] Preauth pkinit failed to initialize In-Reply-To: <4671765086289583095@unknownmsgid> References: <4671765086289583095@unknownmsgid> Message-ID: <1318861086.31149.175.camel@willson.li.ssimo.org> On Mon, 2011-10-17 at 09:18 -0400, Jimmy Caldwell wrote: > Freeipa will not start, suddenly. To my knowledge nothing changed > since the time I knew it to start and now I'm getting these errors: > > In the krb5kdc log- > (error): Preauth pkinit failed to initialize: no realms configured > correctly for pkinit support This shouldn't be fatal and should probably be ignored. > In /var/log/messages- > [named] failed to init credentials (client 'DNS/realm' not found in > Kerberos database) This means the KDC probably can't contact the LDAP server (unless someone removed the DNS service entry). Can you check your directory server is up and has it's ports open ? We had an upgrade issue some times back where a rpm upgrade would fail to properly update dse.lidf and would cause DS to not open ports for other apps. You may want to check if that's the case. Simo. -- Simo Sorce * Red Hat, Inc * New York From g17jimmy at gmail.com Mon Oct 17 14:22:14 2011 From: g17jimmy at gmail.com (Jimmy) Date: Mon, 17 Oct 2011 10:22:14 -0400 Subject: [Freeipa-users] Preauth pkinit failed to initialize In-Reply-To: <1318861086.31149.175.camel@willson.li.ssimo.org> References: <4671765086289583095@unknownmsgid> <1318861086.31149.175.camel@willson.li.ssimo.org> Message-ID: It seems that the dirsrv doesn't start and once named fails to start the startup of ipa halts and shuts everything down. I rolled back to a previous snapshot of the VM and it's working. I kept the broken instance and will debug further later this week. I'll post more to the list when I get back to it. - Jimmy On Mon, Oct 17, 2011 at 10:18 AM, Simo Sorce wrote: > On Mon, 2011-10-17 at 09:18 -0400, Jimmy Caldwell wrote: > > Freeipa will not start, suddenly. To my knowledge nothing changed > > since the time I knew it to start and now I'm getting these errors: > > > > In the krb5kdc log- > > (error): Preauth pkinit failed to initialize: no realms configured > > correctly for pkinit support > > This shouldn't be fatal and should probably be ignored. > > > In /var/log/messages- > > [named] failed to init credentials (client 'DNS/realm' not found in > > Kerberos database) > > This means the KDC probably can't contact the LDAP server (unless > someone removed the DNS service entry). > > Can you check your directory server is up and has it's ports open ? > > We had an upgrade issue some times back where a rpm upgrade would fail > to properly update dse.lidf and would cause DS to not open ports for > other apps. > You may want to check if that's the case. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Oct 18 02:36:27 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 18 Oct 2011 02:36:27 +0000 Subject: [Freeipa-users] Complaint web browsers Message-ID: <833D8E48405E064EBC54C84EC6B36E40446680BA@STAWINCOX10MBX4.staff.vuw.ac.nz> Hi, I have only used Firefox 3.x as shipped with RHEL to admin IPA, what are others using? ie what are compliant/suitable? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From ayoung at redhat.com Tue Oct 18 13:32:00 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 18 Oct 2011 09:32:00 -0400 Subject: [Freeipa-users] Complaint web browsers In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40446680BA@STAWINCOX10MBX4.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40446680BA@STAWINCOX10MBX4.staff.vuw.ac.nz> Message-ID: <4E9D7FD0.3010805@redhat.com> On 10/17/2011 10:36 PM, Steven Jones wrote: > Hi, > > I have only used Firefox 3.x as shipped with RHEL to admin IPA, what are others using? ie what are compliant/suitable? We are only claiming to support Firefox, 3 on forward should all work, but we only test the versions with Fedora and RHEL. Chrome will work, but you need to set up Kerberos Ticket Forwarding, which means setting an ENV VAR prior to running. Have not tested on IE recently. Have reason to think it might be broke, but the Kerberos requirement makes it a non-starter for real deployments. Safari has been fairly well tested. Again, Kerberos setup is a little bit of effort. > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From Duncan.Innes at virginmoney.com Tue Oct 18 15:52:24 2011 From: Duncan.Innes at virginmoney.com (Duncan.Innes at virginmoney.com) Date: Tue, 18 Oct 2011 16:52:24 +0100 Subject: [Freeipa-users] Complaint web browsers In-Reply-To: <4E9D7FD0.3010805@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40446680BA@STAWINCOX10MBX4.staff.vuw.ac.nz> <4E9D7FD0.3010805@redhat.com> Message-ID: Just as a pointer here - It would be good if there was ubiquitous support amongst the browsers. I understand the whole concept behind "we test what we ship with", but we're no longer talking about huge differences between browsers these days. Would it be possible to look at shipping a WebUI which is usable from all the major browsers? (I realise the term "major browsers" already provides a grey area, but it would certainly include IE, Chrome, Firefox and Safari - Opera optional). Having been forced to use IE6 in the bad old days because of HP iLO, it would be good to differentiate ourselves from those times by providing support across a wide base of browsers. I'm not just talking about Free-IPA here - I first encountered the problem by being told that using Chrome with RHN Satellite is unsupported. Just strikes me as somewhat narrow to refuse to support the most used products out there. Who knows if your admin is running Windows, Mac or Linux desktop? Cheers Duncan From: Adam Young To: freeipa-users at redhat.com Date: 18/10/2011 14:34 Subject: Re: [Freeipa-users] Complaint web browsers Sent by: freeipa-users-bounces at redhat.com On 10/17/2011 10:36 PM, Steven Jones wrote: > Hi, > > I have only used Firefox 3.x as shipped with RHEL to admin IPA, what are others using? ie what are compliant/suitable? We are only claiming to support Firefox, 3 on forward should all work, but we only test the versions with Fedora and RHEL. Chrome will work, but you need to set up Kerberos Ticket Forwarding, which means setting an ENV VAR prior to running. Have not tested on IE recently. Have reason to think it might be broke, but the Kerberos requirement makes it a non-starter for real deployments. Safari has been fairly well tested. Again, Kerberos setup is a little bit of effort. > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money do not accept responsibility for changes made to any e-mail after sending. Virgin Money have swept, and believe this e-mail to be free of viruses and profanity but make no guarantees to this effect. Virgin Money Personal Financial Service Ltd is authorised and regulated by the Financial Services Authority. Registered in England no. 3072766. Entered on the Financial Services Authority's Register http://www.fsa.gov.uk/register/. Register Number 179271. The Virgin Deposit Account and the Virgin Cash ISA are both personal deposit accounts with Virgin Bank Ltd administered by Virgin Money Personal Financial Service Ltd. Virgin Bank Ltd is authorised and regulated by the Financial Services Authority. Registered in England no. 980698. Entered on the Financial Services Authority's Register http://www.fsa.gov.uk/register/. Register Number 204459. Virgin Money Unit Trust Managers Ltd is authorised and regulated by the Financial Services Authority. Registered in England no. 3000482. Entered on the Financial Services Authority's Register. Register Number 171748. Virgin Money Ltd. Registered in England no. 4232392. Introducer appointed representative only of Virgin Money Personal Financial Service Ltd. Virgin Money Management Services Ltd. Registered in England no.3072772. Virgin Money Holdings (UK) Limited. Registered in England no.3087587. All the above companies have their Registered office at Discovery House, Whiting Road, Norwich NR4 6EJ. All products are open only to residents of the United Kingdom. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bene at hkl.hms.harvard.edu Tue Oct 18 15:59:21 2011 From: bene at hkl.hms.harvard.edu (Ben Eisenbraun) Date: Tue, 18 Oct 2011 11:59:21 -0400 Subject: [Freeipa-users] Complaint web browsers In-Reply-To: References: <833D8E48405E064EBC54C84EC6B36E40446680BA@STAWINCOX10MBX4.staff.vuw.ac.nz> <4E9D7FD0.3010805@redhat.com> Message-ID: <20111018155920.GA339@crystal.harvard.edu> On Tue, Oct 18, 2011 at 04:52:24PM +0100, Duncan.Innes at virginmoney.com wrote: > Who knows if your admin is running Windows, Mac or Linux desktop? And that's the beauty of standardizing on Firefox support: it doesn't matter, since Firefox runs on all those platforms (and more). Given that engineering time is expensive, I would rather see that time spent on fixing bugs and adding new features than on trying to support other browers. 2 cents, etc. -ben -- | Ben Eisenbraun | SBGrid Consortium | http://sbgrid.org | | Harvard Medical School | http://hms.harvard.edu | From sgallagh at redhat.com Tue Oct 18 17:17:15 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 18 Oct 2011 13:17:15 -0400 Subject: [Freeipa-users] Complaint web browsers In-Reply-To: References: <833D8E48405E064EBC54C84EC6B36E40446680BA@STAWINCOX10MBX4.staff.vuw.ac.nz> <4E9D7FD0.3010805@redhat.com> Message-ID: <1318958235.2323.15.camel@sgallagh520.ipa.sgallagh.bos.redhat.com> On Tue, 2011-10-18 at 16:52 +0100, Duncan.Innes at virginmoney.com wrote: > Just as a pointer here - It would be good if there was ubiquitous > support amongst the browsers. I understand the whole concept behind > "we test what we ship with", but we're no longer talking about huge > differences between browsers these days. Would it be possible to look Unfortunately, this is not true for the internals of the browsers. In general, they're all pretty standardized these days on how a page should look but they vary wildly in how they manage some features, like authentication in any way other than HTTP-BASIC. Specifically, they all support Kerberos to varying degrees. Each browser requires a completely different mechanism for configuring the use of Kerberos so that it can be passed to the web server. The one that is both most complete in its support and most simplistic to configure is Firefox, which is why it is the only officially supported browser at this time. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From Steven.Jones at vuw.ac.nz Tue Oct 18 19:21:53 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 18 Oct 2011 19:21:53 +0000 Subject: [Freeipa-users] Complaint web browsers In-Reply-To: <20111018155920.GA339@crystal.harvard.edu> References: <833D8E48405E064EBC54C84EC6B36E40446680BA@STAWINCOX10MBX4.staff.vuw.ac.nz> <4E9D7FD0.3010805@redhat.com> , <20111018155920.GA339@crystal.harvard.edu> Message-ID: <833D8E48405E064EBC54C84EC6B36E404569E69A@STAWINDRXMAIL01.staff.vuw.ac.nz> Hi, Out in the real world however..... Problem is when you come to a Windows dominated environment and you have ex-windows managers, windows admins and windows useradmins and a windows help desk who only want to use IE because that's all they understand. They look for any excuse to not let me deploy a piece of Linux orientated kit, so being forced to run Firefox might be it. You may not appreciate the battles I have to get anything Linux on site despite having 80%+ of the academics behind me, plus the 600 Mac users who feel like second hand citizens because of above attitude. It may seem crazy that something so minor to some is an issue but the reality is that's how small some ppls minds are and they are in charge...... Also some sites dont allow installation of anything but a particular browser.... >From my perspective I already have to run IE for something's because Firefox doesnt work java based hardware being a classic example.....this means I have to run a virtual Windows machine or remove Windows from my desktop and use Win7..... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Ben Eisenbraun [bene at hkl.hms.harvard.edu] Sent: Wednesday, 19 October 2011 4:59 a.m. To: Duncan.Innes at virginmoney.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Complaint web browsers On Tue, Oct 18, 2011 at 04:52:24PM +0100, Duncan.Innes at virginmoney.com wrote: > Who knows if your admin is running Windows, Mac or Linux desktop? And that's the beauty of standardizing on Firefox support: it doesn't matter, since Firefox runs on all those platforms (and more). Given that engineering time is expensive, I would rather see that time spent on fixing bugs and adding new features than on trying to support other browers. 2 cents, etc. -ben -- | Ben Eisenbraun | SBGrid Consortium | http://sbgrid.org | | Harvard Medical School | http://hms.harvard.edu | _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From simo at redhat.com Tue Oct 18 19:35:02 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 18 Oct 2011 15:35:02 -0400 Subject: [Freeipa-users] Complaint web browsers In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404569E69A@STAWINDRXMAIL01.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40446680BA@STAWINCOX10MBX4.staff.vuw.ac.nz> <4E9D7FD0.3010805@redhat.com> , <20111018155920.GA339@crystal.harvard.edu> <833D8E48405E064EBC54C84EC6B36E404569E69A@STAWINDRXMAIL01.staff.vuw.ac.nz> Message-ID: <1318966502.17448.1.camel@willson.li.ssimo.org> On Tue, 2011-10-18 at 19:21 +0000, Steven Jones wrote: > Hi, > > Out in the real world however..... > > Problem is when you come to a Windows dominated environment and you > have ex-windows managers, windows admins and windows useradmins and a > windows help desk who only want to use IE because that's all they > understand. They look for any excuse to not let me deploy a piece of > Linux orientated kit, so being forced to run Firefox might be it. You > may not appreciate the battles I have to get anything Linux on site > despite having 80%+ of the academics behind me, plus the 600 Mac users > who feel like second hand citizens because of above attitude. > > It may seem crazy that something so minor to some is an issue but the > reality is that's how small some ppls minds are and they are in > charge...... > > Also some sites dont allow installation of anything but a particular > browser.... I sympathize I have been an admin and a consultant at Universities in the distant past. Please file bugs you encounter with IE and we will see if we can help you out, but I cannot promise IE will work perfectly in the immediate future. Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Tue Oct 18 20:37:10 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 18 Oct 2011 20:37:10 +0000 Subject: [Freeipa-users] Complaint web browsers In-Reply-To: <1318966502.17448.1.camel@willson.li.ssimo.org> References: <833D8E48405E064EBC54C84EC6B36E40446680BA@STAWINCOX10MBX4.staff.vuw.ac.nz> <4E9D7FD0.3010805@redhat.com> , <20111018155920.GA339@crystal.harvard.edu> <833D8E48405E064EBC54C84EC6B36E404569E69A@STAWINDRXMAIL01.staff.vuw.ac.nz>, <1318966502.17448.1.camel@willson.li.ssimo.org> Message-ID: <833D8E48405E064EBC54C84EC6B36E40456A59D2@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Im trying to get a PoC (proof of concept) off the ground so I have to submit a business case.....which as a techy is very hard.... :/ So IE "bugs" is something for the hopefully not to distant future. Its also not just Uni's Ive worked in several organisations who are also quite bad.....in fact Uni's tend to be more open in that Firefox is allowed to be installed..... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Simo Sorce [simo at redhat.com] Sent: Wednesday, 19 October 2011 8:35 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Complaint web browsers On Tue, 2011-10-18 at 19:21 +0000, Steven Jones wrote: > Hi, > > Out in the real world however..... > > Problem is when you come to a Windows dominated environment and you > have ex-windows managers, windows admins and windows useradmins and a > windows help desk who only want to use IE because that's all they > understand. They look for any excuse to not let me deploy a piece of > Linux orientated kit, so being forced to run Firefox might be it. You > may not appreciate the battles I have to get anything Linux on site > despite having 80%+ of the academics behind me, plus the 600 Mac users > who feel like second hand citizens because of above attitude. > > It may seem crazy that something so minor to some is an issue but the > reality is that's how small some ppls minds are and they are in > charge...... > > Also some sites dont allow installation of anything but a particular > browser.... I sympathize I have been an admin and a consultant at Universities in the distant past. Please file bugs you encounter with IE and we will see if we can help you out, but I cannot promise IE will work perfectly in the immediate future. Simo. -- Simo Sorce * Red Hat, Inc * New York From ayoung at redhat.com Tue Oct 18 21:52:18 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 18 Oct 2011 17:52:18 -0400 Subject: [Freeipa-users] Complaint web browsers In-Reply-To: <1318958235.2323.15.camel@sgallagh520.ipa.sgallagh.bos.redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40446680BA@STAWINCOX10MBX4.staff.vuw.ac.nz> <4E9D7FD0.3010805@redhat.com> <1318958235.2323.15.camel@sgallagh520.ipa.sgallagh.bos.redhat.com> Message-ID: <4E9DF512.6030706@redhat.com> Lets distinguish between Supported browsers for the kerberos case and the Supported browser for the Basic auth enabled case: For Kerberos, it is as I said previously: it will work on the others, but you have to know how to configure. You are not going to get IE Kerberos support without a significant headache, but even that is theoretically possible. Kerberos is going to be an issue from Windows no matter what. For Basic Auth, things are much easier, but that is the setup is just not that secure. So that would be fine for a proof of concept, we just don't recommend it in the wild. As far as the Javascript web app goes, we try to stick to features that work in all browsers. For example, you'll notice that we don't do any file uploads, as that is something that, in a AJAX application, is done with browser specific code. I can't promise that we will avoid browser specific solutions in the future, but if we do, it will be that you can do everything with either browser, but the user experience will be smoother on Firefox. If something is broken on a browser other than Firefox, please file a ticket, and be prepared to test it for us. https://fedorahosted.org/freeipa/report/12 . Make sure the component is Web UI. From Steven.Jones at vuw.ac.nz Tue Oct 18 22:17:13 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 18 Oct 2011 22:17:13 +0000 Subject: [Freeipa-users] Complaint web browsers In-Reply-To: <4E9DF512.6030706@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40446680BA@STAWINCOX10MBX4.staff.vuw.ac.nz> <4E9D7FD0.3010805@redhat.com> <1318958235.2323.15.camel@sgallagh520.ipa.sgallagh.bos.redhat.com>, <4E9DF512.6030706@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40456ADE25@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Thanks....I will file this for future ref/ammo..... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Adam Young [ayoung at redhat.com] Sent: Wednesday, 19 October 2011 10:52 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Complaint web browsers Lets distinguish between Supported browsers for the kerberos case and the Supported browser for the Basic auth enabled case: For Kerberos, it is as I said previously: it will work on the others, but you have to know how to configure. You are not going to get IE Kerberos support without a significant headache, but even that is theoretically possible. Kerberos is going to be an issue from Windows no matter what. For Basic Auth, things are much easier, but that is the setup is just not that secure. So that would be fine for a proof of concept, we just don't recommend it in the wild. As far as the Javascript web app goes, we try to stick to features that work in all browsers. For example, you'll notice that we don't do any file uploads, as that is something that, in a AJAX application, is done with browser specific code. I can't promise that we will avoid browser specific solutions in the future, but if we do, it will be that you can do everything with either browser, but the user experience will be smoother on Firefox. If something is broken on a browser other than Firefox, please file a ticket, and be prepared to test it for us. https://fedorahosted.org/freeipa/report/12 . Make sure the component is Web UI. _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From Steven at simplycircus.com Wed Oct 19 01:51:55 2011 From: Steven at simplycircus.com (Steven Santos) Date: Tue, 18 Oct 2011 21:51:55 -0400 Subject: [Freeipa-users] Centos 6 Message-ID: Any word on FreeIPA in Centos 6? --- Steven Santos Director P: 617-527-0667 F: 617-934-1870 E: Steven at SimplyCircus.com Simply Circus, Inc. 86 Los Angeles Street Newton, MA 02462 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Wed Oct 19 06:31:15 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 19 Oct 2011 08:31:15 +0200 (CEST) Subject: [Freeipa-users] Centos 6 In-Reply-To: References: Message-ID: <53449.192.168.210.177.1319005875.squirrel@www.nixtra.com> For the stable version I suppose you have to wait for CentOS 6.2, after RHEL 6.2 is out. At the moment even CentOS 6.1 hasn't been released, so I thin it will be a while. Have a look at Scientific Linux instead: http://www.scientificlinux.org/ They're already got a 6.1 release with updated pkgs not far behind RHEL 6.1. Regards, Siggi On Wed, October 19, 2011 03:51, Steven Santos wrote: > Any word on FreeIPA in Centos 6? > --- > Steven Santos > Director > P: 617-527-0667 > F: 617-934-1870 > E: Steven at SimplyCircus.com > > > Simply Circus, Inc. > 86 Los Angeles Street > Newton, MA 02462 > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Wed Oct 19 14:55:08 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Oct 2011 10:55:08 -0400 Subject: [Freeipa-users] Announcing FreeIPA 2.1.3 Message-ID: <4E9EE4CC.6020809@redhat.com> The FreeIPA team is proud to announce version 2.1.3. It can be downloaded from http://www.freeipa.org/Downloads == What happened to 2.1.2!? == Right after tagging 2.1.2 we found an upgrade issue that would have affected any users using the selfsign CA (installed with --selfsign). We decided to hold back the release, fix a few more bugs, and just push out 2.1.3 instead about a week later. So here we are. == Highlights in 2.1.3 == * Enforce that system hostname matches hostname of IPA server. * Require that /etc/hosts is sane even when configuring DNS. * Increase default server-side LDAP search limits. * Client enrollment improvements including longer wait for sssd to start, recovery if discovered IPA server is not responsive and when anonymous bind is disabled in 389-ds. == Highlights in 2.1.2 == * Upgrade older dogtag installs to use new PKI proxy configuration * hbactest improvements * Added platform-independent code to make ipa-client-install more portable * Make client uninstaller more robust, should restore state more completely. * UI usability improvements * Tool for Enabling/Disabling Managed Entry Plugins * Managed Entries configuration is now replicated * IPv6 client enrollment improvements * Man page improvements * Performance improvements when calculating indirect membership * Improved handling of disabled anonymous binds in 389-ds * user is now prompted to enter current password when changing to a new password * ipa server now support multiple namingContexts. ipa-client-install and password migration were fixed == Upgrading == === Server === To upgrade a 2.0.0, 2.0.1 or 2.1.0 server do the following: # yum update freeipa-server --enablerepo=updates-testing This will pull in updated freeIPA, 389-ds, dogtag, libcurl and xmlrpc-c packages (and perhaps some others). A script will be executed in the rpm postinstall phase to update the IPA LDAP server with any required changes. There is a bug reported against 389-ds, https://bugzilla.redhat.com/show_bug.cgi?id=730387, related to read-write locks. The NSPR RW lock implementation does not safely allow re-entrant use of reader locks. This is a timing issue so it is difficult to predict. During testing one user experienced this and the upgrade hung. To break the hang kill the ns-slapd process for your realm, wait for the yum transaction to complete, then restart 389-ds and manually run the update process: # service dirsrv start # ipa-ldap-updater --update === Client === The ipa-client-install tool in the ipa-client package is just a configuration tool. There should be no need to re-run this on every client already enrolled. == Detailed Changelog for 2.1.3 == Adam Young (1): * Fix dynamic display of UI tabs based on rights Alexander Bokovoy (8): * Increase number of 'getent passwd attempts' to 10 * Force kerberos realm to be a string * Include indirect membership and canonicalize hosts during HBAC rules testi ng * Refactor backup_and_replace_hostname() into a flexible config modification tool * Write KRB5REALM to /etc/sysconfig/krb5kdc and make use of common backup_config_and_replace_variables() tool * Refactor authconfig use in ipa-client-install * Document --preserve-sssd option of ipa-client-install * Use set class instead of dictview class as set is wider supported Jan Cholasta (3): * Disallow deletion of global password policy. * Don't leak passwords through kdb5_ldap_util command line arguments. * Remove more redundant configuration values from krb5.conf. John Dennis (1): * Fix Spanish po translation file Martin Kosek (12): * Improve default user/group object class validation * Fix i18n in config plugin * Fix dnszone-add name_from_ip server validation * Improve handling of GIDs when migrating groups * ipa-client-install hangs if the discovered server is unresponsive * Optimize member/memberof searches in LDAP * Make IPv4 address parsing more strict * Check hostname resolution sanity * Hostname used by IPA must be a system hostname * Check /etc/hosts file in ipa-server-install * Fix ipa-client-install -U option alignment * Improve hostgroup/netgroup collision checks Petr Vobornik (2): * Added missing fields to password policy page * Fixed: Unable to add external user for RunAs User for Sudo rules Rob Crittenden (12): * Fix DNS permissions and membership in privileges * Fix upgrades of selfsign server * Make ipa-join work against an LDAP server that disallows anon binds * Fix has_upg() to work with relocated managed entries configuration. * Work around limits not being updatable in 389-ds. * Save the value of hostname even if it doesn't appear in /etc/sysconfig/network * Add explicit instructions to ipa-replica-manage for winsync replication * Set min nvr of 389-ds-base to 1.2.10-0.4.a4 for limits fixes (740942, 742324) * Handle an empty value in a name/value pair in config_replace_variables() * Update all LDAP configuration files that we can. * If our domain is already configured in sssd.conf start with a new config. * Fix typo in invalid PTR record error message Simo Sorce (1): * updates: Change default limits on ldap searches == Detailed Changelog for 2.1.2 == Adam Young (4): * split metadata call * Make mod_nss renegotiation configuration a public function * Execute pki proxy setup when server is upgraded if needed * Force the upgrade of pki-setup when upgrading the RPMS Alexander Bokovoy (13): * Incorrect name in examples of ipa help hbactest * Unroll groups when testing HBAC rules * Introduce platform-specific adaptation for services used by FreeIPA. * Convert server install code to platform-independent access to system services * Convert client-side tools to platform-independent access to system services * Convert installation tools to platform-independent access to system services * Cleanup whitespace * When external host is specified in HBAC rule, allow its use in simulation * Unroll StrEnum values when displaying help * Configure pam_krb5 on the client only if sssd is not configured * Setup and restore ntp configuration on the client side properly * Fix 'referenced before assignment' warning * Before kinit, try to sync time with the NTP servers of the domain we are joining Endi S. Dewata (24): * Fixed unit test for entity select widget. * Fixed layout problem in permission adder dialog. * Fixed sudo rule association dialogs. * Fixed missing optional field. * Fixed labels for run-as users and groups. * Fixed problem opening host adder dialog. * Removed entitlement menu. * Fixed posix group checkbox. * Fixed columns in HBAC/sudo rules list pages. * Fixed missing cancel button in unprovisioning dialog. * Fixed problem enabling/disabling DNS zone. * Fixed problem enrolling member with the same name. * Modified dialog to use sections. * Removed undo flags from dialog field specs. * Fixed problem on combobox with search limit. * Fixed problem displaying special characters. * Fixed add/delete arrows position. * Fixed duplicate entries in enrollment dialog. * Updated color scheme. * Fixed tab and dialog widths. * Disable enroll button if nothing selected. * Fixed missing default shell field. * I18n clean-up. * Disable sudo options Delete button if nothing selected. JR Aquino (1): * Create Tool for Enabling/Disabling Managed Entry Plugins Jakub Hrozek (1): * Silence a compilation warning in ipa_kpasswd Jan Cholasta (6): * Check that install hostname matches the server hostname. * Fix client install on IPv6 machines. * Fix ipa-replica-prepare always warning the user about not using the system hostname. * Validate name_from_ip parameter of dnszone. * Add a function for formatting network locations of the form host:port for use in URLs. * Work around pkisilent bugs. Jr Aquino (1): * Move Managed Entries into their own container in the replicated space. Marko Myllynen (1): * Don't remove /tmp when removing temp cert dir Martin Kosek (21): * Improve man pages structure * Improve ipa-join man page * Fix permissions in installers * Fix configure.jar permissions * Set bind and bind-dyndb-ldap min nvr * Fix pylint false positive in hbactest module * ipactl does not stop dirsrv * dirsrv is not stopped correctly in the fallback * Remove checks for ds-replication plugin * Fix /usr/bin/ipa dupled server list * Revert "Always require SSL in the Kerberos authorization block." * Fix error messages in hbacrule * Fix LDAPCreate search failure * Fix HBAC tests hostnames * ipa-client assumes a single namingcontext * migrate process cannot handle multivalued pkey attribute * Be more clear about selfsign option * Install tools crash when password prompt is interrupted * Improve ipa-replica-prepare DNS check * Prevent collisions of hostgroup and netgroup * Make sure ipa-client-install returns correct error code Nalin Dahyabhai (2): * list users from nested groups, too * Update man pages to note that PKCS#12 files also contain private keys, and that the "pkinit" options refer to the KDC's credentials Petr Vobornik (10): * Fixed: JavaScript type error in entitlement page * Fixed inconsistency in enabling delete buttons * Code cleanup: widget creation * Fixed: Column header for attributes table should be full width * Fixed: Enrolment dialog offers to add entity to reflexive association. * Fixed: Some widgets do not have space for validation error message * Disables gid field if not posix group in group adder dialog * Fixed links to images in config and migration pages * Split Web UI initialization to several smaller calls #2 * Split Web UI initialization to several smaller calls Rob Crittenden (20): * Don't allow a OTP to be set on an enrolled host * Remove normalizer that made role, privilege and permission names lower-case * Improved handling for ipa-pki-proxy.conf * The precendence on the modrdn plugin was set in the wrong location. * Update ipa-ldap-updater man page saying it is not an end-user utility * Skip the cert validator if the csr we are passed in is a valid filename * Change the Requires for the server and server-selinux for proper order * Suppress managed netgroups as indirect members of hosts. * The return value of restorecon is not reliable, ignore it. * Normalize uid in user principal to lower-case and do validation * Shut down duplicated file handle when HTTP response code is not 200. * Don't log one-time password in logs when configuring client. * Always require SSL in the Kerberos authorization block. * Include failed service and service groups in hbac rule management * Add regular expression pattern to host names. * Detect CA installation type in ipa-replica-prepare and ipa-ca-install. * Require current password when using passwd to change your own password. * Migration: don't assume there is only one naming context, add logging. * When calculating indirect membership don't test nesting on users and hosts. Simo Sorce (4): * ipa-pwd-extop: Fix segfault in password change. * ipa-pwd-extop: Enforce old password checks * ipa-client-install: Fix joining when LDAP access is restricted * replica-prepare: anonymous binds may be disallowed Sumit Bose (2): * Call standard_logging_setup() before any logging is done * ipa-pwd-extop: allow password change on all connections with SSF>1 Yuri Chornoivan (1): * Fix typos From dpal at redhat.com Wed Oct 19 17:53:05 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Oct 2011 13:53:05 -0400 Subject: [Freeipa-users] Extending schema In-Reply-To: <4E9B4441.2090505@nixtra.com> References: <4E9B4441.2090505@nixtra.com> Message-ID: <4E9F0E81.9000007@redhat.com> On 10/16/2011 04:53 PM, Sigbjorn Lie wrote: > On 10/14/2011 03:14 PM, Jenny Galipeau wrote: >> >> ----- Original Message ----- >>> On Thu, 2011-10-13 at 15:44 +0200, Sigbjorn Lie wrote: >>>> Hi, >>>> >>>> What is your recommendations for avoiding incompatability with >>>> future upgrades of IPA if extending >>>> the dirsrv schema and adding custom objects to the LDAP server is >>>> required? What considerations >>>> and precautions should be taken? >>>> >>>> Such as adding RBAC support for Solaris clients... >>> Additional schema is unlikely to cause issues if it does not conflict >>> with standard schema. We also tend to prefix all the >>> attributes/objectlasses we create for FreeIPA so name clashes are >>> unlikely. >>> If it is custom schema I suggest you to prefix names appropriately >>> too, >>> so you have your own 'namespace'. >>> >>> As for placement I suggest you put this data in a separate container >>> from standard FreeIPA stuff for new objects. >>> >>> In the base DN create a container named something like your company >>> name >>> or ticker: cn=ACME, and put all your customized entries >>> there. >>> >>> Attaching additional data to users is not a big deal for custom >>> schema. >>> If it is not custom schema but standard schema not currently used by >>> FreeIPA I would be a little bit more careful as a following version >>> of >>> FreeIPA might conceivably start using those attributes, and there is >>> generally enough space to use them in a sort of 'incompatible' way. >>> >>> But don't let that stop you if you really need it. >> Please note that when adding additional objectclasses to users and/or >> group etc ... if there are required attributes in the new >> objectclasses, you will no longer be able to add these objects from >> Web UI and you will not be able to define values for the new >> attributes introduced from the Web UI withoutcustomization. You will >> have to use the CLI and the --setattr option with the command. > > Thank you both, I will keep that in mind. > > Since Solaris RBAC is what I need at this point, is there any plans of > including support for Solaris' RBAC at some point? No, not really. We found that very limiting for different applications and RBAC model is very different depending on the context and resources being deal with by the app. So we decided not to spend time on this effort but contributions are always welcome ;-) > > > Regards, > Siggi > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sigbjorn at nixtra.com Wed Oct 19 19:14:50 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 19 Oct 2011 21:14:50 +0200 Subject: [Freeipa-users] The concept of sites... Message-ID: <4E9F21AA.6090603@nixtra.com> Hi, Has there been given any thought to the concept of sites within IPA to improve cross-site implementations? This should be easy to implement as you are already using DNS SRV records to locate the ldap/kerberos servers. E.g. Site: Boston Site: London Create a subdomain of the IPA dns domain named _sites, and a subdomain of _sites for each site. Boston._sites.ipa.domain.com would contain the srv entries for IPA servers in Boston: _ldap._tcp in srv 0 100 389 boston-ipa-server1 _ldap._tcp in srv 0 100 389 boston-ipa-server2 ..... London._sites.ipa.domain.com would contain the srv entries for IPA serers in London: _ldap._tcp in srv 0 100 389 london-ipa-server1 _ldap._tcp in srv 0 100 389 london-ipa-server2 .... Now point the client's DNS "search" entry to point to the local site first, then search the full name space: Boston client's /etc/resolv.conf: search Boston._sites.ipa.domain.com ipa.domain.com London client's /etc/resolv.conf: search London._sites.ipa.domain.com ipa.domain.com The main ipa.domain.com could still contain srv records for all IPA servers, or selected IPA servers at the central hub. I know I can do this manually within the DNS managment in IPA today, however it would be a lot easier to maintain "Sites" within the IPA webui/cli. *blink* ;) What's your thoughts on this? Regards, Siggi From dpal at redhat.com Wed Oct 19 19:24:23 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Oct 2011 15:24:23 -0400 Subject: [Freeipa-users] The concept of sites... In-Reply-To: <4E9F21AA.6090603@nixtra.com> References: <4E9F21AA.6090603@nixtra.com> Message-ID: <4E9F23E7.5030801@redhat.com> On 10/19/2011 03:14 PM, Sigbjorn Lie wrote: > Hi, > > Has there been given any thought to the concept of sites within IPA to > improve cross-site implementations? This should be easy to implement > as you are already using DNS SRV records to locate the ldap/kerberos > servers. > > E.g. > Site: Boston > Site: London > > > Create a subdomain of the IPA dns domain named _sites, and a subdomain > of _sites for each site. > > Boston._sites.ipa.domain.com would contain the srv entries for IPA > servers in Boston: > _ldap._tcp in srv 0 100 389 boston-ipa-server1 > _ldap._tcp in srv 0 100 389 boston-ipa-server2 > ..... > > London._sites.ipa.domain.com would contain the srv entries for IPA > serers in London: > _ldap._tcp in srv 0 100 389 london-ipa-server1 > _ldap._tcp in srv 0 100 389 london-ipa-server2 > .... > > Now point the client's DNS "search" entry to point to the local site > first, then search the full name space: > Boston client's /etc/resolv.conf: > search Boston._sites.ipa.domain.com ipa.domain.com > > London client's /etc/resolv.conf: > search London._sites.ipa.domain.com ipa.domain.com > > > The main ipa.domain.com could still contain srv records for all IPA > servers, or selected IPA servers at the central hub. > > I know I can do this manually within the DNS managment in IPA today, > however it would be a lot easier to maintain "Sites" within the IPA > webui/cli. *blink* ;) > > What's your thoughts on this? > > > Please file an RFE in BZ. > Regards, > Siggi > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Wed Oct 19 19:27:07 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 19 Oct 2011 15:27:07 -0400 Subject: [Freeipa-users] The concept of sites... In-Reply-To: <4E9F23E7.5030801@redhat.com> References: <4E9F21AA.6090603@nixtra.com> <4E9F23E7.5030801@redhat.com> Message-ID: <1319052427.25154.16.camel@willson.li.ssimo.org> On Wed, 2011-10-19 at 15:24 -0400, Dmitri Pal wrote: > On 10/19/2011 03:14 PM, Sigbjorn Lie wrote: > > Hi, > > > > Has there been given any thought to the concept of sites within IPA to > > improve cross-site implementations? This should be easy to implement > > as you are already using DNS SRV records to locate the ldap/kerberos > > servers. > > > > E.g. > > Site: Boston > > Site: London > > > > > > Create a subdomain of the IPA dns domain named _sites, and a subdomain > > of _sites for each site. > > > > Boston._sites.ipa.domain.com would contain the srv entries for IPA > > servers in Boston: > > _ldap._tcp in srv 0 100 389 boston-ipa-server1 > > _ldap._tcp in srv 0 100 389 boston-ipa-server2 > > ..... > > > > London._sites.ipa.domain.com would contain the srv entries for IPA > > serers in London: > > _ldap._tcp in srv 0 100 389 london-ipa-server1 > > _ldap._tcp in srv 0 100 389 london-ipa-server2 > > .... > > > > Now point the client's DNS "search" entry to point to the local site > > first, then search the full name space: > > Boston client's /etc/resolv.conf: > > search Boston._sites.ipa.domain.com ipa.domain.com > > > > London client's /etc/resolv.conf: > > search London._sites.ipa.domain.com ipa.domain.com > > > > > > The main ipa.domain.com could still contain srv records for all IPA > > servers, or selected IPA servers at the central hub. > > > > I know I can do this manually within the DNS managment in IPA today, > > however it would be a lot easier to maintain "Sites" within the IPA > > webui/cli. *blink* ;) > > > > What's your thoughts on this? > > > > > > > Please file an RFE in BZ. Please take a look at this document before filing any bz: http://freeipa.org/page/DNS_Location_Discovery Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Wed Oct 19 19:30:29 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 19 Oct 2011 19:30:29 +0000 Subject: [Freeipa-users] The concept of sites... In-Reply-To: <4E9F21AA.6090603@nixtra.com> References: <4E9F21AA.6090603@nixtra.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40456BAAD0@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I think AD sort of does this which they have now backed away from? >From my very limited understanding having sub-domains/realms seems to be counter-productive....in that trying to do cross-realm trusts/passwords/user info becomes a nightmare? I know somehow I have to get unix.vuw.ac.nz to talk to staff.vuw.ac.nz and student.vuw.ac.nz in a winsync (password) agreement, I dont know even if that's possible? Yet with a flat domain to flat domain its easy? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie [sigbjorn at nixtra.com] Sent: Thursday, 20 October 2011 8:14 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] The concept of sites... Hi, Has there been given any thought to the concept of sites within IPA to improve cross-site implementations? This should be easy to implement as you are already using DNS SRV records to locate the ldap/kerberos servers. E.g. Site: Boston Site: London Create a subdomain of the IPA dns domain named _sites, and a subdomain of _sites for each site. Boston._sites.ipa.domain.com would contain the srv entries for IPA servers in Boston: _ldap._tcp in srv 0 100 389 boston-ipa-server1 _ldap._tcp in srv 0 100 389 boston-ipa-server2 ..... London._sites.ipa.domain.com would contain the srv entries for IPA serers in London: _ldap._tcp in srv 0 100 389 london-ipa-server1 _ldap._tcp in srv 0 100 389 london-ipa-server2 .... Now point the client's DNS "search" entry to point to the local site first, then search the full name space: Boston client's /etc/resolv.conf: search Boston._sites.ipa.domain.com ipa.domain.com London client's /etc/resolv.conf: search London._sites.ipa.domain.com ipa.domain.com The main ipa.domain.com could still contain srv records for all IPA servers, or selected IPA servers at the central hub. I know I can do this manually within the DNS managment in IPA today, however it would be a lot easier to maintain "Sites" within the IPA webui/cli. *blink* ;) What's your thoughts on this? Regards, Siggi _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From danieljamesscott at gmail.com Wed Oct 19 20:05:11 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 19 Oct 2011 16:05:11 -0400 Subject: [Freeipa-users] Problem when SSHing into FreeIPA client Message-ID: Hi, I am having some problems when SSHing into my Fedora 15 client which is authenticated using FreeIPA djscott at pc35:~$ ssh admin at pc35 admin at pc35's password: id: cannot find name for user ID 1812600000 id: cannot find name for user ID 1812600000 [I have no name!@pc35 ~]$ logout Connection to pc35 closed. I've attached the output from /var/log/secure and my sssd.conf (santitzed) When running as my user, everything appears OK. The 'id' command returns the correct groups for my user and for the admin user: djscott at pc35:~$ id admin uid=1812600000(admin) gid=1812600000(admins) groups=1812600000(admins),1115(svnadmins) Any ideas what could be wrong? Does anyone have an example of a 'clean' sssd.conf for a standard FreeIPA configured client? I think mine has been modified so much that it's probably full of unnecessary junk. I'm running the latest FreeIPA and SSSD packages: djscott at pc35:~$ rpm -qa|grep "freeipa-client\|sssd" sssd-client-1.5.13-1.fc15.2.x86_64 freeipa-client-2.1.0-1.fc15.x86_64 sssd-1.5.13-1.fc15.2.x86_64 sssd-tools-1.5.13-1.fc15.2.x86_64 djscott at pc35:~$ Thanks, Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: secure Type: application/octet-stream Size: 3732 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd.conf Type: application/octet-stream Size: 1000 bytes Desc: not available URL: From sigbjorn at nixtra.com Wed Oct 19 20:11:50 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 19 Oct 2011 22:11:50 +0200 (CEST) Subject: [Freeipa-users] The concept of sites... In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40456BAAD0@STAWINCOX10MBX1.staff.vuw.ac .nz> References: <4E9F21AA.6090603@nixtra.com> <833D8E48405E064EBC54C84EC6B36E40456BAAD0@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <36360.192.168.211.11.1319055110.squirrel@www.nixtra.com> I see your point with a messy dns infrastructure, however this would happen in the background. You would still only have one kerberos realm per IPA instance. Rgds, Siggi On Wed, October 19, 2011 21:30, Steven Jones wrote: > Hi, > > > I think AD sort of does this which they have now backed away from? > > > From my very limited understanding having sub-domains/realms seems to be counter-productive....in > that trying to do cross-realm trusts/passwords/user info becomes a nightmare? > > I know somehow I have to get unix.vuw.ac.nz to talk to staff.vuw.ac.nz and student.vuw.ac.nz in a > winsync (password) agreement, I dont know even if that's possible? Yet with a flat domain to > flat domain its easy? > > regards > > Steven Jones > > > Technical Specialist - Linux RHCE > > > Victoria University, Wellington, NZ > > > 0064 4 463 6272 > > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn > Lie [sigbjorn at nixtra.com] > Sent: Thursday, 20 October 2011 8:14 a.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] The concept of sites... > > > Hi, > > > Has there been given any thought to the concept of sites within IPA to > improve cross-site implementations? This should be easy to implement as you are already using DNS > SRV records to locate the ldap/kerberos servers. > > > E.g. > Site: Boston > Site: London > > > > Create a subdomain of the IPA dns domain named _sites, and a subdomain > of _sites for each site. > > Boston._sites.ipa.domain.com would contain the srv entries for IPA > servers in Boston: _ldap._tcp in srv 0 100 389 boston-ipa-server1 > _ldap._tcp in srv 0 100 389 boston-ipa-server2 > ..... > > > London._sites.ipa.domain.com would contain the srv entries for IPA > serers in London: _ldap._tcp in srv 0 100 389 london-ipa-server1 > _ldap._tcp in srv 0 100 389 london-ipa-server2 > .... > > > Now point the client's DNS "search" entry to point to the local site > first, then search the full name space: Boston client's /etc/resolv.conf: > search Boston._sites.ipa.domain.com ipa.domain.com > > London client's /etc/resolv.conf: > search London._sites.ipa.domain.com ipa.domain.com > > > The main ipa.domain.com could still contain srv records for all IPA > servers, or selected IPA servers at the central hub. > > I know I can do this manually within the DNS managment in IPA today, > however it would be a lot easier to maintain "Sites" within the IPA webui/cli. *blink* ;) > > What's your thoughts on this? > > > > > Regards, > Siggi > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > From Steven.Jones at vuw.ac.nz Wed Oct 19 20:15:15 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 19 Oct 2011 20:15:15 +0000 Subject: [Freeipa-users] The concept of sites... In-Reply-To: <36360.192.168.211.11.1319055110.squirrel@www.nixtra.com> References: <4E9F21AA.6090603@nixtra.com> <833D8E48405E064EBC54C84EC6B36E40456BAAD0@STAWINCOX10MBX1.staff.vuw.ac.nz>, <36360.192.168.211.11.1319055110.squirrel@www.nixtra.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40456BABC3@STAWINCOX10MBX1.staff.vuw.ac.nz> Ah right, yes, one realm. However how would you password sync with AD? So say London.ad.ms.com and Newyork.ad.ms.com With NY as the "head" So with london.ipa.unix.com and newyork.ipa.unix.com Is there still only one winsync agreement? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Sigbjorn Lie [sigbjorn at nixtra.com] Sent: Thursday, 20 October 2011 9:11 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: RE: [Freeipa-users] The concept of sites... I see your point with a messy dns infrastructure, however this would happen in the background. You would still only have one kerberos realm per IPA instance. Rgds, Siggi On Wed, October 19, 2011 21:30, Steven Jones wrote: > Hi, > > > I think AD sort of does this which they have now backed away from? > > > From my very limited understanding having sub-domains/realms seems to be counter-productive....in > that trying to do cross-realm trusts/passwords/user info becomes a nightmare? > > I know somehow I have to get unix.vuw.ac.nz to talk to staff.vuw.ac.nz and student.vuw.ac.nz in a > winsync (password) agreement, I dont know even if that's possible? Yet with a flat domain to > flat domain its easy? > > regards > > Steven Jones > > > Technical Specialist - Linux RHCE > > > Victoria University, Wellington, NZ > > > 0064 4 463 6272 > > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn > Lie [sigbjorn at nixtra.com] > Sent: Thursday, 20 October 2011 8:14 a.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] The concept of sites... > > > Hi, > > > Has there been given any thought to the concept of sites within IPA to > improve cross-site implementations? This should be easy to implement as you are already using DNS > SRV records to locate the ldap/kerberos servers. > > > E.g. > Site: Boston > Site: London > > > > Create a subdomain of the IPA dns domain named _sites, and a subdomain > of _sites for each site. > > Boston._sites.ipa.domain.com would contain the srv entries for IPA > servers in Boston: _ldap._tcp in srv 0 100 389 boston-ipa-server1 > _ldap._tcp in srv 0 100 389 boston-ipa-server2 > ..... > > > London._sites.ipa.domain.com would contain the srv entries for IPA > serers in London: _ldap._tcp in srv 0 100 389 london-ipa-server1 > _ldap._tcp in srv 0 100 389 london-ipa-server2 > .... > > > Now point the client's DNS "search" entry to point to the local site > first, then search the full name space: Boston client's /etc/resolv.conf: > search Boston._sites.ipa.domain.com ipa.domain.com > > London client's /etc/resolv.conf: > search London._sites.ipa.domain.com ipa.domain.com > > > The main ipa.domain.com could still contain srv records for all IPA > servers, or selected IPA servers at the central hub. > > I know I can do this manually within the DNS managment in IPA today, > however it would be a lot easier to maintain "Sites" within the IPA webui/cli. *blink* ;) > > What's your thoughts on this? > > > > > Regards, > Siggi > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > From sigbjorn at nixtra.com Wed Oct 19 20:21:40 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 19 Oct 2011 22:21:40 +0200 (CEST) Subject: [Freeipa-users] The concept of sites... In-Reply-To: <1319052427.25154.16.camel@willson.li.ssimo.org> References: <4E9F21AA.6090603@nixtra.com> <4E9F23E7.5030801@redhat.com> <1319052427.25154.16.camel@willson.li.ssimo.org> Message-ID: <38013.192.168.211.11.1319055700.squirrel@www.nixtra.com> On Wed, October 19, 2011 21:27, Simo Sorce wrote: > On Wed, 2011-10-19 at 15:24 -0400, Dmitri Pal wrote: > >> On 10/19/2011 03:14 PM, Sigbjorn Lie wrote: >> >>> Hi, >>> >>> >>> Has there been given any thought to the concept of sites within IPA to >>> improve cross-site implementations? This should be easy to implement as you are already using >>> DNS SRV records to locate the ldap/kerberos >>> servers. >>> >>> E.g. >>> Site: Boston >>> Site: London >>> >>> >>> >>> Create a subdomain of the IPA dns domain named _sites, and a subdomain >>> of _sites for each site. >>> >>> Boston._sites.ipa.domain.com would contain the srv entries for IPA >>> servers in Boston: _ldap._tcp in srv 0 100 389 boston-ipa-server1 >>> _ldap._tcp in srv 0 100 389 boston-ipa-server2 >>> ..... >>> >>> >>> London._sites.ipa.domain.com would contain the srv entries for IPA >>> serers in London: _ldap._tcp in srv 0 100 389 london-ipa-server1 >>> _ldap._tcp in srv 0 100 389 london-ipa-server2 >>> .... >>> >>> >>> Now point the client's DNS "search" entry to point to the local site >>> first, then search the full name space: Boston client's /etc/resolv.conf: >>> search Boston._sites.ipa.domain.com ipa.domain.com >>> >>> London client's /etc/resolv.conf: >>> search London._sites.ipa.domain.com ipa.domain.com >>> >>> >>> The main ipa.domain.com could still contain srv records for all IPA >>> servers, or selected IPA servers at the central hub. >>> >>> I know I can do this manually within the DNS managment in IPA today, >>> however it would be a lot easier to maintain "Sites" within the IPA webui/cli. *blink* ;) >>> >>> What's your thoughts on this? >>> >>> >>> >>> >> Please file an RFE in BZ. >> > > Please take a look at this document before filing any bz: > http://freeipa.org/page/DNS_Location_Discovery > SPF uses TXT records. Could the SUBNET dns records be substituted with TXT records? Use the configured LDAP base as dns search as fallback if there is no records found in the dns domain given by the dhcp server? I understand that was your major conserns? Rgds, Siggi From sigbjorn at nixtra.com Wed Oct 19 20:25:48 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 19 Oct 2011 22:25:48 +0200 (CEST) Subject: [Freeipa-users] The concept of sites... In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40456BABC3@STAWINCOX10MBX1.staff.vuw.ac .nz> References: <4E9F21AA.6090603@nixtra.com> <833D8E48405E064EBC54C84EC6B36E40456BAAD0@STAWINCOX10MBX1.staff.vuw.ac.nz>, <36360.192.168.211.11.1319055110.squirrel@www.nixtra.com> <833D8E48405E064EBC54C84EC6B36E40456BABC3@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <34350.192.168.211.11.1319055948.squirrel@www.nixtra.com> The London/newyork dns sub-domains would be used for looking up srv records for the local kerberos/ldap servers only. The actual domain configured on the client and the kerberos and LDAP base would still be the ipa.domain.com. Sync with AD would still be done between ipa.domain.com <-> ad.domain.com. Rgds, Siggi On Wed, October 19, 2011 22:15, Steven Jones wrote: > Ah right, yes, one realm. > > > However how would you password sync with AD? > > > So say London.ad.ms.com and Newyork.ad.ms.com > > > With NY as the "head" > > > So with london.ipa.unix.com and newyork.ipa.unix.com > > > Is there still only one winsync agreement? > > > > > regards > > Steven Jones > > > Technical Specialist - Linux RHCE > > > Victoria University, Wellington, NZ > > > 0064 4 463 6272 > > > ________________________________________ > From: Sigbjorn Lie [sigbjorn at nixtra.com] > Sent: Thursday, 20 October 2011 9:11 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: RE: [Freeipa-users] The concept of sites... > > > I see your point with a messy dns infrastructure, however this would happen in the background. > > > You would still only have one kerberos realm per IPA instance. > > > > Rgds, > Siggi > > > > > > On Wed, October 19, 2011 21:30, Steven Jones wrote: > >> Hi, >> >> >> >> I think AD sort of does this which they have now backed away from? >> >> >> >> From my very limited understanding having sub-domains/realms seems to be >> counter-productive....in that trying to do cross-realm trusts/passwords/user info becomes a >> nightmare? >> >> I know somehow I have to get unix.vuw.ac.nz to talk to staff.vuw.ac.nz and student.vuw.ac.nz in >> a winsync (password) agreement, I dont know even if that's possible? Yet with a flat domain to >> flat domain its easy? >> >> regards >> >> Steven Jones >> >> >> >> Technical Specialist - Linux RHCE >> >> >> >> Victoria University, Wellington, NZ >> >> >> >> 0064 4 463 6272 >> >> >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn >> Lie [sigbjorn at nixtra.com] >> Sent: Thursday, 20 October 2011 8:14 a.m. >> To: freeipa-users at redhat.com >> Subject: [Freeipa-users] The concept of sites... >> >> >> >> Hi, >> >> >> >> Has there been given any thought to the concept of sites within IPA to >> improve cross-site implementations? This should be easy to implement as you are already using >> DNS >> SRV records to locate the ldap/kerberos servers. >> >> >> >> E.g. >> Site: Boston >> Site: London >> >> >> >> >> Create a subdomain of the IPA dns domain named _sites, and a subdomain >> of _sites for each site. >> >> Boston._sites.ipa.domain.com would contain the srv entries for IPA >> servers in Boston: _ldap._tcp in srv 0 100 389 boston-ipa-server1 _ldap._tcp >> in srv 0 100 389 boston-ipa-server2 ..... >> >> >> >> London._sites.ipa.domain.com would contain the srv entries for IPA >> serers in London: _ldap._tcp in srv 0 100 389 london-ipa-server1 _ldap._tcp >> in srv 0 100 389 london-ipa-server2 .... >> >> >> >> Now point the client's DNS "search" entry to point to the local site >> first, then search the full name space: Boston client's /etc/resolv.conf: search >> Boston._sites.ipa.domain.com ipa.domain.com >> >> >> London client's /etc/resolv.conf: >> search London._sites.ipa.domain.com ipa.domain.com >> >> >> The main ipa.domain.com could still contain srv records for all IPA >> servers, or selected IPA servers at the central hub. >> >> I know I can do this manually within the DNS managment in IPA today, >> however it would be a lot easier to maintain "Sites" within the IPA webui/cli. *blink* ;) >> >> What's your thoughts on this? >> >> >> >> >> >> Regards, >> Siggi >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > > From dpal at redhat.com Wed Oct 19 20:43:55 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Oct 2011 16:43:55 -0400 Subject: [Freeipa-users] Problem when SSHing into FreeIPA client In-Reply-To: References: Message-ID: <4E9F368B.3010803@redhat.com> On 10/19/2011 04:05 PM, Dan Scott wrote: > Hi, > > I am having some problems when SSHing into my Fedora 15 client which > is authenticated using FreeIPA > > djscott at pc35:~$ ssh admin at pc35 > admin at pc35's password: > id: cannot find name for user ID 1812600000 > id: cannot find name for user ID 1812600000 > [I have no name!@pc35 ~]$ logout > Connection to pc35 closed. > > I've attached the output from /var/log/secure and my sssd.conf (santitzed) > > When running as my user, everything appears OK. The 'id' command > returns the correct groups for my user and for the admin user: > > djscott at pc35:~$ id admin > uid=1812600000(admin) gid=1812600000(admins) > groups=1812600000(admins),1115(svnadmins) > > Any ideas what could be wrong? > > Does anyone have an example of a 'clean' sssd.conf for a standard > FreeIPA configured client? I think mine has been modified so much that > it's probably full of unnecessary junk. The simples way to get to the canonical sssd.conf is probably to uninstall the client and re-install it again. Please use ipa-client-install --uninstall to uninstall and then ipa-client-install to enroll. > I'm running the latest FreeIPA and SSSD packages: > > djscott at pc35:~$ rpm -qa|grep "freeipa-client\|sssd" > sssd-client-1.5.13-1.fc15.2.x86_64 > freeipa-client-2.1.0-1.fc15.x86_64 > sssd-1.5.13-1.fc15.2.x86_64 > sssd-tools-1.5.13-1.fc15.2.x86_64 > djscott at pc35:~$ > > Thanks, > > Dan > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jzeleny at redhat.com Wed Oct 19 20:57:58 2011 From: jzeleny at redhat.com (Jan Zeleny) Date: Wed, 19 Oct 2011 22:57:58 +0200 Subject: [Freeipa-users] Problem when SSHing into FreeIPA client In-Reply-To: <4E9F368B.3010803@redhat.com> References: <4E9F368B.3010803@redhat.com> Message-ID: <201110192257.58503.jzeleny@redhat.com> Dmitri Pal wrote: > On 10/19/2011 04:05 PM, Dan Scott wrote: > > Hi, > > > > I am having some problems when SSHing into my Fedora 15 client which > > is authenticated using FreeIPA > > > > djscott at pc35:~$ ssh admin at pc35 > > admin at pc35's password: > > id: cannot find name for user ID 1812600000 > > id: cannot find name for user ID 1812600000 > > [I have no name!@pc35 ~]$ logout > > Connection to pc35 closed. > > > > I've attached the output from /var/log/secure and my sssd.conf > > (santitzed) > > > > When running as my user, everything appears OK. The 'id' command > > returns the correct groups for my user and for the admin user: > > > > djscott at pc35:~$ id admin > > uid=1812600000(admin) gid=1812600000(admins) > > groups=1812600000(admins),1115(svnadmins) > > > > Any ideas what could be wrong? > > > > Does anyone have an example of a 'clean' sssd.conf for a standard > > FreeIPA configured client? I think mine has been modified so much that > > it's probably full of unnecessary junk. > > The simples way to get to the canonical sssd.conf is probably to > uninstall the client and re-install it again. > Please use ipa-client-install --uninstall to uninstall and then > ipa-client-install to enroll. If this doesn't work, could you please send sanitized log files of SSSD? > > > I'm running the latest FreeIPA and SSSD packages: > > > > djscott at pc35:~$ rpm -qa|grep "freeipa-client\|sssd" > > sssd-client-1.5.13-1.fc15.2.x86_64 > > freeipa-client-2.1.0-1.fc15.x86_64 > > sssd-1.5.13-1.fc15.2.x86_64 > > sssd-tools-1.5.13-1.fc15.2.x86_64 > > djscott at pc35:~$ > > > > Thanks, > > > > Dan > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users From danieljamesscott at gmail.com Wed Oct 19 21:21:12 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 19 Oct 2011 17:21:12 -0400 Subject: [Freeipa-users] Problem when SSHing into FreeIPA client In-Reply-To: <4E9F368B.3010803@redhat.com> References: <4E9F368B.3010803@redhat.com> Message-ID: Hi, On Wed, Oct 19, 2011 at 16:43, Dmitri Pal wrote: > On 10/19/2011 04:05 PM, Dan Scott wrote: > > Hi, > > I am having some problems when SSHing into my Fedora 15 client which > is authenticated using FreeIPA > > djscott at pc35:~$ ssh admin at pc35 > admin at pc35's password: > id: cannot find name for user ID 1812600000 > id: cannot find name for user ID 1812600000 > [I have no name!@pc35 ~]$ logout > Connection to pc35 closed. > > I've attached the output from /var/log/secure and my sssd.conf (santitzed) > > When running as my user, everything appears OK. The 'id' command > returns the correct groups for my user and for the admin user: > > djscott at pc35:~$ id admin > uid=1812600000(admin) gid=1812600000(admins) > groups=1812600000(admins),1115(svnadmins) > > Any ideas what could be wrong? > > Does anyone have an example of a 'clean' sssd.conf for a standard > FreeIPA configured client? I think mine has been modified so much that > it's probably full of unnecessary junk. > > The simples way to get to the canonical sssd.conf is probably to uninstall > the client and re-install it again. > Please use ipa-client-install --uninstall to uninstall and then > ipa-client-install to enroll. That seems to have done the trick, the sssd.conf is much cleaner now and admin SSHing works fine now. Thanks, Dan > I'm running the latest FreeIPA and SSSD packages: > > djscott at pc35:~$ rpm -qa|grep "freeipa-client\|sssd" > sssd-client-1.5.13-1.fc15.2.x86_64 > freeipa-client-2.1.0-1.fc15.x86_64 > sssd-1.5.13-1.fc15.2.x86_64 > sssd-tools-1.5.13-1.fc15.2.x86_64 > djscott at pc35:~$ > > Thanks, > > Dan > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From ondrejv at s3group.cz Thu Oct 20 07:02:27 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Thu, 20 Oct 2011 09:02:27 +0200 Subject: [Freeipa-users] The concept of sites... In-Reply-To: <34350.192.168.211.11.1319055948.squirrel@www.nixtra.com> References: <4E9F21AA.6090603@nixtra.com> <833D8E48405E064EBC54C84EC6B36E40456BAAD0@STAWINCOX10MBX1.staff.vuw.ac.nz>, <36360.192.168.211.11.1319055110.squirrel@www.nixtra.com> <833D8E48405E064EBC54C84EC6B36E40456BABC3@STAWINCOX10MBX1.staff.vuw.ac.nz> <34350.192.168.211.11.1319055948.squirrel@www.nixtra.com> Message-ID: <4E9FC783.3060708@s3group.cz> I have come across this already, BZ already created: https://fedorahosted.org/sssd/ticket/1032 On 10/19/2011 10:25 PM, Sigbjorn Lie wrote: > The London/newyork dns sub-domains would be used for looking up srv records for the local > kerberos/ldap servers only. The actual domain configured on the client and the kerberos and LDAP > base would still be the ipa.domain.com. > > Sync with AD would still be done between ipa.domain.com<-> ad.domain.com. > > > Rgds, > Siggi > > > On Wed, October 19, 2011 22:15, Steven Jones wrote: >> Ah right, yes, one realm. >> >> >> However how would you password sync with AD? >> >> >> So say London.ad.ms.com and Newyork.ad.ms.com >> >> >> With NY as the "head" >> >> >> So with london.ipa.unix.com and newyork.ipa.unix.com >> >> >> Is there still only one winsync agreement? >> >> >> >> >> regards >> >> Steven Jones >> >> >> Technical Specialist - Linux RHCE >> >> >> Victoria University, Wellington, NZ >> >> >> 0064 4 463 6272 >> >> >> ________________________________________ >> From: Sigbjorn Lie [sigbjorn at nixtra.com] >> Sent: Thursday, 20 October 2011 9:11 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: RE: [Freeipa-users] The concept of sites... >> >> >> I see your point with a messy dns infrastructure, however this would happen in the background. >> >> >> You would still only have one kerberos realm per IPA instance. >> >> >> >> Rgds, >> Siggi >> >> >> >> >> >> On Wed, October 19, 2011 21:30, Steven Jones wrote: >> >>> Hi, >>> >>> >>> >>> I think AD sort of does this which they have now backed away from? >>> >>> >>> >>> From my very limited understanding having sub-domains/realms seems to be >>> counter-productive....in that trying to do cross-realm trusts/passwords/user info becomes a >>> nightmare? >>> >>> I know somehow I have to get unix.vuw.ac.nz to talk to staff.vuw.ac.nz and student.vuw.ac.nz in >>> a winsync (password) agreement, I dont know even if that's possible? Yet with a flat domain to >>> flat domain its easy? >>> >>> regards >>> >>> Steven Jones >>> >>> >>> >>> Technical Specialist - Linux RHCE >>> >>> >>> >>> Victoria University, Wellington, NZ >>> >>> >>> >>> 0064 4 463 6272 >>> >>> >>> >>> ________________________________________ >>> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn >>> Lie [sigbjorn at nixtra.com] >>> Sent: Thursday, 20 October 2011 8:14 a.m. >>> To: freeipa-users at redhat.com >>> Subject: [Freeipa-users] The concept of sites... >>> >>> >>> >>> Hi, >>> >>> >>> >>> Has there been given any thought to the concept of sites within IPA to >>> improve cross-site implementations? This should be easy to implement as you are already using >>> DNS >>> SRV records to locate the ldap/kerberos servers. >>> >>> >>> >>> E.g. >>> Site: Boston >>> Site: London >>> >>> >>> >>> >>> Create a subdomain of the IPA dns domain named _sites, and a subdomain >>> of _sites for each site. >>> >>> Boston._sites.ipa.domain.com would contain the srv entries for IPA >>> servers in Boston: _ldap._tcp in srv 0 100 389 boston-ipa-server1 _ldap._tcp >>> in srv 0 100 389 boston-ipa-server2 ..... >>> >>> >>> >>> London._sites.ipa.domain.com would contain the srv entries for IPA >>> serers in London: _ldap._tcp in srv 0 100 389 london-ipa-server1 _ldap._tcp >>> in srv 0 100 389 london-ipa-server2 .... >>> >>> >>> >>> Now point the client's DNS "search" entry to point to the local site >>> first, then search the full name space: Boston client's /etc/resolv.conf: search >>> Boston._sites.ipa.domain.com ipa.domain.com >>> >>> >>> London client's /etc/resolv.conf: >>> search London._sites.ipa.domain.com ipa.domain.com >>> >>> >>> The main ipa.domain.com could still contain srv records for all IPA >>> servers, or selected IPA servers at the central hub. >>> >>> I know I can do this manually within the DNS managment in IPA today, >>> however it would be a lot easier to maintain "Sites" within the IPA webui/cli. *blink* ;) >>> >>> What's your thoughts on this? >>> >>> >>> >>> >>> >>> Regards, >>> Siggi >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Thu Oct 20 09:55:29 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 20 Oct 2011 11:55:29 +0200 (CEST) Subject: [Freeipa-users] The concept of sites... In-Reply-To: <4E9FC783.3060708@s3group.cz> References: <4E9F21AA.6090603@nixtra.com> <833D8E48405E064EBC54C84EC6B36E40456BAAD0@STAWINCOX10MBX1.staff.vuw.ac.nz>, <36360.192.168.211.11.1319055110.squirrel@www.nixtra.com> <833D8E48405E064EBC54C84EC6B36E40456BABC3@STAWINCOX10MBX1.staff.vuw.ac.nz> <34350.192.168.211.11.1319055948.squirrel@www.nixtra.com> <4E9FC783.3060708@s3group.cz> Message-ID: <22998.62.148.39.180.1319104529.squirrel@www.nixtra.com> Hi Ondrej, Thanks. That RFE is for SSSD client only. I would like to see the management of sites within the IPA webui/cli. Regards, Siggi On Thu, October 20, 2011 09:02, Ondrej Valousek wrote: > I have come across this already, BZ already created: > > > https://fedorahosted.org/sssd/ticket/1032 > > > On 10/19/2011 10:25 PM, Sigbjorn Lie wrote: > >> The London/newyork dns sub-domains would be used for looking up srv records for the local >> kerberos/ldap servers only. The actual domain configured on the client and the kerberos and LDAP >> base would still be the ipa.domain.com. >> >> Sync with AD would still be done between ipa.domain.com<-> ad.domain.com. >> >> >> >> Rgds, >> Siggi >> >> >> >> On Wed, October 19, 2011 22:15, Steven Jones wrote: >> >>> Ah right, yes, one realm. >>> >>> >>> >>> However how would you password sync with AD? >>> >>> >>> >>> So say London.ad.ms.com and Newyork.ad.ms.com >>> >>> >>> >>> With NY as the "head" >>> >>> >>> >>> So with london.ipa.unix.com and newyork.ipa.unix.com >>> >>> >>> >>> Is there still only one winsync agreement? >>> >>> >>> >>> >>> >>> regards >>> >>> Steven Jones >>> >>> >>> >>> Technical Specialist - Linux RHCE >>> >>> >>> >>> Victoria University, Wellington, NZ >>> >>> >>> >>> 0064 4 463 6272 >>> >>> >>> >>> ________________________________________ >>> From: Sigbjorn Lie [sigbjorn at nixtra.com] >>> Sent: Thursday, 20 October 2011 9:11 a.m. >>> To: Steven Jones >>> Cc: freeipa-users at redhat.com >>> Subject: RE: [Freeipa-users] The concept of sites... >>> >>> >>> >>> I see your point with a messy dns infrastructure, however this would happen in the >>> background. >>> >>> >>> You would still only have one kerberos realm per IPA instance. >>> >>> >>> >>> >>> Rgds, >>> Siggi >>> >>> >>> >>> >>> >>> >>> On Wed, October 19, 2011 21:30, Steven Jones wrote: >>> >>> >>>> Hi, >>>> >>>> >>>> >>>> >>>> I think AD sort of does this which they have now backed away from? >>>> >>>> >>>> >>>> >>>> From my very limited understanding having sub-domains/realms seems to be >>>> counter-productive....in that trying to do cross-realm trusts/passwords/user info becomes a >>>> nightmare? >>>> >>>> I know somehow I have to get unix.vuw.ac.nz to talk to staff.vuw.ac.nz and >>>> student.vuw.ac.nz in a winsync (password) agreement, I dont know even if that's possible? >>>> Yet with a flat domain to >>>> flat domain its easy? >>>> >>>> regards >>>> >>>> Steven Jones >>>> >>>> >>>> >>>> >>>> Technical Specialist - Linux RHCE >>>> >>>> >>>> >>>> >>>> Victoria University, Wellington, NZ >>>> >>>> >>>> >>>> >>>> 0064 4 463 6272 >>>> >>>> >>>> >>>> >>>> ________________________________________ >>>> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of >>>> Sigbjorn >>>> Lie [sigbjorn at nixtra.com] >>>> Sent: Thursday, 20 October 2011 8:14 a.m. >>>> To: freeipa-users at redhat.com >>>> Subject: [Freeipa-users] The concept of sites... >>>> >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> >>>> Has there been given any thought to the concept of sites within IPA to >>>> improve cross-site implementations? This should be easy to implement as you are already >>>> using DNS >>>> SRV records to locate the ldap/kerberos servers. >>>> >>>> >>>> >>>> >>>> E.g. >>>> Site: Boston >>>> Site: London >>>> >>>> >>>> >>>> >>>> >>>> Create a subdomain of the IPA dns domain named _sites, and a subdomain >>>> of _sites for each site. >>>> >>>> Boston._sites.ipa.domain.com would contain the srv entries for IPA >>>> servers in Boston: _ldap._tcp in srv 0 100 389 boston-ipa-server1 _ldap._tcp in >>>> srv 0 100 389 boston-ipa-server2 ..... >>>> >>>> >>>> >>>> London._sites.ipa.domain.com would contain the srv entries for IPA >>>> serers in London: _ldap._tcp in srv 0 100 389 london-ipa-server1 _ldap._tcp in >>>> srv 0 100 389 london-ipa-server2 .... >>>> >>>> >>>> >>>> Now point the client's DNS "search" entry to point to the local site >>>> first, then search the full name space: Boston client's /etc/resolv.conf: search >>>> Boston._sites.ipa.domain.com ipa.domain.com >>>> >>>> >>>> >>>> London client's /etc/resolv.conf: >>>> search London._sites.ipa.domain.com ipa.domain.com >>>> >>>> >>>> The main ipa.domain.com could still contain srv records for all IPA >>>> servers, or selected IPA servers at the central hub. >>>> >>>> I know I can do this manually within the DNS managment in IPA today, >>>> however it would be a lot easier to maintain "Sites" within the IPA webui/cli. *blink* ;) >>>> >>>> What's your thoughts on this? >>>> >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> Siggi >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > The information contained in this e-mail and in any attachments is confidential and is designated > solely for the attention of the intended recipient(s). If you are not an intended recipient, you > must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have > received this e-mail in error, please notify the sender by return e-mail and delete all copies of > this e-mail from your computer system(s). Please direct any additional queries to: > communications at s3group.com. Thank You. > Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. > Registered Office: South County Business Park, Leopardstown, Dublin > 18_______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From ondrejv at s3group.cz Thu Oct 20 09:57:06 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Thu, 20 Oct 2011 11:57:06 +0200 Subject: [Freeipa-users] The concept of sites... In-Reply-To: <22998.62.148.39.180.1319104529.squirrel@www.nixtra.com> References: <4E9F21AA.6090603@nixtra.com> <833D8E48405E064EBC54C84EC6B36E40456BAAD0@STAWINCOX10MBX1.staff.vuw.ac.nz>, <36360.192.168.211.11.1319055110.squirrel@www.nixtra.com> <833D8E48405E064EBC54C84EC6B36E40456BABC3@STAWINCOX10MBX1.staff.vuw.ac.nz> <34350.192.168.211.11.1319055948.squirrel@www.nixtra.com> <4E9FC783.3060708@s3group.cz> <22998.62.148.39.180.1319104529.squirrel@www.nixtra.com> Message-ID: <4E9FF072.9040206@s3group.cz> Hi Siggi, I see and agree fully - we need something like this... Ondrej On 10/20/2011 11:55 AM, Sigbjorn Lie wrote: > Hi Ondrej, > > Thanks. That RFE is for SSSD client only. I would like to see the management of sites within the > IPA webui/cli. > > > > > Regards, > Siggi > > > On Thu, October 20, 2011 09:02, Ondrej Valousek wrote: >> I have come across this already, BZ already created: >> >> >> https://fedorahosted.org/sssd/ticket/1032 >> >> >> On 10/19/2011 10:25 PM, Sigbjorn Lie wrote: >> >>> The London/newyork dns sub-domains would be used for looking up srv records for the local >>> kerberos/ldap servers only. The actual domain configured on the client and the kerberos and LDAP >>> base would still be the ipa.domain.com. >>> >>> Sync with AD would still be done between ipa.domain.com<-> ad.domain.com. >>> >>> >>> >>> Rgds, >>> Siggi >>> >>> >>> >>> On Wed, October 19, 2011 22:15, Steven Jones wrote: >>> >>>> Ah right, yes, one realm. >>>> >>>> >>>> >>>> However how would you password sync with AD? >>>> >>>> >>>> >>>> So say London.ad.ms.com and Newyork.ad.ms.com >>>> >>>> >>>> >>>> With NY as the "head" >>>> >>>> >>>> >>>> So with london.ipa.unix.com and newyork.ipa.unix.com >>>> >>>> >>>> >>>> Is there still only one winsync agreement? >>>> >>>> >>>> >>>> >>>> >>>> regards >>>> >>>> Steven Jones >>>> >>>> >>>> >>>> Technical Specialist - Linux RHCE >>>> >>>> >>>> >>>> Victoria University, Wellington, NZ >>>> >>>> >>>> >>>> 0064 4 463 6272 >>>> >>>> >>>> >>>> ________________________________________ >>>> From: Sigbjorn Lie [sigbjorn at nixtra.com] >>>> Sent: Thursday, 20 October 2011 9:11 a.m. >>>> To: Steven Jones >>>> Cc: freeipa-users at redhat.com >>>> Subject: RE: [Freeipa-users] The concept of sites... >>>> >>>> >>>> >>>> I see your point with a messy dns infrastructure, however this would happen in the >>>> background. >>>> >>>> >>>> You would still only have one kerberos realm per IPA instance. >>>> >>>> >>>> >>>> >>>> Rgds, >>>> Siggi >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, October 19, 2011 21:30, Steven Jones wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> >>>>> I think AD sort of does this which they have now backed away from? >>>>> >>>>> >>>>> >>>>> >>>>> From my very limited understanding having sub-domains/realms seems to be >>>>> counter-productive....in that trying to do cross-realm trusts/passwords/user info becomes a >>>>> nightmare? >>>>> >>>>> I know somehow I have to get unix.vuw.ac.nz to talk to staff.vuw.ac.nz and >>>>> student.vuw.ac.nz in a winsync (password) agreement, I dont know even if that's possible? >>>>> Yet with a flat domain to >>>>> flat domain its easy? >>>>> >>>>> regards >>>>> >>>>> Steven Jones >>>>> >>>>> >>>>> >>>>> >>>>> Technical Specialist - Linux RHCE >>>>> >>>>> >>>>> >>>>> >>>>> Victoria University, Wellington, NZ >>>>> >>>>> >>>>> >>>>> >>>>> 0064 4 463 6272 >>>>> >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of >>>>> Sigbjorn >>>>> Lie [sigbjorn at nixtra.com] >>>>> Sent: Thursday, 20 October 2011 8:14 a.m. >>>>> To: freeipa-users at redhat.com >>>>> Subject: [Freeipa-users] The concept of sites... >>>>> >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> >>>>> Has there been given any thought to the concept of sites within IPA to >>>>> improve cross-site implementations? This should be easy to implement as you are already >>>>> using DNS >>>>> SRV records to locate the ldap/kerberos servers. >>>>> >>>>> >>>>> >>>>> >>>>> E.g. >>>>> Site: Boston >>>>> Site: London >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Create a subdomain of the IPA dns domain named _sites, and a subdomain >>>>> of _sites for each site. >>>>> >>>>> Boston._sites.ipa.domain.com would contain the srv entries for IPA >>>>> servers in Boston: _ldap._tcp in srv 0 100 389 boston-ipa-server1 _ldap._tcp in >>>>> srv 0 100 389 boston-ipa-server2 ..... >>>>> >>>>> >>>>> >>>>> London._sites.ipa.domain.com would contain the srv entries for IPA >>>>> serers in London: _ldap._tcp in srv 0 100 389 london-ipa-server1 _ldap._tcp in >>>>> srv 0 100 389 london-ipa-server2 .... >>>>> >>>>> >>>>> >>>>> Now point the client's DNS "search" entry to point to the local site >>>>> first, then search the full name space: Boston client's /etc/resolv.conf: search >>>>> Boston._sites.ipa.domain.com ipa.domain.com >>>>> >>>>> >>>>> >>>>> London client's /etc/resolv.conf: >>>>> search London._sites.ipa.domain.com ipa.domain.com >>>>> >>>>> >>>>> The main ipa.domain.com could still contain srv records for all IPA >>>>> servers, or selected IPA servers at the central hub. >>>>> >>>>> I know I can do this manually within the DNS managment in IPA today, >>>>> however it would be a lot easier to maintain "Sites" within the IPA webui/cli. *blink* ;) >>>>> >>>>> What's your thoughts on this? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Siggi >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> >>>>> >>>>> >>>>> >>>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> The information contained in this e-mail and in any attachments is confidential and is designated >> solely for the attention of the intended recipient(s). If you are not an intended recipient, you >> must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have >> received this e-mail in error, please notify the sender by return e-mail and delete all copies of >> this e-mail from your computer system(s). Please direct any additional queries to: >> communications at s3group.com. Thank You. >> Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. >> Registered Office: South County Business Park, Leopardstown, Dublin >> 18_______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelltoesuperstar at gmail.com Thu Oct 20 20:11:25 2011 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Thu, 20 Oct 2011 21:11:25 +0100 Subject: [Freeipa-users] Replicating 2.1.3 from 2.0.0.rc3 Message-ID: Hi Really simple question, is it possible to create a F15 2.1.3 replica from my F14 2.0.0.rc3 IPA Server and then could I rebuild that 2.0.0.rc3 IPA server as a 2.1.3 server based on the new 2.1.3 replica? I would've thought it should be but I seem to remember hearing that something changed in the schema that would prevent this from happening? Thanks Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Thu Oct 20 20:32:13 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 20 Oct 2011 20:32:13 +0000 Subject: [Freeipa-users] GUI backto CLI/LDAP syntax. Message-ID: <833D8E48405E064EBC54C84EC6B36E40456BEE9B@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Just looking at the GUI and then trying to connect a Sun/Oracle Soalr storage array to it Im struggling to match up what the Sun is asking v what I see in the GUI. I know it might clutter up the GUI, possibly too much but I'd like to see the I suppose "raw" info... So If I have a user such as Steven who's in group admin-users and domain unix.vuw.ac.nz I'd like to see the lDAP syntax reflected in the GUI as I set it up......so a single line on the page saying steven ou=admin-users, cn=unix,cn=vuw,cn=ac,cn=nz (or whatever its meant to be) would be hugely useful for me....and I suspect others.....Its like trying to learn another language really, I need a gui to ldap "dictionary".... Hopefully Ive explained what I am trying to get across/ask for. :/ regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From dpal at redhat.com Thu Oct 20 22:20:28 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 20 Oct 2011 18:20:28 -0400 Subject: [Freeipa-users] GUI backto CLI/LDAP syntax. In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40456BEE9B@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40456BEE9B@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4EA09EAC.7090107@redhat.com> On 10/20/2011 04:32 PM, Steven Jones wrote: > Hi, > > Just looking at the GUI and then trying to connect a Sun/Oracle Soalr storage array to it Im struggling to match up what the Sun is asking v what I see in the GUI. > > I know it might clutter up the GUI, possibly too much but I'd like to see the I suppose "raw" info... > > So If I have a user such as Steven who's in group admin-users and domain unix.vuw.ac.nz I'd like to see the lDAP syntax reflected in the GUI as I set it up......so a single line on the page saying steven ou=admin-users, cn=unix,cn=vuw,cn=ac,cn=nz (or whatever its meant to be) would be hugely useful for me....and I suspect others.....Its like trying to learn another language really, I need a gui to ldap "dictionary".... > > Hopefully Ive explained what I am trying to get across/ask for. You can use CLI with the --raw argument. Like: ipa user-show stephen --raw It will give you what you are looking for. Feel free to file an RFE for having a special place in UI to see raw LDAP data. > :/ > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From shelltoesuperstar at gmail.com Fri Oct 21 06:39:51 2011 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Fri, 21 Oct 2011 07:39:51 +0100 Subject: [Freeipa-users] SELinux Denial when installing IPA 2.1.3 on F15 Message-ID: Sounds sort of related to the bug you mentioned in your release notes but this was a clean install not an upgrade. Regards Charlie ------------------------------------------------------------------------------------------------------------------------------------------ FYI SELinux is preventing /usr/sbin/ns-slapd from read access on the lnk_file /var/lock. ***** Plugin restorecon (94.8 confidence) suggests ************************* If you want to fix the label. /var/lock default label should be var_lock_t. Then you can run restorecon. Do # /sbin/restorecon -v /var/lock ***** Plugin catchall_labels (5.21 confidence) suggests ******************** If you want to allow ns-slapd to have read access on the lock lnk_file Then you need to change the label on /var/lock Do # semanage fcontext -a -t FILE_TYPE '/var/lock' where FILE_TYPE is one of the following: abrt_t, lib_t, root_t, device_t, ld_so_t, proc_t, textrel_shlib_t, rpm_script_tmp_t, dirsrv_t, var_lock_t, cert_t, usr_t, device_t, devlog_t, var_run_t, locale_t, etc_t, proc_t, dirsrv_config_t, var_run_t, var_run_t. Then execute: restorecon -v '/var/lock' ***** Plugin catchall (1.44 confidence) suggests *************************** If you believe that ns-slapd should be allowed read access on the lock lnk_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep ns-slapd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:system_r:dirsrv_t:s0 Target Context system_u:object_r:var_t:s0 Target Objects /var/lock [ lnk_file ] Source ns-slapd Source Path /usr/sbin/ns-slapd Port Host f15.test.net Source RPM Packages 389-ds-base-1.2.10-0.4.a4.fc15 Target RPM Packages filesystem-2.4.41-1.fc15 Policy RPM selinux-policy-3.9.16-24.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name f15.test.net Platform Linux f15.test.net 2.6.38.6-27.fc15.x86_64 #1 SMP Sun May 15 17:23:28 UTC 2011 x86_64 x86_64 Alert Count 3 First Seen Fri 21 Oct 2011 01:28:21 AM BST Last Seen Fri 21 Oct 2011 07:29:38 AM BST Local ID Raw Audit Messages type=AVC msg=audit(1319178578.723:176): avc: denied { read } for pid=26931 comm="ns-slapd" name="lock" dev=dm-1 ino=1281 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1319178578.723:176): arch=x86_64 syscall=open success=no exit=EACCES a0=7fff9b184460 a1=c2 a2=1a4 a3=0 items=0 ppid=1 pid=26931 auid=500 uid=492 gid=490 euid=492 suid=492 fsuid=492 egid=490 sgid=490 fsgid=490 tty=(none) ses=4 comm=ns-slapd exe=/usr/sbin/ns-slapd subj=unconfined_u:system_r:dirsrv_t:s0 key=(null) Hash: ns-slapd,dirsrv_t,var_t,lnk_file,read audit2allow #============= dirsrv_t ============== allow dirsrv_t var_t:lnk_file read; audit2allow -R #============= dirsrv_t ============== allow dirsrv_t var_t:lnk_file read; -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Oct 21 13:30:29 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Oct 2011 09:30:29 -0400 Subject: [Freeipa-users] SELinux Denial when installing IPA 2.1.3 on F15 In-Reply-To: References: Message-ID: <4EA173F5.4050003@redhat.com> Charlie Derwent wrote: > Sounds sort of related to the bug you mentioned in your release notes > but this was a clean install not an upgrade. It looks like we need to update the minimum version of selinux-policy required. I believe this was fixed in 3.9.16-29 and it looks like you are running -24. thanks rob > > Regards > Charlie > > ------------------------------------------------------------------------------------------------------------------------------------------ > > FYI > > SELinux is preventing /usr/sbin/ns-slapd from read access on the > lnk_file /var/lock. > > ***** Plugin restorecon (94.8 confidence) suggests > ************************* > > If you want to fix the label. > /var/lock default label should be var_lock_t. > Then you can run restorecon. > Do > # /sbin/restorecon -v /var/lock > > ***** Plugin catchall_labels (5.21 confidence) suggests > ******************** > > If you want to allow ns-slapd to have read access on the lock lnk_file > Then you need to change the label on /var/lock > Do > # semanage fcontext -a -t FILE_TYPE '/var/lock' > where FILE_TYPE is one of the following: abrt_t, lib_t, root_t, > device_t, ld_so_t, proc_t, textrel_shlib_t, rpm_script_tmp_t, dirsrv_t, > var_lock_t, cert_t, usr_t, device_t, devlog_t, var_run_t, locale_t, > etc_t, proc_t, dirsrv_config_t, var_run_t, var_run_t. > Then execute: > restorecon -v '/var/lock' > > > ***** Plugin catchall (1.44 confidence) suggests > *************************** > > If you believe that ns-slapd should be allowed read access on the lock > lnk_file by default. > Then you should report this as a bug. > You can generate a local policy module to allow this access. > Do > allow this access for now by executing: > # grep ns-slapd /var/log/audit/audit.log | audit2allow -M mypol > # semodule -i mypol.pp > > Additional Information: > Source Context unconfined_u:system_r:dirsrv_t:s0 > Target Context system_u:object_r:var_t:s0 > Target Objects /var/lock [ lnk_file ] > Source ns-slapd > Source Path /usr/sbin/ns-slapd > Port > Host f15.test.net > Source RPM Packages 389-ds-base-1.2.10-0.4.a4.fc15 > Target RPM Packages filesystem-2.4.41-1.fc15 > Policy RPM selinux-policy-3.9.16-24.fc15 > Selinux Enabled True > Policy Type targeted > Enforcing Mode Enforcing > Host Name f15.test.net > Platform Linux f15.test.net > 2.6.38.6-27.fc15.x86_64 #1 SMP > Sun May 15 17:23:28 UTC 2011 x86_64 x86_64 > Alert Count 3 > First Seen Fri 21 Oct 2011 01:28:21 AM BST > Last Seen Fri 21 Oct 2011 07:29:38 AM BST > Local ID > > Raw Audit Messages > type=AVC msg=audit(1319178578.723:176): avc: denied { read } for > pid=26931 comm="ns-slapd" name="lock" dev=dm-1 ino=1281 > scontext=unconfined_u:system_r:dirsrv_t:s0 > tcontext=system_u:object_r:var_t:s0 tclass=lnk_file > > > type=SYSCALL msg=audit(1319178578.723:176): arch=x86_64 syscall=open > success=no exit=EACCES a0=7fff9b184460 a1=c2 a2=1a4 a3=0 items=0 ppid=1 > pid=26931 auid=500 uid=492 gid=490 euid=492 suid=492 fsuid=492 egid=490 > sgid=490 fsgid=490 tty=(none) ses=4 comm=ns-slapd exe=/usr/sbin/ns-slapd > subj=unconfined_u:system_r:dirsrv_t:s0 key=(null) > > Hash: ns-slapd,dirsrv_t,var_t,lnk_file,read > > audit2allow > > #============= dirsrv_t ============== > allow dirsrv_t var_t:lnk_file read; > > audit2allow -R > > #============= dirsrv_t ============== > allow dirsrv_t var_t:lnk_file read; > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Fri Oct 21 14:08:37 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Oct 2011 10:08:37 -0400 Subject: [Freeipa-users] GUI backto CLI/LDAP syntax. In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40456BEE9B@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40456BEE9B@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4EA17CE5.1040304@redhat.com> Steven Jones wrote: > Hi, > > Just looking at the GUI and then trying to connect a Sun/Oracle Soalr storage array to it Im struggling to match up what the Sun is asking v what I see in the GUI. > > I know it might clutter up the GUI, possibly too much but I'd like to see the I suppose "raw" info... > > So If I have a user such as Steven who's in group admin-users and domain unix.vuw.ac.nz I'd like to see the lDAP syntax reflected in the GUI as I set it up......so a single line on the page saying steven ou=admin-users, cn=unix,cn=vuw,cn=ac,cn=nz (or whatever its meant to be) would be hugely useful for me....and I suspect others.....Its like trying to learn another language really, I need a gui to ldap "dictionary".... > > Hopefully Ive explained what I am trying to get across/ask for. I'm not sure we'd add this to the UI for clutter reasons, as you suggest. We've talked about per-user config in the past so maybe an 'advanced' option could be added. Feel free to file an RFE if you'd like. The command-line can do this now: ipa user-show --raw --all Steven The --raw option should be available in all commands. rob From sigbjorn at nixtra.com Fri Oct 21 18:04:38 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 21 Oct 2011 20:04:38 +0200 Subject: [Freeipa-users] No hosts showing as enrolled Message-ID: <4EA1B436.70308@nixtra.com> Hi, I've updated to freeipa-server-2.1.3-2.fc15.x86_64. There is no hosts showing as enrolled in the webui. In the CLI hosts are reported to have a keytab. Is this a known issue? Rgds, Siggi PS. KUDOS on the speed of lookups! MASSIVE improvement both in the CLI and in the WEBUI!!! From ayoung at redhat.com Fri Oct 21 18:15:34 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 21 Oct 2011 14:15:34 -0400 Subject: [Freeipa-users] No hosts showing as enrolled In-Reply-To: <4EA1B436.70308@nixtra.com> References: <4EA1B436.70308@nixtra.com> Message-ID: <4EA1B6C6.2010500@redhat.com> On 10/21/2011 02:04 PM, Sigbjorn Lie wrote: > Hi, > > I've updated to freeipa-server-2.1.3-2.fc15.x86_64. > > There is no hosts showing as enrolled in the webui. In the CLI hosts > are reported to have a keytab. Is this a known issue? > > > Rgds, > Siggi > > > PS. KUDOS on the speed of lookups! MASSIVE improvement both in the CLI > and in the WEBUI!!! > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users They use exactly the same API. The only difference between the webUI and the CLI is that the WebUI is marshalled via JSON, and the CLI uses XML RPC. So you should see exactly the same results in both. Have you typed something into your filter field that is hiding the hosts? From sigbjorn at nixtra.com Fri Oct 21 18:29:23 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 21 Oct 2011 20:29:23 +0200 Subject: [Freeipa-users] No hosts showing as enrolled In-Reply-To: <4EA1B6C6.2010500@redhat.com> References: <4EA1B436.70308@nixtra.com> <4EA1B6C6.2010500@redhat.com> Message-ID: <4EA1BA03.6030507@nixtra.com> On 10/21/2011 08:15 PM, Adam Young wrote: > On 10/21/2011 02:04 PM, Sigbjorn Lie wrote: >> Hi, >> >> I've updated to freeipa-server-2.1.3-2.fc15.x86_64. >> >> There is no hosts showing as enrolled in the webui. In the CLI hosts >> are reported to have a keytab. Is this a known issue? >> >> >> Rgds, >> Siggi >> >> >> PS. KUDOS on the speed of lookups! MASSIVE improvement both in the >> CLI and in the WEBUI!!! >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > They use exactly the same API. The only difference between the webUI > and the CLI is that the WebUI is marshalled via JSON, and the CLI uses > XML RPC. So you should see exactly the same results in both. Have > you typed something into your filter field that is hiding the hosts? > No search filter, that I know of. I assume you're referring to the top right hand corner field? That field is empty, I'm displaying all hosts. Still noting in the "Enrolled?" field. Rgds, Siggi From ayoung at redhat.com Fri Oct 21 20:02:20 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 21 Oct 2011 16:02:20 -0400 Subject: [Freeipa-users] No hosts showing as enrolled In-Reply-To: <4EA1BA03.6030507@nixtra.com> References: <4EA1B436.70308@nixtra.com> <4EA1B6C6.2010500@redhat.com> <4EA1BA03.6030507@nixtra.com> Message-ID: <4EA1CFCC.7080006@redhat.com> On 10/21/2011 02:29 PM, Sigbjorn Lie wrote: > On 10/21/2011 08:15 PM, Adam Young wrote: >> On 10/21/2011 02:04 PM, Sigbjorn Lie wrote: >>> Hi, >>> >>> I've updated to freeipa-server-2.1.3-2.fc15.x86_64. >>> >>> There is no hosts showing as enrolled in the webui. In the CLI hosts >>> are reported to have a keytab. Is this a known issue? >>> >>> >>> Rgds, >>> Siggi >>> >>> >>> PS. KUDOS on the speed of lookups! MASSIVE improvement both in the >>> CLI and in the WEBUI!!! >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> They use exactly the same API. The only difference between the webUI >> and the CLI is that the WebUI is marshalled via JSON, and the CLI >> uses XML RPC. So you should see exactly the same results in both. >> Have you typed something into your filter field that is hiding the >> hosts? >> > No search filter, that I know of. I assume you're referring to the top > right hand corner field? > > That field is empty, I'm displaying all hosts. Still noting in the > "Enrolled?" field. Just realized that you are referring to the "enrolle?" column. I think that is a bug. I just opened this ticket: https://fedorahosted.org/freeipa/ticket/2020 The field that populates that column is actually krblastpwdchange, which should show when the password for the host principal was last changed. The intention is that this column should show when the host was enrolled, But is defaulting to blank. > > > Rgds, > Siggi > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sigbjorn at nixtra.com Fri Oct 21 23:05:34 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Sat, 22 Oct 2011 01:05:34 +0200 Subject: [Freeipa-users] No hosts showing as enrolled In-Reply-To: <4EA1CFCC.7080006@redhat.com> References: <4EA1B436.70308@nixtra.com> <4EA1B6C6.2010500@redhat.com> <4EA1BA03.6030507@nixtra.com> <4EA1CFCC.7080006@redhat.com> Message-ID: <4EA1FABE.60805@nixtra.com> On 10/21/2011 10:02 PM, Adam Young wrote: > On 10/21/2011 02:29 PM, Sigbjorn Lie wrote: >> On 10/21/2011 08:15 PM, Adam Young wrote: >>> On 10/21/2011 02:04 PM, Sigbjorn Lie wrote: >>>> Hi, >>>> >>>> I've updated to freeipa-server-2.1.3-2.fc15.x86_64. >>>> >>>> There is no hosts showing as enrolled in the webui. In the CLI >>>> hosts are reported to have a keytab. Is this a known issue? >>>> >>>> >>>> Rgds, >>>> Siggi >>>> >>>> >>>> PS. KUDOS on the speed of lookups! MASSIVE improvement both in the >>>> CLI and in the WEBUI!!! >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> They use exactly the same API. The only difference between the >>> webUI and the CLI is that the WebUI is marshalled via JSON, and the >>> CLI uses XML RPC. So you should see exactly the same results in >>> both. Have you typed something into your filter field that is >>> hiding the hosts? >>> >> No search filter, that I know of. I assume you're referring to the >> top right hand corner field? >> >> That field is empty, I'm displaying all hosts. Still noting in the >> "Enrolled?" field. > Just realized that you are referring to the "enrolle?" column. I > think that is a bug. I just opened this ticket: > https://fedorahosted.org/freeipa/ticket/2020 > > The field that populates that column is actually krblastpwdchange, > which should show when the password for the host principal was last > changed. The intention is that this column should show when the host > was enrolled, But is defaulting to blank. Thanks. I got several hosts joined to IPA, and they have a krbLastPwdChange value if I look for them using ldapsarch and "ipa host-show --all". Please let me know if I can assist in further troubleshooting of the issue. Rgds, Siggi From ayoung at redhat.com Mon Oct 24 13:32:44 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 24 Oct 2011 09:32:44 -0400 Subject: [Freeipa-users] No hosts showing as enrolled In-Reply-To: <4EA1FABE.60805@nixtra.com> References: <4EA1B436.70308@nixtra.com> <4EA1B6C6.2010500@redhat.com> <4EA1BA03.6030507@nixtra.com> <4EA1CFCC.7080006@redhat.com> <4EA1FABE.60805@nixtra.com> Message-ID: <4EA568FC.1000309@redhat.com> On 10/21/2011 07:05 PM, Sigbjorn Lie wrote: > On 10/21/2011 10:02 PM, Adam Young wrote: >> On 10/21/2011 02:29 PM, Sigbjorn Lie wrote: >>> On 10/21/2011 08:15 PM, Adam Young wrote: >>>> On 10/21/2011 02:04 PM, Sigbjorn Lie wrote: >>>>> Hi, >>>>> >>>>> I've updated to freeipa-server-2.1.3-2.fc15.x86_64. >>>>> >>>>> There is no hosts showing as enrolled in the webui. In the CLI >>>>> hosts are reported to have a keytab. Is this a known issue? >>>>> >>>>> >>>>> Rgds, >>>>> Siggi >>>>> >>>>> >>>>> PS. KUDOS on the speed of lookups! MASSIVE improvement both in the >>>>> CLI and in the WEBUI!!! >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> They use exactly the same API. The only difference between the >>>> webUI and the CLI is that the WebUI is marshalled via JSON, and the >>>> CLI uses XML RPC. So you should see exactly the same results in >>>> both. Have you typed something into your filter field that is >>>> hiding the hosts? >>>> >>> No search filter, that I know of. I assume you're referring to the >>> top right hand corner field? >>> >>> That field is empty, I'm displaying all hosts. Still noting in the >>> "Enrolled?" field. >> Just realized that you are referring to the "enrolle?" column. I >> think that is a bug. I just opened this ticket: >> https://fedorahosted.org/freeipa/ticket/2020 >> >> The field that populates that column is actually krblastpwdchange, >> which should show when the password for the host principal was last >> changed. The intention is that this column should show when the host >> was enrolled, But is defaulting to blank. > > Thanks. > > I got several hosts joined to IPA, and they have a krbLastPwdChange > value if I look for them using ldapsarch and "ipa host-show > --all". > > Please let me know if I can assist in further troubleshooting of the > issue. There is not problem with your hosts, just a UI disconnect. The column is bogus and we are going to remove it. Please ignore it for now. > > > Rgds, > Siggi > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Mon Oct 24 14:01:56 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 24 Oct 2011 10:01:56 -0400 Subject: [Freeipa-users] No hosts showing as enrolled In-Reply-To: <4EA568FC.1000309@redhat.com> References: <4EA1B436.70308@nixtra.com> <4EA1B6C6.2010500@redhat.com> <4EA1BA03.6030507@nixtra.com> <4EA1CFCC.7080006@redhat.com> <4EA1FABE.60805@nixtra.com> <4EA568FC.1000309@redhat.com> Message-ID: <4EA56FD4.2020003@redhat.com> On 10/24/2011 09:32 AM, Adam Young wrote: > On 10/21/2011 07:05 PM, Sigbjorn Lie wrote: >> On 10/21/2011 10:02 PM, Adam Young wrote: >>> On 10/21/2011 02:29 PM, Sigbjorn Lie wrote: >>>> On 10/21/2011 08:15 PM, Adam Young wrote: >>>>> On 10/21/2011 02:04 PM, Sigbjorn Lie wrote: >>>>>> Hi, >>>>>> >>>>>> I've updated to freeipa-server-2.1.3-2.fc15.x86_64. >>>>>> >>>>>> There is no hosts showing as enrolled in the webui. In the CLI >>>>>> hosts are reported to have a keytab. Is this a known issue? >>>>>> >>>>>> >>>>>> Rgds, >>>>>> Siggi >>>>>> >>>>>> >>>>>> PS. KUDOS on the speed of lookups! MASSIVE improvement both in >>>>>> the CLI and in the WEBUI!!! >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-users mailing list >>>>>> Freeipa-users at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> They use exactly the same API. The only difference between the >>>>> webUI and the CLI is that the WebUI is marshalled via JSON, and >>>>> the CLI uses XML RPC. So you should see exactly the same results >>>>> in both. Have you typed something into your filter field that is >>>>> hiding the hosts? >>>>> >>>> No search filter, that I know of. I assume you're referring to the >>>> top right hand corner field? >>>> >>>> That field is empty, I'm displaying all hosts. Still noting in the >>>> "Enrolled?" field. >>> Just realized that you are referring to the "enrolle?" column. I >>> think that is a bug. I just opened this ticket: >>> https://fedorahosted.org/freeipa/ticket/2020 >>> >>> The field that populates that column is actually krblastpwdchange, >>> which should show when the password for the host principal was last >>> changed. The intention is that this column should show when the host >>> was enrolled, But is defaulting to blank. >> >> Thanks. >> >> I got several hosts joined to IPA, and they have a krbLastPwdChange >> value if I look for them using ldapsarch and "ipa host-show >> --all". >> >> Please let me know if I can assist in further troubleshooting of the >> issue. > There is not problem with your hosts, just a UI disconnect. > The column is bogus and we are going to remove it. Please ignore it > for now. I would not say it is bogus. It is supposed to show which hosts have been enrolled and which are not. IMO it is a valuable piece of data so rather than removing it please fix it to display the correct status. > >> >> >> Rgds, >> Siggi >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sigbjorn at nixtra.com Tue Oct 25 14:33:54 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 25 Oct 2011 16:33:54 +0200 (CEST) Subject: [Freeipa-users] Minimum required access for winsync Message-ID: <32883.213.225.75.97.1319553234.squirrel@www.nixtra.com> Hi, What is the minimum required access for the account specified when creating a winsync agreement with a Windows 2008 Active Directory? Regards, Siggi From rmeggins at redhat.com Tue Oct 25 14:47:22 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 25 Oct 2011 08:47:22 -0600 Subject: [Freeipa-users] Minimum required access for winsync In-Reply-To: <32883.213.225.75.97.1319553234.squirrel@www.nixtra.com> References: <32883.213.225.75.97.1319553234.squirrel@www.nixtra.com> Message-ID: <4EA6CBFA.5040700@redhat.com> On 10/25/2011 08:33 AM, Sigbjorn Lie wrote: > Hi, > > What is the minimum required access for the account specified when creating a winsync agreement > with a Windows 2008 Active Directory? Read, write, and replicator rights. > > > > Regards, > Siggi > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sigbjorn at nixtra.com Tue Oct 25 14:52:17 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 25 Oct 2011 16:52:17 +0200 (CEST) Subject: [Freeipa-users] Minimum required access for winsync In-Reply-To: <4EA6CBFA.5040700@redhat.com> References: <32883.213.225.75.97.1319553234.squirrel@www.nixtra.com> <4EA6CBFA.5040700@redhat.com> Message-ID: <34566.213.225.75.97.1319554337.squirrel@www.nixtra.com> Read and write to the subtree I'm attempting to sync, or the whole AD? Could you elaborate on the replicator rights topic please? I cannot remember having seen this in Active Directory? Rgds, Siggi On Tue, October 25, 2011 16:47, Rich Megginson wrote: > On 10/25/2011 08:33 AM, Sigbjorn Lie wrote: > >> Hi, >> >> >> What is the minimum required access for the account specified when creating a winsync agreement >> with a Windows 2008 Active Directory? > Read, write, and replicator rights. > >> >> >> >> Regards, >> Siggi >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > From rmeggins at redhat.com Tue Oct 25 15:18:41 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 25 Oct 2011 09:18:41 -0600 Subject: [Freeipa-users] Minimum required access for winsync In-Reply-To: <34566.213.225.75.97.1319554337.squirrel@www.nixtra.com> References: <32883.213.225.75.97.1319553234.squirrel@www.nixtra.com> <4EA6CBFA.5040700@redhat.com> <34566.213.225.75.97.1319554337.squirrel@www.nixtra.com> Message-ID: <4EA6D351.8010005@redhat.com> On 10/25/2011 08:52 AM, Sigbjorn Lie wrote: > Read and write to the subtree I'm attempting to sync, or the whole AD? > > Could you elaborate on the replicator rights topic please? I cannot remember having seen this in > Active Directory? See http://support.microsoft.com/kb/891995 and http://support.microsoft.com/kb/303972 > > > Rgds, > Siggi > > > > > On Tue, October 25, 2011 16:47, Rich Megginson wrote: >> On 10/25/2011 08:33 AM, Sigbjorn Lie wrote: >> >>> Hi, >>> >>> >>> What is the minimum required access for the account specified when creating a winsync agreement >>> with a Windows 2008 Active Directory? >> Read, write, and replicator rights. >> >>> >>> >>> Regards, >>> Siggi >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> > From sigbjorn at nixtra.com Tue Oct 25 19:23:29 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 25 Oct 2011 21:23:29 +0200 Subject: [Freeipa-users] Minimum required access for winsync In-Reply-To: <4EA6D351.8010005@redhat.com> References: <32883.213.225.75.97.1319553234.squirrel@www.nixtra.com> <4EA6CBFA.5040700@redhat.com> <34566.213.225.75.97.1319554337.squirrel@www.nixtra.com> <4EA6D351.8010005@redhat.com> Message-ID: <4EA70CB1.5040705@nixtra.com> On 10/25/2011 05:18 PM, Rich Megginson wrote: > On 10/25/2011 08:52 AM, Sigbjorn Lie wrote: >> Read and write to the subtree I'm attempting to sync, or the whole AD? >> >> Could you elaborate on the replicator rights topic please? I cannot >> remember having seen this in >> Active Directory? > See > http://support.microsoft.com/kb/891995 > and > http://support.microsoft.com/kb/303972 Thank you. From Steven.Jones at vuw.ac.nz Thu Oct 27 00:49:01 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 27 Oct 2011 00:49:01 +0000 Subject: [Freeipa-users] Unique world wide UIDS Message-ID: <833D8E48405E064EBC54C84EC6B36E4045793DCD@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Readng the docs on the 32bit UIDs it says it makes an attempt to give out a unique range....would it be possible / practical if RH (would want to) ran some sort of database or registration function to try and insure that? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From ayoung at redhat.com Thu Oct 27 01:35:29 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 26 Oct 2011 21:35:29 -0400 Subject: [Freeipa-users] Unique world wide UIDS In-Reply-To: <833D8E48405E064EBC54C84EC6B36E4045793DCD@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E4045793DCD@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4EA8B561.5040105@redhat.com> On 10/26/2011 08:49 PM, Steven Jones wrote: > Hi, > > Readng the docs on the 32bit UIDs it says it makes an attempt to give out a unique range....would it be possible / practical if RH (would want to) ran some sort of database or registration function to try and insure that? > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users No. It would not be. Fragmentation of the 32 Bit space means that you are going to have clashes. Just look at IPv4 addresses and you can see an analogue. 32bits really means 32 bits, as you have to deal with sometimes things being stored in signed values (Java for instance) so you have 2^31 or 2,147,483,648. Which is not quite a quarter of the worlds population. Now, assuming that any organization is going to be smaller than that, you have to figure out how much to give them...they are going to make it a financial decision, so the US governement buys up enough to be future proof, lets say 1 Billion, leaveing a little over 1 Billion for the Rest of the world...then China comes in. Then India. You get the idea. From ayoung at redhat.com Thu Oct 27 12:52:03 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 27 Oct 2011 08:52:03 -0400 Subject: [Freeipa-users] Unique world wide UIDS In-Reply-To: <4EA8B561.5040105@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E4045793DCD@STAWINCOX10MBX1.staff.vuw.ac.nz> <4EA8B561.5040105@redhat.com> Message-ID: <4EA953F3.8040101@redhat.com> On 10/26/2011 09:35 PM, Adam Young wrote: > On 10/26/2011 08:49 PM, Steven Jones wrote: >> Hi, >> >> Readng the docs on the 32bit UIDs it says it makes an attempt to give >> out a unique range....would it be possible / practical if RH (would >> want to) ran some sort of database or registration function to try >> and insure that? >> >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > No. It would not be. Fragmentation of the 32 Bit space means that > you are going to have clashes. Just look at IPv4 addresses and you > can see an analogue. 32bits really means 32 bits, as you have to > deal with sometimes things being stored in signed values (Java for > instance) so you have 2^31 or 2,147,483,648. Which is not quite a > quarter of the worlds population. Wrote this too late at night. Should read "less than half of the world's population" but the argument stays the same. > Now, assuming that any organization is going to be smaller than that, > you have to figure out how much to give them...they are going to make > it a financial decision, so the US governement buys up enough to be > future proof, lets say 1 Billion, leaveing a little over 1 Billion > for the Rest of the world...then China comes in. Then India. You get > the idea. > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From i.am.stack at gmail.com Thu Oct 27 18:27:50 2011 From: i.am.stack at gmail.com (=?UTF-8?Q?Stack_Koror=C4=81?=) Date: Thu, 27 Oct 2011 13:27:50 -0500 Subject: [Freeipa-users] Scientific Linux 6.1 client issues Message-ID: Hello everyone. I like the potential possibilities that IPA provides so I have been playing with it trying to figure it out. I am using Scientific Linux 6.1 as my OS and I have been using the Red Hat documentation [1] as the majority source of my learning thus far. I have been recently reading through the documentation on freeipa.org since it seems to be flushed out a little more[2]. [1] http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Enterprise_Identity_Management_Guide/index.html [2] https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/index.html I have run into an issue and I am having difficultly solving it. The client will not see the server. I have posted to the SL forums but I have not heard anything back. I am hoping it is more of an IPA issue instead of a SL6.1 and as such someone here might be able to help. For testing purposes I have two hosts. Both hosts are a fresh install of SL6.1 Minimal Desktop fully updated on a VM connected by a virtual network. There is nothing else on this network at all and no connection to the outside world. My yum updates off of a external USB drive that contains a up-to-date yum mirror of 6.1, Security, and Fastbugs (I do a lot of testing and this helps alleviate me beating up someone elses mirror). Host ipa.blarg.local is my ipa server. Host dev.blarg.local is my "desktop developer" system. The minimal desktop install included dnsmasq. So I configured it for use as my DHCP/DNS server on ipa.blarg.local. /etc/dnsmasq.conf is as follows: domain=needed domain=blarg.local dhcp-range=10.1.1.50,10.1.1.55,255.255.0.0,12h dhcp-host=08:00:27:e1:7c:15,dev log-dhcp I added the dhcp-host just to ensure that the dev box gets a proper hostname entry in the DNS. I opened up ports 53 TCP and 53,67-69 UDP in the firewall of ipa.blarg.local. Then I installed the IPA server with `yum install ipa-server`. 115 packages are installed. Then I ran the install script `ipa-server-install` It correctly identifies the Server Host Name as ipa.blarg.local. It correctly identifies the domain name as blarg.local. It correctly identifies the realm name as BLARG.LOCAL. I set the Directory Manager password I set the IPA Admin password. The script runs till completion. I opened up ports 80,88,389,443,464,636 TCP and 88,464,123 UDP as suggested by the Red Hat documentation. Table 2.2 of the FreeIPA documentation has a few other ports listed as well, so I opened them too. These are 9180,9443-9446,9701,7389 TCP. Next I run `kinit admin` on the command prompt. Then I opened up firefox to http://ipa.blarg.local and "I understand the risks" to "add exception" that I permanently stored. An error pops up saying that "Kerberos ticket no longer valid" and I click the "follow these directions" link. This takes me to a page to import the CA certificate and I agree to trust the site. Next is the link to configure Firefox for Single Sign On. Everything is pretty much exactly as the documentation says it should be. Now going to ipa.blarg.local logs me in. Great! I tested it out by adding a new user via command line: `echo "password" | ipa user-add user1 --first=Some --last=User --password`. This completes successfully. Now I tried to add the dev box as a client. On dev.blarg.local, it has an IP from the DNS server and I can ping both 'ipa' and 'ipa.blarg.local'. Both hosts can ping 'dev.blarg.local' and 'dev'. I can do a `dig -x 10.1.1.12` and get a successful result for the host ipa.blarg.local. I get a successful lookup for the host dev as well. The DNS forward and reverse look-ups appear to be working correctly, as far as I can tell. `yum install ipa-client` showed it was already installed. Therefore I ran `ipa-client-install` as root. "DNS discovery failed to determine your DNS domain." "Please provide the domain name of your IPA server:" Hrm. Why didn't it pick it up? The host sees it and so does the DNS. I entered blarg.local "DNS discovery failed to determine your DNS domain." "Please provide your IPA server name:" Hrm. Very odd. I enter in ipa.blarg.local I get a big error message saying it failed. It says my resolve.conf file is not properly configured. It asks if I want to proceed without DNS and I say no. I get back a bash command prompt. `cat /etc/resolv.conf` domain blarg.local search blarg.local nameserver 10.1.1.12 #This is the IP of ipa.blarg.local aka the DNS/DHCP server Everything looks right. DNS acts properly as far as I can tell. Don't know why it didn't work. I have done a bunch of reading and verified things like my time being correct (It is. Both hosts are less then a second of each other). I thought maybe a port is missing on the firewall since the FreeIPA documentation has more ports then the Red Hat documentation. I double checked the firewall ports with nmap and they appear open. So I turned off the firewall (not great IRL but OK for testing in a isolated virtual machine). I thought it was a problem with a service not running, but everything looks like it is running properly. The latest attempt I failed out early on. The Fedora RPMS for FreeIPA 2.1.3 complained about too many packages being different from the SL base (and I would rather not have that many packages different) so I tried to pull the source to compile 2.1.3 but I was having issues pulling in all the devel packages. If I just need to suck it up and compile from source, I will. If I were to move this into my work environment I would just rather stick with the official RPMS then build my own repo, but I can do it if that is what is needed. Not sure what the problem is with the client though. Any ideas? Thanks! ~Stack~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From i.am.stack at gmail.com Thu Oct 27 19:07:27 2011 From: i.am.stack at gmail.com (=?UTF-8?Q?Stack_Koror=C4=81?=) Date: Thu, 27 Oct 2011 14:07:27 -0500 Subject: [Freeipa-users] Scientific Linux 6.1 client issues In-Reply-To: References: Message-ID: Quick update. Just to be thorough and complete as possible, I just tried to pass a ton of information into ipa-client-install as I could. I also verified that I could access the webserver and ntp server from the dev client box. # ipa-client-install --realm=BLARG.LOCAL --server=ipa.blarg.local --domain=blarg.local --mkhomedir --hostname=dev.blarg.local --enable-dns-updates --ntp-server=ipa.blarg.local --principal=admin Discovery was successful! Hostname: dev.blarg.local Realm: BLARG.LOCAL DNS Domain: blarg.local IPA Server: ipa.blarg.local BaseDN: dc=blarg,dc=local Continue to configure the system with these values? [no]: yes Password for admin at BLARG.LOCAL: kinit: Cannot resolve network address for KDC in realm "BLARG.LOCAL" while getting initial credentials. Hrmm.....Stuck again. Any ideas? Thanks! ~Stack~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Oct 27 19:50:13 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Oct 2011 15:50:13 -0400 Subject: [Freeipa-users] Scientific Linux 6.1 client issues In-Reply-To: References: Message-ID: <4EA9B5F5.8050109@redhat.com> Stack Koror? wrote: > Quick update. > > Just to be thorough and complete as possible, I just tried to pass a ton > of information into ipa-client-install as I could. I also verified that > I could access the webserver and ntp server from the dev client box. > > # ipa-client-install --realm=BLARG.LOCAL --server=ipa.blarg.local > --domain=blarg.local --mkhomedir --hostname=dev.blarg.local > --enable-dns-updates --ntp-server=ipa.blarg.local --principal=admin > > Discovery was successful! > Hostname: dev.blarg.local > Realm: BLARG.LOCAL > DNS Domain: blarg.local > IPA Server: ipa.blarg.local > BaseDN: dc=blarg,dc=local > > Continue to configure the system with these values? [no]: yes > Password for admin at BLARG.LOCAL: > > kinit: Cannot resolve network address for KDC in realm "BLARG.LOCAL" > while getting initial credentials. > > > Hrmm.....Stuck again. Any ideas? > > Thanks! > > ~Stack~ You don't say what version of freeipa you are using but we fixed a similar sounding problem earlier this spring. Try adding --force to the command-line as an outside chance of working. Building 2.1.3 from source is going to require the same set of dependencies as building from the src.rpm. Note though that upstream development of freeipa is done in Fedora, not RHEL. regards rob From Steven.Jones at vuw.ac.nz Thu Oct 27 20:29:52 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 27 Oct 2011 20:29:52 +0000 Subject: [Freeipa-users] Unique world wide UIDS In-Reply-To: <4EA953F3.8040101@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E4045793DCD@STAWINCOX10MBX1.staff.vuw.ac.nz> <4EA8B561.5040105@redhat.com>,<4EA953F3.8040101@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40457B3672@STAWINCOX10MBX4.staff.vuw.ac.nz> Hi, Well if you understand Peak Oil and that the "green revolution" was actually truning fossil fuel into food ie we eat oil....only having 2billion UIDs wont be a problem. :/ regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Adam Young [ayoung at redhat.com] Sent: Friday, 28 October 2011 1:52 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unique world wide UIDS On 10/26/2011 09:35 PM, Adam Young wrote: > On 10/26/2011 08:49 PM, Steven Jones wrote: >> Hi, >> >> Readng the docs on the 32bit UIDs it says it makes an attempt to give >> out a unique range....would it be possible / practical if RH (would >> want to) ran some sort of database or registration function to try >> and insure that? >> >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > No. It would not be. Fragmentation of the 32 Bit space means that > you are going to have clashes. Just look at IPv4 addresses and you > can see an analogue. 32bits really means 32 bits, as you have to > deal with sometimes things being stored in signed values (Java for > instance) so you have 2^31 or 2,147,483,648. Which is not quite a > quarter of the worlds population. Wrote this too late at night. Should read "less than half of the world's population" but the argument stays the same. > Now, assuming that any organization is going to be smaller than that, > you have to figure out how much to give them...they are going to make > it a financial decision, so the US governement buys up enough to be > future proof, lets say 1 Billion, leaveing a little over 1 Billion > for the Rest of the world...then China comes in. Then India. You get > the idea. > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Thu Oct 27 20:34:23 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Oct 2011 16:34:23 -0400 Subject: [Freeipa-users] Unique world wide UIDS In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40457B3672@STAWINCOX10MBX4.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E4045793DCD@STAWINCOX10MBX1.staff.vuw.ac.nz> <4EA8B561.5040105@redhat.com>, <4EA953F3.8040101@redhat.com> <833D8E48405E064EBC54C84EC6B36E40457B3672@STAWINCOX10MBX4.staff.vuw.ac.nz> Message-ID: <4EA9C04F.9050405@redhat.com> Steven Jones wrote: > Hi, > > Well if you understand Peak Oil and that the "green revolution" was actually truning fossil fuel into food ie we eat oil....only having 2billion UIDs wont be a problem. > > :/ Many, many organizations start with the same uid base, 500 or 1000. When company A buys company B there are tons and tons of uid collisions. If each started at a random start point then the chances of collision, while not zero, are much lower. Our goal wasn't to guarantee uniqueness in the universe, just to make integration hopefully easier in the future when namespaces are merged. rob From Steven.Jones at vuw.ac.nz Thu Oct 27 20:40:14 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 27 Oct 2011 20:40:14 +0000 Subject: [Freeipa-users] Unique world wide UIDS In-Reply-To: <4EA9C04F.9050405@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E4045793DCD@STAWINCOX10MBX1.staff.vuw.ac.nz> <4EA8B561.5040105@redhat.com>,<4EA953F3.8040101@redhat.com> <833D8E48405E064EBC54C84EC6B36E40457B3672@STAWINCOX10MBX4.staff.vuw.ac.nz>, <4EA9C04F.9050405@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40457B36A1@STAWINCOX10MBX4.staff.vuw.ac.nz> Yes I can appreciate that, we have done the same thing im '500'... oops.... As an educational setup we are looking to federate worldwide, that means Shibboleth or similar....a unique UID per academic world wide might be worthwhile....there wont be 2billion academics...students...well i guess that would one day be a "ipv4" problem. Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Friday, 28 October 2011 9:34 a.m. To: Steven Jones Cc: Adam Young; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unique world wide UIDS Steven Jones wrote: > Hi, > > Well if you understand Peak Oil and that the "green revolution" was actually truning fossil fuel into food ie we eat oil....only having 2billion UIDs wont be a problem. > > :/ Many, many organizations start with the same uid base, 500 or 1000. When company A buys company B there are tons and tons of uid collisions. If each started at a random start point then the chances of collision, while not zero, are much lower. Our goal wasn't to guarantee uniqueness in the universe, just to make integration hopefully easier in the future when namespaces are merged. rob From sigbjorn at nixtra.com Sat Oct 29 08:55:26 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Sat, 29 Oct 2011 10:55:26 +0200 Subject: [Freeipa-users] No hosts showing as enrolled In-Reply-To: <4EA56FD4.2020003@redhat.com> References: <4EA1B436.70308@nixtra.com> <4EA1B6C6.2010500@redhat.com> <4EA1BA03.6030507@nixtra.com> <4EA1CFCC.7080006@redhat.com> <4EA1FABE.60805@nixtra.com> <4EA568FC.1000309@redhat.com> <4EA56FD4.2020003@redhat.com> Message-ID: <4EABBF7E.5040304@nixtra.com> On 10/24/2011 04:01 PM, Dmitri Pal wrote: > On 10/24/2011 09:32 AM, Adam Young wrote: >> On 10/21/2011 07:05 PM, Sigbjorn Lie wrote: >>> On 10/21/2011 10:02 PM, Adam Young wrote: >>>> On 10/21/2011 02:29 PM, Sigbjorn Lie wrote: >>>>> On 10/21/2011 08:15 PM, Adam Young wrote: >>>>>> On 10/21/2011 02:04 PM, Sigbjorn Lie wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've updated to freeipa-server-2.1.3-2.fc15.x86_64. >>>>>>> >>>>>>> There is no hosts showing as enrolled in the webui. In the CLI >>>>>>> hosts are reported to have a keytab. Is this a known issue? >>>>>>> >>>>>>> >>>>>>> Rgds, >>>>>>> Siggi >>>>>>> >>>>>>> >>>>>>> PS. KUDOS on the speed of lookups! MASSIVE improvement both in >>>>>>> the CLI and in the WEBUI!!! >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-users mailing list >>>>>>> Freeipa-users at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> They use exactly the same API. The only difference between the >>>>>> webUI and the CLI is that the WebUI is marshalled via JSON, and >>>>>> the CLI uses XML RPC. So you should see exactly the same results >>>>>> in both. Have you typed something into your filter field that is >>>>>> hiding the hosts? >>>>>> >>>>> No search filter, that I know of. I assume you're referring to the >>>>> top right hand corner field? >>>>> >>>>> That field is empty, I'm displaying all hosts. Still noting in the >>>>> "Enrolled?" field. >>>> Just realized that you are referring to the "enrolle?" column. I >>>> think that is a bug. I just opened this ticket: >>>> https://fedorahosted.org/freeipa/ticket/2020 >>>> >>>> The field that populates that column is actually krblastpwdchange, >>>> which should show when the password for the host principal was last >>>> changed. The intention is that this column should show when the host >>>> was enrolled, But is defaulting to blank. >>> Thanks. >>> >>> I got several hosts joined to IPA, and they have a krbLastPwdChange >>> value if I look for them using ldapsarch and "ipa host-show >>> --all". >>> >>> Please let me know if I can assist in further troubleshooting of the >>> issue. >> There is not problem with your hosts, just a UI disconnect. >> The column is bogus and we are going to remove it. Please ignore it >> for now. > I would not say it is bogus. It is supposed to show which hosts have > been enrolled and which are not. IMO it is a valuable piece of data so > rather than removing it please fix it to display the correct status. > I agree. From i.am.stack at gmail.com Sat Oct 29 13:50:53 2011 From: i.am.stack at gmail.com (~Stack~) Date: Sat, 29 Oct 2011 08:50:53 -0500 Subject: [Freeipa-users] Scientific Linux 6.1 client issues In-Reply-To: <4EA9B5F5.8050109@redhat.com> References: <4EA9B5F5.8050109@redhat.com> Message-ID: <4EAC04BD.5080701@gmail.com> I apologize for the delay. I got crazy busy. On 10/27/2011 02:50 PM, Rob Crittenden wrote: > You don't say what version of freeipa you are using but we fixed a > similar sounding problem earlier this spring. Try adding --force to the > command-line as an outside chance of working. The RPM's show a version of 2.0.0-23.el6_1.2. I knew they were a bit old, but I didn't realize they were that far back. I did try adding the --force option and I got the results below. Joining realm failed: Host is already joined. Use ipa-getkeytab to obtain a host principal for this server. Created /etc/ipa/default.con Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm BLARG.LOCAL Failed to obtain host TGT. Failed to update DNS A record. (Command ?/usr/bin/nsupdate ?g /etc/ipa/.dns_update.txt? return non-zero exit status 1) SSSD enabled nss_ldap is not able to use DNS discovery! Changing configuration to use hardcoded server name: ipa.blarg.local Kerberos 5 enabled NTP enabled Client configuration complete. Since my first email, I had attempted to add the host via the web browser. I was hoping if I set the OTP that I could get it to work. It didn?t. Don?t know if that caused a problem here. When I try to look at /etc/ipa/.dns_update.txt the file doesn?t exist so I assume it was deleted by the ipa-client-install script. I am unable to login with the user I created. > Building 2.1.3 from source is going to require the same set of > dependencies as building from the src.rpm. Note though that upstream > development of freeipa is done in Fedora, not RHEL. I will keep that in mind and I will try to build from the source RPM. If I have an issue I will post back here. Thank you very much for your help! ~Stack~ From simo at redhat.com Sun Oct 30 14:41:33 2011 From: simo at redhat.com (Simo Sorce) Date: Sun, 30 Oct 2011 10:41:33 -0400 Subject: [Freeipa-users] Unique world wide UIDS In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40457B36A1@STAWINCOX10MBX4.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E4045793DCD@STAWINCOX10MBX1.staff.vuw.ac.nz> <4EA8B561.5040105@redhat.com>,<4EA953F3.8040101@redhat.com> <833D8E48405E064EBC54C84EC6B36E40457B3672@STAWINCOX10MBX4.staff.vuw.ac.nz> , <4EA9C04F.9050405@redhat.com> <833D8E48405E064EBC54C84EC6B36E40457B36A1@STAWINCOX10MBX4.staff.vuw.ac.nz> Message-ID: <1319985693.7734.2.camel@willson.li.ssimo.org> I would rather lobby the Linux kernel people to give me 128bit IDs That would solve all problems, as the chance of collision in a carefully randomly selected 90something bit prefix are basically none. Simo. On Thu, 2011-10-27 at 20:40 +0000, Steven Jones wrote: > Yes I can appreciate that, we have done the same thing im '500'... > > oops.... > > As an educational setup we are looking to federate worldwide, that > means Shibboleth or similar....a unique UID per academic world wide > might be worthwhile....there wont be 2billion > academics...students...well i guess that would one day be a "ipv4" > problem. > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Friday, 28 October 2011 9:34 a.m. > To: Steven Jones > Cc: Adam Young; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Unique world wide UIDS > > Steven Jones wrote: > > Hi, > > > > Well if you understand Peak Oil and that the "green revolution" was > actually truning fossil fuel into food ie we eat oil....only having > 2billion UIDs wont be a problem. > > > > :/ > > Many, many organizations start with the same uid base, 500 or 1000. > When > company A buys company B there are tons and tons of uid collisions. If > each started at a random start point then the chances of collision, > while not zero, are much lower. > > Our goal wasn't to guarantee uniqueness in the universe, just to make > integration hopefully easier in the future when namespaces are merged. > > rob > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Sun Oct 30 19:21:56 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 30 Oct 2011 19:21:56 +0000 Subject: [Freeipa-users] Unique world wide UIDS In-Reply-To: <1319985693.7734.2.camel@willson.li.ssimo.org> References: <833D8E48405E064EBC54C84EC6B36E4045793DCD@STAWINCOX10MBX1.staff.vuw.ac.nz> <4EA8B561.5040105@redhat.com>,<4EA953F3.8040101@redhat.com> <833D8E48405E064EBC54C84EC6B36E40457B3672@STAWINCOX10MBX4.staff.vuw.ac.nz> , <4EA9C04F.9050405@redhat.com> <833D8E48405E064EBC54C84EC6B36E40457B36A1@STAWINCOX10MBX4.staff.vuw.ac.nz>, <1319985693.7734.2.camel@willson.li.ssimo.org> Message-ID: <833D8E48405E064EBC54C84EC6B36E40457C9C9D@STAWINCOX10MBX4.staff.vuw.ac.nz> Hi, Yeah I kind of wondered after ipv4 being so well known that "we" only went to 32bit... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Simo Sorce [simo at redhat.com] Sent: Monday, 31 October 2011 3:41 a.m. To: Steven Jones Cc: Rob Crittenden; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unique world wide UIDS I would rather lobby the Linux kernel people to give me 128bit IDs That would solve all problems, as the chance of collision in a carefully randomly selected 90something bit prefix are basically none. Simo. On Thu, 2011-10-27 at 20:40 +0000, Steven Jones wrote: > Yes I can appreciate that, we have done the same thing im '500'... > > oops.... > > As an educational setup we are looking to federate worldwide, that > means Shibboleth or similar....a unique UID per academic world wide > might be worthwhile....there wont be 2billion > academics...students...well i guess that would one day be a "ipv4" > problem. > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Friday, 28 October 2011 9:34 a.m. > To: Steven Jones > Cc: Adam Young; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Unique world wide UIDS > > Steven Jones wrote: > > Hi, > > > > Well if you understand Peak Oil and that the "green revolution" was > actually truning fossil fuel into food ie we eat oil....only having > 2billion UIDs wont be a problem. > > > > :/ > > Many, many organizations start with the same uid base, 500 or 1000. > When > company A buys company B there are tons and tons of uid collisions. If > each started at a random start point then the chances of collision, > while not zero, are much lower. > > Our goal wasn't to guarantee uniqueness in the universe, just to make > integration hopefully easier in the future when namespaces are merged. > > rob > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Sun Oct 30 21:03:07 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 30 Oct 2011 21:03:07 +0000 Subject: [Freeipa-users] problem with replica install Message-ID: <833D8E48405E064EBC54C84EC6B36E40457CDE1F@STAWINCOX10MBX4.staff.vuw.ac.nz> Hi, I am getting this failure, [root at vuwunicoipamt02 ipa]# ipa-replica-install --setup-dns --forwarder=130.195.85.25 --forwarder=130.195.98.151 --no-reverse /var/lib/ipa/replica-info-vuwunicoipamt02.unix.vuw.ac.nz.gpg Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'vuwunicoipamt01.unix.vuw.ac.nz': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: port 80 (80): OK HTTP Server: port 443(https) (443): OK Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master Password for admin at UNIX.VUW.AC.NZ: Execute check on remote master Remote master check failed with following error message(s): Connection check failed! Please fix your network settings according to error messages above. If the check results are not valid it can be skipped with --skip-conncheck parameter. On the first master my firewall ruleset is, ===========8><--------master firewall ruleset-------- ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:88 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:389 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:464 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:636 ACCEPT tcp -- 130.195.87.247 0.0.0.0/0 tcp dpt:9443 ACCEPT tcp -- 130.195.87.247 0.0.0.0/0 tcp dpt:9444 ACCEPT tcp -- 130.195.87.247 0.0.0.0/0 tcp dpt:9445 ACCEPT tcp -- 130.195.87.247 0.0.0.0/0 tcp dpt:7389 ACCEPT tcp -- 130.195.87.248 0.0.0.0/0 tcp dpt:9443 ACCEPT tcp -- 130.195.87.248 0.0.0.0/0 tcp dpt:9444 ACCEPT tcp -- 130.195.87.248 0.0.0.0/0 tcp dpt:9445 ACCEPT tcp -- 130.195.87.248 0.0.0.0/0 tcp dpt:7389 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:88 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:123 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:464 ==========8><------ Cant see what else I have missed...... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Monday, 31 October 2011 8:21 a.m. To: Simo Sorce Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unique world wide UIDS Hi, Yeah I kind of wondered after ipv4 being so well known that "we" only went to 32bit... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Simo Sorce [simo at redhat.com] Sent: Monday, 31 October 2011 3:41 a.m. To: Steven Jones Cc: Rob Crittenden; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unique world wide UIDS I would rather lobby the Linux kernel people to give me 128bit IDs That would solve all problems, as the chance of collision in a carefully randomly selected 90something bit prefix are basically none. Simo. On Thu, 2011-10-27 at 20:40 +0000, Steven Jones wrote: > Yes I can appreciate that, we have done the same thing im '500'... > > oops.... > > As an educational setup we are looking to federate worldwide, that > means Shibboleth or similar....a unique UID per academic world wide > might be worthwhile....there wont be 2billion > academics...students...well i guess that would one day be a "ipv4" > problem. > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Friday, 28 October 2011 9:34 a.m. > To: Steven Jones > Cc: Adam Young; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Unique world wide UIDS > > Steven Jones wrote: > > Hi, > > > > Well if you understand Peak Oil and that the "green revolution" was > actually truning fossil fuel into food ie we eat oil....only having > 2billion UIDs wont be a problem. > > > > :/ > > Many, many organizations start with the same uid base, 500 or 1000. > When > company A buys company B there are tons and tons of uid collisions. If > each started at a random start point then the chances of collision, > while not zero, are much lower. > > Our goal wasn't to guarantee uniqueness in the universe, just to make > integration hopefully easier in the future when namespaces are merged. > > rob > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Mon Oct 31 00:47:31 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 31 Oct 2011 00:47:31 +0000 Subject: [Freeipa-users] problem with replica install In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40457CDE1F@STAWINCOX10MBX4.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40457CDE1F@STAWINCOX10MBX4.staff.vuw.ac.nz> Message-ID: <833D8E48405E064EBC54C84EC6B36E40457D651B@STAWINCOX10MBX4.staff.vuw.ac.nz> Couple of logs I have found..... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Monday, 31 October 2011 10:03 a.m. Cc: freeipa-users at redhat.com Subject: [Freeipa-users] problem with replica install Hi, I am getting this failure, [root at vuwunicoipamt02 ipa]# ipa-replica-install --setup-dns --forwarder=130.195.85.25 --forwarder=130.195.98.151 --no-reverse /var/lib/ipa/replica-info-vuwunicoipamt02.unix.vuw.ac.nz.gpg Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'vuwunicoipamt01.unix.vuw.ac.nz': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: port 80 (80): OK HTTP Server: port 443(https) (443): OK Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master Password for admin at UNIX.VUW.AC.NZ: Execute check on remote master Remote master check failed with following error message(s): Connection check failed! Please fix your network settings according to error messages above. If the check results are not valid it can be skipped with --skip-conncheck parameter. On the first master my firewall ruleset is, ===========8><--------master firewall ruleset-------- ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:88 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:389 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:464 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:636 ACCEPT tcp -- 130.195.87.247 0.0.0.0/0 tcp dpt:9443 ACCEPT tcp -- 130.195.87.247 0.0.0.0/0 tcp dpt:9444 ACCEPT tcp -- 130.195.87.247 0.0.0.0/0 tcp dpt:9445 ACCEPT tcp -- 130.195.87.247 0.0.0.0/0 tcp dpt:7389 ACCEPT tcp -- 130.195.87.248 0.0.0.0/0 tcp dpt:9443 ACCEPT tcp -- 130.195.87.248 0.0.0.0/0 tcp dpt:9444 ACCEPT tcp -- 130.195.87.248 0.0.0.0/0 tcp dpt:9445 ACCEPT tcp -- 130.195.87.248 0.0.0.0/0 tcp dpt:7389 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:88 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:123 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:464 ==========8><------ Cant see what else I have missed...... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Monday, 31 October 2011 8:21 a.m. To: Simo Sorce Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unique world wide UIDS Hi, Yeah I kind of wondered after ipv4 being so well known that "we" only went to 32bit... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Simo Sorce [simo at redhat.com] Sent: Monday, 31 October 2011 3:41 a.m. To: Steven Jones Cc: Rob Crittenden; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unique world wide UIDS I would rather lobby the Linux kernel people to give me 128bit IDs That would solve all problems, as the chance of collision in a carefully randomly selected 90something bit prefix are basically none. Simo. On Thu, 2011-10-27 at 20:40 +0000, Steven Jones wrote: > Yes I can appreciate that, we have done the same thing im '500'... > > oops.... > > As an educational setup we are looking to federate worldwide, that > means Shibboleth or similar....a unique UID per academic world wide > might be worthwhile....there wont be 2billion > academics...students...well i guess that would one day be a "ipv4" > problem. > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Friday, 28 October 2011 9:34 a.m. > To: Steven Jones > Cc: Adam Young; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Unique world wide UIDS > > Steven Jones wrote: > > Hi, > > > > Well if you understand Peak Oil and that the "green revolution" was > actually truning fossil fuel into food ie we eat oil....only having > 2billion UIDs wont be a problem. > > > > :/ > > Many, many organizations start with the same uid base, 500 or 1000. > When > company A buys company B there are tons and tons of uid collisions. If > each started at a random start point then the chances of collision, > while not zero, are much lower. > > Our goal wasn't to guarantee uniqueness in the universe, just to make > integration hopefully easier in the future when namespaces are merged. > > rob > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-conncheck.log Type: application/octet-stream Size: 2145 bytes Desc: ipareplica-conncheck.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-install.log Type: application/octet-stream Size: 1692 bytes Desc: ipareplica-install.log URL: From Steven.Jones at vuw.ac.nz Mon Oct 31 19:25:55 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 31 Oct 2011 19:25:55 +0000 Subject: [Freeipa-users] Youtube Message-ID: <833D8E48405E064EBC54C84EC6B36E4045839049@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Looking for info on freeIPA I came across Simo's talk from 2009.....its a good technical talk but not suitable for managers..... http://www.youtube.com/watch?v=7rljVIVHT6o Any chance of some not to technical "howto" pieces on how things are done? Even simple things like creating users adding to groups and then the BACLs to a server group is really good as it shows off IPA's capability...good intro as well as it demos stuff for admins who have never seen it. I can then also demo such things to my Windows orientated managers if they ask about various aspects of IPA...... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From rmercer at harris.com Mon Oct 31 21:20:04 2011 From: rmercer at harris.com (Rodney Mercer) Date: Mon, 31 Oct 2011 17:20:04 -0400 Subject: [Freeipa-users] Overall Design of Policy Related Components Message-ID: <1320096004.2019.27.camel@ratbert.evn.harris.com> We have previously developed Solaris RBAC authorization within our application to validate users and roles to our application's internal commanding capability using the definitions that populate the name service switch maps. I have been searching for a method for implementing similar capability using RHEL and had found promise with the following proposed documentation for IPAv2: http://freeipa.org/page/Overall_Design_of_Policy_Related_Components#Adding_Support_for_New_applications However backing up within the documentation, I see that this Policy Related Component capability is being deferred. http://www.freeipa.org/page/IPAv2_development_status Is there a defined timeline when the Policy Related Components support for New applications will move forward and be adopted for a RHEL6 update release? Thanks and regards, Rodney. -- Rodney Mercer Systems Administrator