From rmeggins at redhat.com Wed Oct 1 15:42:55 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 01 Oct 2008 09:42:55 -0600 Subject: [Freeipa-devel] Please review: Bug 459729 - Windows sync support in IPA - account disable and force sync In-Reply-To: <48E2691E.3060603@redhat.com> References: <48DD0E4D.2020506@redhat.com> <48E2691E.3060603@redhat.com> Message-ID: <48E39A7F.5050208@redhat.com> Rob Crittenden wrote: > Rich Megginson wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=459729 >> Resolves: bug 459729 >> Bug Description: Windows sync support in IPA - account disable and >> force sync >> Reviewed by: ??? >> Files: see diff >> Branch: HEAD >> Fix Description: Add support for account disable sync and force sync >> * Account disable sync - AD uses the userAccountControl attribute >> ACCOUNTDISABLE value http://support.microsoft.com/kb/305144 >> We have to sync that with the nsAccountLock attribute used by DS. In >> IPA, nsAccountLock is a virtual attribute generated by the membership >> of the user or group in the cn=inactivated group (or enabled if in >> the cn=activated group or not in any group - the account is enabled >> if nsAccountLock is not present). The sync can be done in 1 of 4 >> ways, with the config attribute ipaWinSyncAcctDisable: >> * none - no account disable sync occurs >> * to_ad - account disable is only synced from IPA to AD, not from >> AD to IPA >> * to_ds - account disable is only synced from AD to IPA, not from >> IPA to AD >> * both - account disable is synced in both directions >> I added some code to let the plugin find the cn=inactivated and >> cn=activated groups dynamically >> * Force Sync - by default, the DS will only sync existing IPA users >> if they have the ntUser objectclass, and the ntUserDomainID set to >> the Windows user ID (e.g. the samAccountName). With the config >> attribute ipaWinSyncForceSync set to "true", any IPA user that has a >> matching account in Windows will be forced to be in sync - the IPA >> user will have the ntUser objectclass added automatically, and the >> ntUserDomainID set to the matching account samAccountName value. The >> existing winsync code already handles adding ntUserDomainID, so the >> ipa winsync plugin just has to add ntUser. >> Platforms tested: Fedora 9 >> Flag Day: no >> Doc impact: no >> https://bugzilla.redhat.com/attachment.cgi?id=317807&action=diff > > Assuming I'm reading this properly, you don't need to add users to the > activated group in order to activate them. This group is for override > purposes (has a lower cosPriority). > > We have it so that if a group is inactivated but you want one or more > members to be active you can add them to the activated group. This > will override the group membership in an inactivated group. > > By putting unlocked users into activated you will be preventing them > from being inactivated. Ok. The plugin will not add the user to the activated group when it is enabling the user. > > Is parse_acct_disable() called for each request or only during > initialization? It is a little hard to tell in the context of this > patch. I mention it because you end up doing 4 string compares every > time it runs though. It's only called when the config changes. I cleaned it up to use else if though. Here is the new patch: https://bugzilla.redhat.com/attachment.cgi?id=318214&action=diff > > rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Oct 3 20:25:36 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 03 Oct 2008 14:25:36 -0600 Subject: [Freeipa-devel] Please review: more patches for winsync support Message-ID: <48E67FC0.1070908@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=459729 Resolves: bug 459729 Bug Description: Windows sync support in IPA - account disable and force sync During testing, I found a few issues: add winsync options to man page for ipa-replica-manage - https://bugzilla.redhat.com/attachment.cgi?id=319412&action=diff ipa-replica-manage commands such as init, synch, and list did not work with windows sync agreements - https://bugzilla.redhat.com/attachment.cgi?id=319413&action=diff before installing the Windows CA cert, I stop the server - this just makes the stop unconditional, since I don't care if the server is running or not - https://bugzilla.redhat.com/attachment.cgi?id=319414&action=diff the ntUniqueID and ntUserDomainID indexes exist by default, so we just have to modify them to add eq,pres - https://bugzilla.redhat.com/attachment.cgi?id=319415&action=diff the ipa-winsync plugin must start before MMR so that it can register the API that the winsync code uses - also, the slapi-nis plugin creates an entry just like the default IPA entry containing the default gidNumber to use, so I had (objectclass=groupOfNames) to the search filter - https://bugzilla.redhat.com/attachment.cgi?id=319416&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From bbaker at priefert.com Tue Oct 7 15:08:16 2008 From: bbaker at priefert.com (William Baker) Date: Tue, 07 Oct 2008 10:08:16 -0500 Subject: [Freeipa-devel] using with samba Message-ID: <48EB7B60.2010001@priefert.com> I would like to get FreeIPA working with Samba. Where would I start? My guess is to review the schema requirements for samba. Would 3.2 be a reasonable Samba version to target, or should it be 4.0? Somebody must know of some show stoppers, otherwise it would work out-of-the-box. bbaker From dpal at redhat.com Tue Oct 7 16:12:23 2008 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 07 Oct 2008 12:12:23 -0400 Subject: [Freeipa-devel] using with samba In-Reply-To: <48EB7B60.2010001@priefert.com> References: <48EB7B60.2010001@priefert.com> Message-ID: <48EB8A67.5010900@redhat.com> Hi William, What kind of setup you have in mind? Can you please share your vision with us? The attached is a doc on how to use Samba 3 with IPA but I am not sure that this is what you have in mind. Thanks Dmitri William Baker wrote: > > I would like to get FreeIPA working with Samba. Where would I start? > My guess is to review the schema requirements for samba. Would 3.2 be > a reasonable Samba version to target, or should it be 4.0? > > Somebody must know of some show stoppers, otherwise it would work > out-of-the-box. > > bbaker > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Securing_Samba_with_IPA-1.0.pdf Type: application/pdf Size: 198467 bytes Desc: not available URL: From mike at flyn.org Wed Oct 8 00:25:24 2008 From: mike at flyn.org (W. Michael Petullo) Date: Tue, 7 Oct 2008 20:25:24 -0400 Subject: [Freeipa-devel] Tighter automount integration Message-ID: <8708D5FE-D125-4058-864C-EE0CFCAB8C64@flyn.org> I am interested in implementing tighter integration between automount (autofs) and FreeIPA. There are instructions for using FreeIPA with automount at [1]. However, this currently requires several manual steps. I'd like to see this completely configurable using the FreeIPA GUI and/or install utility. Should I add a new option to Manage Policy -> IPA Policy? Perhaps after "Root for Home Directories" should follow a checkbox, "Automount Home Directories," followed by a text field labeled "Location, e.g., servername:/home?" If checked, FreeIPA would initialize automount's LDAP records. The only problem I see here is that it could cause confusion if a user checked this feature's box after a user's local home directory had already been created. In this case, his home would become unavailable because the remote home would be mounted over it. Another option is to allow ipa-server-install to optionally initialize automount's LDAP records. Does anyone have any comments on which technique would be preferable? For reference, I have submitted a request to Red Hat's Bugzilla, asking that the automount schema be included in the fedora-ds-base package. See [2]. Mike [1] http://freeipa.org/page/AdministratorsGuide#Configuring_automount [2] https://bugzilla.redhat.com/show_bug.cgi?id=441026 From dpal at redhat.com Wed Oct 8 13:49:05 2008 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 08 Oct 2008 09:49:05 -0400 Subject: [Freeipa-devel] Tighter automount integration In-Reply-To: <8708D5FE-D125-4058-864C-EE0CFCAB8C64@flyn.org> References: <8708D5FE-D125-4058-864C-EE0CFCAB8C64@flyn.org> Message-ID: <48ECBA51.4090200@redhat.com> Hi Michael, I am not an automount expert but we plan to have a tighter integration of the automount data with IPA. It will be done in IPA v2 we are currently working on. In v2 the UI is completely rewritten using a new extensible plugin based architecture framework so modifying v1 UI would be a lost work. We are on the verge of making the first cut of this framework and corresponding documentation public. So stay tuned. There will be announcement on the list. What would be helpful is a set of scripts that would pre-populate this data in LDAP with the data from NIS or other source of the automount information. I think the way how the data should be initialized should be left to the administrator but the system should provide several options: a) Migration scripts that transfer auto mount information from other source into LDAP entries in IPA's DS b) UI to set default setting for all users c) UI to manage automount data for individual users d) CLI to manage automount data These UI screens will be new screens for IPA. We are currently working on the new refactored UXD design for v2. Unfortunately they are not published yet. I will be working on publishing different new design and informational pages on freeIPA this and next week. Hope this helps. Thank you Dmitri W. Michael Petullo wrote: > I am interested in implementing tighter integration between automount > (autofs) and FreeIPA. > > There are instructions for using FreeIPA with automount at [1]. > However, this currently requires several manual steps. > > I'd like to see this completely configurable using the FreeIPA GUI > and/or install utility. > > Should I add a new option to Manage Policy -> IPA Policy? Perhaps > after "Root for Home Directories" should follow a checkbox, "Automount > Home Directories," followed by a text field labeled "Location, e.g., > servername:/home?" If checked, FreeIPA would initialize automount's > LDAP records. > > The only problem I see here is that it could cause confusion if a user > checked this feature's box after a user's local home directory had > already been created. In this case, his home would become unavailable > because the remote home would be mounted over it. > > Another option is to allow ipa-server-install to optionally initialize > automount's LDAP records. > > Does anyone have any comments on which technique would be preferable? > > For reference, I have submitted a request to Red Hat's Bugzilla, > asking that the automount schema be included in the fedora-ds-base > package. See [2]. > > Mike > > [1] http://freeipa.org/page/AdministratorsGuide#Configuring_automount > [2] https://bugzilla.redhat.com/show_bug.cgi?id=441026 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mnagy at redhat.com Wed Oct 8 14:31:56 2008 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 8 Oct 2008 16:31:56 +0200 Subject: [Freeipa-devel] [PATCH] Fix a typo in ipa-modgroup causing it to fail Message-ID: <20081008163156.7d021bf3@wolverine.englab.brq.redhat.com> Fix a typo in ipa-modgroup causing it to fail. Fixes: 463567 Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-a-typo-in-ipa-modgroup-causing-it-to-fail.patch Type: text/x-patch Size: 985 bytes Desc: not available URL: From mnagy at redhat.com Wed Oct 8 14:34:17 2008 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 8 Oct 2008 16:34:17 +0200 Subject: [Freeipa-devel] [PATCH] ipa-pwpolicy: correctly compare minlife and maxlife Message-ID: <20081008163417.7ce00977@wolverine.englab.brq.redhat.com> Compare minlife and maxlife correctly ub ipa-pwpolicy. Currently, the comparison is done badly because minlife and maxlife should be treated differently, because minlife is in hours and maxlife in days. Fixes: 463849 Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-ipa-pwpolicy-correctly-compare-minlife-and-maxlife.patch Type: text/x-patch Size: 855 bytes Desc: not available URL: From rcritten at redhat.com Wed Oct 8 14:35:52 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 08 Oct 2008 10:35:52 -0400 Subject: [Freeipa-devel] [PATCH] Fix a typo in ipa-modgroup causing it to fail In-Reply-To: <20081008163156.7d021bf3@wolverine.englab.brq.redhat.com> References: <20081008163156.7d021bf3@wolverine.englab.brq.redhat.com> Message-ID: <48ECC548.3050208@redhat.com> Martin Nagy wrote: > Fix a typo in ipa-modgroup causing it to fail. > Fixes: 463567 > > Martin > > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Oct 8 14:35:58 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 08 Oct 2008 10:35:58 -0400 Subject: [Freeipa-devel] [PATCH] ipa-pwpolicy: correctly compare minlife and maxlife In-Reply-To: <20081008163417.7ce00977@wolverine.englab.brq.redhat.com> References: <20081008163417.7ce00977@wolverine.englab.brq.redhat.com> Message-ID: <48ECC54E.4000904@redhat.com> Martin Nagy wrote: > Compare minlife and maxlife correctly ub ipa-pwpolicy. Currently, the > comparison is done badly because minlife and maxlife should be treated > differently, because minlife is in hours and maxlife in days. > Fixes: 463849 > > Martin > > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Wed Oct 8 14:45:59 2008 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 8 Oct 2008 16:45:59 +0200 Subject: [Freeipa-devel] [PATCH] Fix a typo in ipa-modgroup causing it to fail In-Reply-To: <48ECC548.3050208@redhat.com> References: <20081008163156.7d021bf3@wolverine.englab.brq.redhat.com> <48ECC548.3050208@redhat.com> Message-ID: <20081008164559.20fbd506@wolverine.englab.brq.redhat.com> On Wed, 08 Oct 2008 10:35:52 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > Fix a typo in ipa-modgroup causing it to fail. > > Fixes: 463567 > > > > Martin > > > > > > ack pushed to master From mnagy at redhat.com Wed Oct 8 14:46:09 2008 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 8 Oct 2008 16:46:09 +0200 Subject: [Freeipa-devel] [PATCH] ipa-pwpolicy: correctly compare minlife and maxlife In-Reply-To: <48ECC54E.4000904@redhat.com> References: <20081008163417.7ce00977@wolverine.englab.brq.redhat.com> <48ECC54E.4000904@redhat.com> Message-ID: <20081008164609.48691c89@wolverine.englab.brq.redhat.com> On Wed, 08 Oct 2008 10:35:58 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > Compare minlife and maxlife correctly ub ipa-pwpolicy. Currently, > > the comparison is done badly because minlife and maxlife should be > > treated differently, because minlife is in hours and maxlife in > > days. Fixes: 463849 > > > > Martin > > > > > > ack pushed to master From bbaker at priefert.com Wed Oct 8 15:47:00 2008 From: bbaker at priefert.com (William Baker) Date: Wed, 08 Oct 2008 10:47:00 -0500 Subject: [Freeipa-devel] using with samba In-Reply-To: <48ECB0DF.9010201@redhat.com> References: <48EB7B60.2010001@priefert.com> <48EB8A67.5010900@redhat.com> <48EBA625.5070407@priefert.com> <48EBB5B6.1060404@redhat.com> <48EBD8D1.80004@priefert.com> <48ECB0DF.9010201@redhat.com> Message-ID: <48ECD5F4.3010707@priefert.com> I've seen Penrose before, but never really understood a good use case for it. In this context, maybe it will make more sense. I'll look at it seriously. bbaker > One of the things we were considering for AD integration you are > looking for is to use Penrose virtual directory with IPA. But we have > not quite figured out how to glue things together. > The idea was that Penrose can provide solution for mapping Samba and > IPA DSs trees to each other. We were even thinking about taking pieces > from Samba and adding them to virtual directory. > In this case Penrose could have been a front end to IPA from the > prospective of the AD integration. > May be this would help. > http://docs.safehaus.org/display/PENROSE/Home. > > If you have any Samba specific questions you can ask Gunther Deschner > - he is our Samba team member. > I CC him on this mail. > > Thank you > Dmitri > > William Baker wrote: >> >> I guess my "primary goal" is not well defined. Broadly, it would be >> samba integration. I'll download the current development tree and >> see what pops out. I'm interested in seeing the new plugin interface. >> >> Let's say I wanted to make Samba 3.2 run as PDC using FreeIPA. Sound >> reasonable? >> I'm not sure what's in Samba 3.3 yet. I think it's the Franky >> release, but would appreciate clarification if anyone knows. >> >> bbaker >> >> >>> Hi, >>> >>> You touched on a lot of different issues in one e-mail. >>> I will try to comment inline. >> >> Sorry :) > From rmeggins at redhat.com Wed Oct 8 19:36:16 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 08 Oct 2008 13:36:16 -0600 Subject: [Freeipa-devel] Please review: Windows sync support in IPA - add --win-subtree argument to ipa-replica-manage Message-ID: <48ED0BB0.3020808@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=459729 Resolves: bug 459729 Bug Description: Windows sync support in IPA - add --win-subtree argument to ipa-replica-manage This patch adds a new argument --win-subtree to ipa-replica-manage to allow the user to specify the user data subtree in Windows AD if not the default CN=Users, https://bugzilla.redhat.com/attachment.cgi?id=319786&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Oct 8 20:09:26 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 08 Oct 2008 16:09:26 -0400 Subject: [Freeipa-devel] Please review: Windows sync support in IPA - add --win-subtree argument to ipa-replica-manage In-Reply-To: <48ED0BB0.3020808@redhat.com> References: <48ED0BB0.3020808@redhat.com> Message-ID: <48ED1376.1050807@redhat.com> Rich Megginson wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=459729 > Resolves: bug 459729 > Bug Description: Windows sync support in IPA - add --win-subtree > argument to ipa-replica-manage > > This patch adds a new argument --win-subtree to ipa-replica-manage to > allow the user to specify the user data subtree in Windows AD if not the > default CN=Users, > > https://bugzilla.redhat.com/attachment.cgi?id=319786&action=diff It's hard to see what this is doing without more context. Is win_subtree handled on the server-side already? I only see client-side changes. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Oct 8 20:26:47 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 08 Oct 2008 14:26:47 -0600 Subject: [Freeipa-devel] Please review: Windows sync support in IPA - add --win-subtree argument to ipa-replica-manage In-Reply-To: <48ED1376.1050807@redhat.com> References: <48ED0BB0.3020808@redhat.com> <48ED1376.1050807@redhat.com> Message-ID: <48ED1787.7010405@redhat.com> Rob Crittenden wrote: > Rich Megginson wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=459729 >> Resolves: bug 459729 >> Bug Description: Windows sync support in IPA - add --win-subtree >> argument to ipa-replica-manage >> >> This patch adds a new argument --win-subtree to ipa-replica-manage to >> allow the user to specify the user data subtree in Windows AD if not >> the default CN=Users, >> >> https://bugzilla.redhat.com/attachment.cgi?id=319786&action=diff > > It's hard to see what this is doing without more context. Is > win_subtree handled on the server-side already? I only see client-side > changes. Yes, it's already handled in the replication code in my earlier addition to replication.py - https://bugzilla.redhat.com/attachment.cgi?id=316460&action=diff#a/ipa-server/ipaserver/replication.py_sec2 And since this function already takes a **kargs argument, it was a simple matter to add the key/value in ipa-replica-manage > > rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From t.sailer at alumni.ethz.ch Thu Oct 9 13:54:12 2008 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Thu, 09 Oct 2008 15:54:12 +0200 Subject: [Freeipa-devel] GSSAPI/krb5 troubles after dirsrv restart Message-ID: <1223560452.17106.45.camel@xbox360.hq.axsem.com> After restarting dirsrv, I'm getting the following: # ldapsearch -Y GSSAPI -b "dc=xxxxx,dc=com" SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Permission denied) Needless to say, the ipa-* command line tools and the webgui ceased to work. The dirsrv log shows the following: [09/Oct/2008:15:46:19 +0200] conn=26 fd=72 slot=72 connection from 127.0.0.1 to 127.0.0.1 [09/Oct/2008:15:46:19 +0200] conn=26 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [09/Oct/2008:15:46:19 +0200] conn=26 op=0 RESULT err=49 tag=97 nentries=0 etime=0 [09/Oct/2008:15:46:19 +0200] conn=26 op=-1 fd=72 closed - B1 # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at XXXXX.COM Valid starting Expires Service principal 10/09/08 15:00:06 10/11/08 15:00:03 krbtgt/XXXXX.COM at XXXXX.COM 10/09/08 15:00:12 10/11/08 15:00:03 HTTP/xxx.xxxxx.com at XXXXX.COM 10/09/08 15:08:44 10/11/08 15:00:03 ldap/xxx.xxxxx.com at XXXXX.COM After an attempt at downgrading to the last known to work packages: # rpm -qa 'fedora-ds*' fedora-ds-dsgw-1.1.1-1.fc8 fedora-ds-admin-1.1.5-1.fc8 fedora-ds-base-1.1.1-1.fc8 fedora-ds-base-devel-1.1.1-1.fc8 fedora-ds-console-1.1.1-3.fc8 fedora-ds-1.1.1-2.fc8 fedora-ds-admin-console-1.1.1-3.fc8 However, it didn't work with the current up-to-date fc8 packages either. Does anyone have any idea what went wrong, or how to better locate the culprit? Thanks, Tom From rcritten at redhat.com Thu Oct 9 14:04:09 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 09 Oct 2008 10:04:09 -0400 Subject: [Freeipa-devel] GSSAPI/krb5 troubles after dirsrv restart In-Reply-To: <1223560452.17106.45.camel@xbox360.hq.axsem.com> References: <1223560452.17106.45.camel@xbox360.hq.axsem.com> Message-ID: <48EE0F59.4070603@redhat.com> Thomas Sailer wrote: > After restarting dirsrv, I'm getting the following: > # ldapsearch -Y GSSAPI -b "dc=xxxxx,dc=com" > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Invalid credentials (49) > additional info: SASL(-1): generic failure: GSSAPI Error: > Unspecified GSS failure. Minor code may provide more information > (Permission denied) > > Needless to say, the ipa-* command line tools and the webgui ceased to > work. > > The dirsrv log shows the following: > [09/Oct/2008:15:46:19 +0200] conn=26 fd=72 slot=72 connection from 127.0.0.1 to 127.0.0.1 > [09/Oct/2008:15:46:19 +0200] conn=26 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI > [09/Oct/2008:15:46:19 +0200] conn=26 op=0 RESULT err=49 tag=97 nentries=0 etime=0 > [09/Oct/2008:15:46:19 +0200] conn=26 op=-1 fd=72 closed - B1 > > > # klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at XXXXX.COM > > Valid starting Expires Service principal > 10/09/08 15:00:06 10/11/08 15:00:03 krbtgt/XXXXX.COM at XXXXX.COM > 10/09/08 15:00:12 10/11/08 15:00:03 HTTP/xxx.xxxxx.com at XXXXX.COM > 10/09/08 15:08:44 10/11/08 15:00:03 ldap/xxx.xxxxx.com at XXXXX.COM > > After an attempt at downgrading to the last known to work packages: > # rpm -qa 'fedora-ds*' > fedora-ds-dsgw-1.1.1-1.fc8 > fedora-ds-admin-1.1.5-1.fc8 > fedora-ds-base-1.1.1-1.fc8 > fedora-ds-base-devel-1.1.1-1.fc8 > fedora-ds-console-1.1.1-3.fc8 > fedora-ds-1.1.1-2.fc8 > fedora-ds-admin-console-1.1.1-3.fc8 > > However, it didn't work with the current up-to-date fc8 packages either. > > Does anyone have any idea what went wrong, or how to better locate the > culprit? Check the owner and/or permissions of /etc/dirsrv/ds.keytab. It should be owned by the user that FDS runs as and be mode 0600. Mine looks like: -rw------- 1 dirsrv dirsrv 436 2008-09-17 23:03 /etc/dirsrv/ds.keytab rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Oct 9 14:21:22 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 09 Oct 2008 10:21:22 -0400 Subject: [Freeipa-devel] GSSAPI/krb5 troubles after dirsrv restart In-Reply-To: <1223561172.17106.47.camel@xbox360.hq.axsem.com> References: <1223560452.17106.45.camel@xbox360.hq.axsem.com> <48EE0F59.4070603@redhat.com> <1223561172.17106.47.camel@xbox360.hq.axsem.com> Message-ID: <48EE1362.7090902@redhat.com> Thomas Sailer wrote: > On Thu, 2008-10-09 at 10:04 -0400, Rob Crittenden wrote: > >> Check the owner and/or permissions of /etc/dirsrv/ds.keytab. >> >> It should be owned by the user that FDS runs as and be mode 0600. Mine >> looks like: >> >> -rw------- 1 dirsrv dirsrv 436 2008-09-17 23:03 /etc/dirsrv/ds.keytab > > Mine does too: > > # ls -l /etc/dirsrv/ds.keytab > -rw------- 1 dirsrv dirsrv 484 2008-02-05 12:30 /etc/dirsrv/ds.keytab > > Thanks, > Tom Hmm, ok. It definitely appears to be some file or directory permissions issue. Does the FDS error log have anything interesting in it? A brute-force way to find the answer is to start FDS with strace, something like: # /etc/init.d/dirsrv stop # strace -o /tmp/out -fF /etc/init.d/dirsrv start [ in another session try your search ] [ in another root session ] # /etc/init.d/dirsrv stop Look for EACCES in /tmp/out. Don't be too alarmed about some failures. Kerberos, for example, tries to open /etc/krb5.conf as writable for some reason, but falls back to read-only if that fails. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From t.sailer at alumni.ethz.ch Thu Oct 9 16:19:19 2008 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Thu, 09 Oct 2008 18:19:19 +0200 Subject: [Freeipa-devel] GSSAPI/krb5 troubles after dirsrv restart In-Reply-To: <48EE1362.7090902@redhat.com> References: <1223560452.17106.45.camel@xbox360.hq.axsem.com> <48EE0F59.4070603@redhat.com> <1223561172.17106.47.camel@xbox360.hq.axsem.com> <48EE1362.7090902@redhat.com> Message-ID: <1223569159.4800.8.camel@xbox360.hq.axsem.com> On Thu, 2008-10-09 at 10:21 -0400, Rob Crittenden wrote: > Hmm, ok. It definitely appears to be some file or directory permissions > issue. Does the FDS error log have anything interesting in it? Doesn't seem so: Fedora-Directory/1.1.1 B2008.151.1915 xxx.xxxxx.com:636 (/etc/dirsrv/slapd-XXXXX-COM) [09/Oct/2008:17:47:55 +0200] - Fedora-Directory/1.1.1 B2008.151.1915 starting up [09/Oct/2008:17:47:56 +0200] - slapd started. Listening on All Interfaces port 389 for LDAP requests [09/Oct/2008:17:47:56 +0200] - Listening on All Interfaces port 636 for LDAPS requests [09/Oct/2008:17:48:10 +0200] - slapd shutting down - signaling operation threads [09/Oct/2008:17:48:10 +0200] - slapd shutting down - closing down internal subsystems and plugins [09/Oct/2008:17:48:10 +0200] - Waiting for 4 database threads to stop [09/Oct/2008:17:48:10 +0200] - All database threads now stopped [09/Oct/2008:17:48:10 +0200] - slapd stopped. > A brute-force way to find the answer is to start FDS with strace, > something like: > > # /etc/init.d/dirsrv stop > # strace -o /tmp/out -fF /etc/init.d/dirsrv start That didn't work for me, strace somehow didn't manage to follow the childs. Instead I tried this: strace -o /tmp/out -fF /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-XXXXX-COM -i /var/run/dirsrv/slapd-XXXXX-COM.pid -w /var/run/dirsrv/slapd-XXXXX-COM.startpid Which gave me the trace (but apparently also without following clone's, but this time without error messages about not being able to follow...) No EACCES, also no apparently important failures open'ing or stat'ing. But it also does not try to read ds.keytab. I'm a bit at a loss... Thanks, Tom From t.sailer at alumni.ethz.ch Thu Oct 9 16:31:54 2008 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Thu, 09 Oct 2008 18:31:54 +0200 Subject: [Freeipa-devel] GSSAPI/krb5 troubles after dirsrv restart In-Reply-To: <48EE1362.7090902@redhat.com> References: <1223560452.17106.45.camel@xbox360.hq.axsem.com> <48EE0F59.4070603@redhat.com> <1223561172.17106.47.camel@xbox360.hq.axsem.com> <48EE1362.7090902@redhat.com> Message-ID: <1223569914.4800.26.camel@xbox360.hq.axsem.com> On Thu, 2008-10-09 at 10:21 -0400, Rob Crittenden wrote: Ok, kernel-2.6.26.5-28.fc8 seems to be broken wrt. ptrace, rebooted with kernel-2.6.25.14-69.fc8, now strace works. 3252 access("/etc/sysconfig/init", X_OK) = -1 EACCES (Permission denied) 3252 access("/etc/sysconfig/network", X_OK) = -1 EACCES (Permission denied) 3269 access("/etc/krb5.conf", W_OK) = -1 EACCES (Permission denied) 3291 access("/etc/krb5.conf", W_OK) = -1 EACCES (Permission denied) 3291 access("/etc/krb5.conf", W_OK) = -1 EACCES (Permission denied) 3291 open("/etc/krb5.keytab", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied) 3291 access("/etc/krb5.conf", W_OK) = -1 EACCES (Permission denied) Now I don't know why it tries to read /etc/krb5.keytab, and not /etc/dirsrv/ds.keytab ? Thanks, Tom From ssorce at redhat.com Thu Oct 9 16:55:11 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 09 Oct 2008 12:55:11 -0400 Subject: [Freeipa-devel] GSSAPI/krb5 troubles after dirsrv restart In-Reply-To: <1223569914.4800.26.camel@xbox360.hq.axsem.com> References: <1223560452.17106.45.camel@xbox360.hq.axsem.com> <48EE0F59.4070603@redhat.com> <1223561172.17106.47.camel@xbox360.hq.axsem.com> <48EE1362.7090902@redhat.com> <1223569914.4800.26.camel@xbox360.hq.axsem.com> Message-ID: <1223571311.27822.30.camel@hopeson> On Thu, 2008-10-09 at 18:31 +0200, Thomas Sailer wrote: > On Thu, 2008-10-09 at 10:21 -0400, Rob Crittenden wrote: > > Ok, kernel-2.6.26.5-28.fc8 seems to be broken wrt. ptrace, rebooted with > kernel-2.6.25.14-69.fc8, now strace works. > > 3252 access("/etc/sysconfig/init", X_OK) = -1 EACCES (Permission denied) > 3252 access("/etc/sysconfig/network", X_OK) = -1 EACCES (Permission denied) > 3269 access("/etc/krb5.conf", W_OK) = -1 EACCES (Permission denied) > 3291 access("/etc/krb5.conf", W_OK) = -1 EACCES (Permission denied) > 3291 access("/etc/krb5.conf", W_OK) = -1 EACCES (Permission denied) > 3291 open("/etc/krb5.keytab", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied) > 3291 access("/etc/krb5.conf", W_OK) = -1 EACCES (Permission denied) > > Now I don't know why it tries to read /etc/krb5.keytab, and > not /etc/dirsrv/ds.keytab ? Check /etc/sysconfig/dirsrv it should contain a line that tells DS where to find the right keytab. If that is missing we need to find out why. Simo. From rcritten at redhat.com Thu Oct 9 17:16:43 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 09 Oct 2008 13:16:43 -0400 Subject: [Freeipa-devel] GSSAPI/krb5 troubles after dirsrv restart In-Reply-To: <1223569159.4800.8.camel@xbox360.hq.axsem.com> References: <1223560452.17106.45.camel@xbox360.hq.axsem.com> <48EE0F59.4070603@redhat.com> <1223561172.17106.47.camel@xbox360.hq.axsem.com> <48EE1362.7090902@redhat.com> <1223569159.4800.8.camel@xbox360.hq.axsem.com> Message-ID: <48EE3C7B.7050602@redhat.com> Thomas Sailer wrote: > On Thu, 2008-10-09 at 10:21 -0400, Rob Crittenden wrote: > >> Hmm, ok. It definitely appears to be some file or directory permissions >> issue. Does the FDS error log have anything interesting in it? > > Doesn't seem so: > > Fedora-Directory/1.1.1 B2008.151.1915 > xxx.xxxxx.com:636 (/etc/dirsrv/slapd-XXXXX-COM) > > [09/Oct/2008:17:47:55 +0200] - Fedora-Directory/1.1.1 B2008.151.1915 starting up > [09/Oct/2008:17:47:56 +0200] - slapd started. Listening on All Interfaces port 389 for LDAP requests > [09/Oct/2008:17:47:56 +0200] - Listening on All Interfaces port 636 for LDAPS requests > [09/Oct/2008:17:48:10 +0200] - slapd shutting down - signaling operation threads > [09/Oct/2008:17:48:10 +0200] - slapd shutting down - closing down internal subsystems and plugins > [09/Oct/2008:17:48:10 +0200] - Waiting for 4 database threads to stop > [09/Oct/2008:17:48:10 +0200] - All database threads now stopped > [09/Oct/2008:17:48:10 +0200] - slapd stopped. > >> A brute-force way to find the answer is to start FDS with strace, >> something like: >> >> # /etc/init.d/dirsrv stop >> # strace -o /tmp/out -fF /etc/init.d/dirsrv start > > That didn't work for me, strace somehow didn't manage to follow the > childs. Instead I tried this: > > strace -o /tmp/out -fF /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-XXXXX-COM -i /var/run/dirsrv/slapd-XXXXX-COM.pid -w /var/run/dirsrv/slapd-XXXXX-COM.startpid > > Which gave me the trace (but apparently also without following clone's, > but this time without error messages about not being able to follow...) > > No EACCES, also no apparently important failures open'ing or stat'ing. > But it also does not try to read ds.keytab. > > I'm a bit at a loss... > > Thanks, Tom > Ok, what does /etc/sysconfig/dirsrv contain? It should have something like: export KRB5_KTNAME=/etc/dirsrv/ds.keytab rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From t.sailer at alumni.ethz.ch Thu Oct 9 19:17:40 2008 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Thu, 09 Oct 2008 21:17:40 +0200 Subject: [Freeipa-devel] GSSAPI/krb5 troubles after dirsrv restart In-Reply-To: <48EE3C7B.7050602@redhat.com> References: <1223560452.17106.45.camel@xbox360.hq.axsem.com> <48EE0F59.4070603@redhat.com> <1223561172.17106.47.camel@xbox360.hq.axsem.com> <48EE1362.7090902@redhat.com> <1223569159.4800.8.camel@xbox360.hq.axsem.com> <48EE3C7B.7050602@redhat.com> Message-ID: <1223579860.2583.21.camel@localhost.localdomain> On Thu, 2008-10-09 at 13:16 -0400, Rob Crittenden wrote: > Ok, what does /etc/sysconfig/dirsrv contain? > > It should have something like: export KRB5_KTNAME=/etc/dirsrv/ds.keytab such a line was indeed missing. I've added it and now it works again, thanks a lot! Why it was missing I'm not sure - the most likely explanation is that I made a mistake when merging /etc/sysconfig/dirsrv.rpmnew changes into /etc/sysconfig/dirsrv. Tom From Colin.Simpson at iongeo.com Sun Oct 12 00:42:37 2008 From: Colin.Simpson at iongeo.com (Colin Simpson) Date: Sun, 12 Oct 2008 01:42:37 +0100 Subject: [Freeipa-devel] Tighter automount integration Message-ID: Is it planned for IPA to use Kerberized GSSAPI SASL LDAPS to get the maps, now that autofs supports Kerberos authenticated LDAP for maps? If I'm adding onto my wish list for automount points from a corporate security standpoint, eventual support for NFSv4 kerberized mounts via the automounter would be desired (IPA making this easy to setup and maintain) It is desirable to have no non-kerberized unencrypted data on the network. If I'm on a wish list for things to make IPA work cleanly in a corporate context applying the SSH key exchange patch is really essential (i.e so you don't have to maintain "known hosts" files across loads of machines). Plus the cascading credential support, so ticket renewal propagates to all connected SSH sessions. In the bug report for this, RH seem not too keen to include the available patches until the upstream does (even though lots of other vendors do), and the upstream doesn't seem keen for some reason. I'll shut up now, I'm asking for too much in one email! Thanks Colin This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Oct 13 16:13:58 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 13 Oct 2008 10:13:58 -0600 Subject: [Freeipa-devel] Please review: final winsync patches - rebased on top of latest master Message-ID: <48F373C6.2030401@redhat.com> Here are all of the IPA WinSync patches, rebased on top of the latest master in the IPA git repo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Initial-addition-of-ipa-winsync-plugin.patch Type: text/x-patch Size: 18749 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Added-the-new-IPA-WinSync-Plug-in-Work-done-so-far.patch Type: text/x-patch Size: 10367 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Added-support-for-posixAccount-lookup-attribute-con.patch Type: text/x-patch Size: 11321 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Added-ipa-winsync-config.c-this-handles-dynamic-co.patch Type: text/x-patch Size: 32867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-fix-some-memory-leaks.patch Type: text/x-patch Size: 1681 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Use-dirsrv-file.h-with-includes-by-default-only-us.patch Type: text/x-patch Size: 7876 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-The-library-name-is-libipa_winsync-not-libipa-winsyn.patch Type: text/x-patch Size: 1757 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-Added-support-to-IPA-server-install-to-install-the-w.patch Type: text/x-patch Size: 16831 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0011-add-no-host-dns-option-to-ipa-server-install-all.patch Type: text/x-patch Size: 3969 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012-fix-issues-brought-up-by-initial-review-of-ipa-winsy.patch Type: text/x-patch Size: 3851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0013-Adds-winsync-account-disable-and-force-sync.patch Type: text/x-patch Size: 42932 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0014-add-winsync-options-to-ipa-replica-manage-man-page.patch Type: text/x-patch Size: 1424 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0015-Do-not-add-enabled-user-to-activated-group-clean-u.patch Type: text/x-patch Size: 5324 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0016-Add-more-winsync-support-to-cli.patch Type: text/x-patch Size: 4667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0017-Don-t-try-to-conditionally-stop-the-server-it-does.patch Type: text/x-patch Size: 1009 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0018-Just-add-eq-pres-to-the-existing-indices.patch Type: text/x-patch Size: 1240 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0019-Do-not-depend-on-MMR-plugin-start-before-MMR-plugi.patch Type: text/x-patch Size: 1861 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0020-add-win-subtree-argument-to-ipa-replica-manage.patch Type: text/x-patch Size: 2369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0021-do-not-store-the-OUs-from-the-AD-DN-in-the-IPA-user.patch Type: text/x-patch Size: 2757 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0022-add-update-to-fix-the-index-for-the-winsync-attribut.patch Type: text/x-patch Size: 1430 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Oct 13 17:03:49 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 Oct 2008 13:03:49 -0400 Subject: [Freeipa-devel] Please review: final winsync patches - rebased on top of latest master In-Reply-To: <48F373C6.2030401@redhat.com> References: <48F373C6.2030401@redhat.com> Message-ID: <48F37F75.3050705@redhat.com> Rich Megginson wrote: > Here are all of the IPA WinSync patches, rebased on top of the latest > master in the IPA git repo. Pushed to master and ipa-1-2 rob From rcritten at redhat.com Wed Oct 15 19:00:09 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 15 Oct 2008 15:00:09 -0400 Subject: [Freeipa-devel] [PATCH] fix bug in ldap updater Message-ID: <48F63DB9.5040509@redhat.com> I guess I didn't exercise the 'only' code enough :-( If multiple values are set then it will crap out because I wasn't converting the first one into a python list. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-93-update.patch Type: text/x-patch Size: 1004 bytes Desc: not available URL: From rmeggins at redhat.com Wed Oct 15 19:08:32 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 15 Oct 2008 13:08:32 -0600 Subject: [Freeipa-devel] [PATCH] fix bug in ldap updater In-Reply-To: <48F63DB9.5040509@redhat.com> References: <48F63DB9.5040509@redhat.com> Message-ID: <48F63FB0.9000000@redhat.com> Rob Crittenden wrote: > I guess I didn't exercise the 'only' code enough :-( > > If multiple values are set then it will crap out because I wasn't > converting the first one into a python list. ack > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Oct 15 19:16:03 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 15 Oct 2008 15:16:03 -0400 Subject: [Freeipa-devel] [PATCH] fix bug in ldap updater In-Reply-To: <48F63FB0.9000000@redhat.com> References: <48F63DB9.5040509@redhat.com> <48F63FB0.9000000@redhat.com> Message-ID: <48F64173.5010506@redhat.com> Rich Megginson wrote: > Rob Crittenden wrote: >> I guess I didn't exercise the 'only' code enough :-( >> >> If multiple values are set then it will crap out because I wasn't >> converting the first one into a python list. > ack >> pushed to master and ipa-1-2 From rmeggins at redhat.com Fri Oct 17 23:15:13 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 17 Oct 2008 17:15:13 -0600 Subject: [Freeipa-devel] Notes on server to server sasl Message-ID: <48F91C81.90805@redhat.com> I'm using the current HEAD code. My master is F9 x86_64 and my replica is F8 i386. For the most part, the setup documented here http://freeipa.org/page/InstallAndDeploy works pretty well. Setup 1) I'm not using DNS, just testing with VMs, so I had to make sure my VMs were assigned a consistent IP address via dhcp - and edit /etc/hosts to use the fqdn 2) I did not assign a hostname at install time, so I had to edit /etc/sysconfig/network to assign the hostname and reboot - probably could have done that with dhcp too (anyone know how?) 3) I had to edit the firewall settings to allow 389 and 636 tcp (and udp for good measure) on both the master and replica 4) I added the --no-host-dns option to ipa-server-install, but I'll need to add that to several other ipa- cmd line tools as well - I just hacked them instead to pass in verify_fqdn(name, True) Notes 1) ipa-replica-install did not add a replication agreement from the replica to the master, but it configured the replica as a master (for MMR) - is this expected? 2) There was no principal for ldap/fqdn.of.replica at REALM - do I have to add this manually? I did anyway and it made kerberos happier (but not work) with replication, but it seemed to break lots of stuff on the replica (could no longer ldapsearch -Y GSSAPI on the replica, could not ipa-finduser on the replica) * Server to Server SASL/GSSAPI I modified Fedora DS to do SASL/GSSAPI bind for replication from the master to the replica. I then had to modify /etc/sysconfig/dirsrv to do the following: kinit -k -t /etc/dirsrv/ds.keytab ldap/fqdn.of.master at REALM parse klist to get the tgt filename export KRB5CCNAME=tgtfilename chown dirsrv:dirsrv $KRB5CCNAME I then had to add the ldap host principal for ldap/fqdn.of.replica at REALM (not sure why it wasn't there?). After startup, the master attempts to do a SASL/GSSAPI bind to the replica, and gets this error in kdc5krb log on the master: NO PREAUTH: authtime xxxx, ldap/fqdn.of.master at REALM for ldap/fqdn.of.replica at REALM , Generic error (see e-text) Is what I'm trying to do possible within the IPA kerberos framework? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Sat Oct 18 10:42:14 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 18 Oct 2008 06:42:14 -0400 Subject: [Freeipa-devel] Notes on server to server sasl In-Reply-To: <48F91C81.90805@redhat.com> References: <48F91C81.90805@redhat.com> Message-ID: <1224326534.30024.24.camel@hopeson> On Fri, 2008-10-17 at 17:15 -0600, Rich Megginson wrote: > I'm using the current HEAD code. My master is F9 x86_64 and my replica > is F8 i386. For the most part, the setup documented here > http://freeipa.org/page/InstallAndDeploy works pretty well. > > Setup > 1) I'm not using DNS, just testing with VMs, so I had to make sure my > VMs were assigned a consistent IP address via dhcp - and edit /etc/hosts > to use the fqdn > 2) I did not assign a hostname at install time, so I had to edit > /etc/sysconfig/network to assign the hostname and reboot - probably > could have done that with dhcp too (anyone know how?) > 3) I had to edit the firewall settings to allow 389 and 636 tcp (and udp > for good measure) on both the master and replica > 4) I added the --no-host-dns option to ipa-server-install, but I'll need > to add that to several other ipa- cmd line tools as well - I just hacked > them instead to pass in verify_fqdn(name, True) > > Notes > 1) ipa-replica-install did not add a replication agreement from the > replica to the master, but it configured the replica as a master (for > MMR) - is this expected? Yes they are all masters in freeipa-land so far. > 2) There was no principal for ldap/fqdn.of.replica at REALM - do I have to > add this manually? It should be under cn=kerberos, if you manually add another one in cn=services I guess all you get is a broken system. At the very least you reset the secret and /etc/dirsrv/ds.keytab gets out of sync. > I did anyway and it made kerberos happier (but not > work) with replication, but it seemed to break lots of stuff on the > replica (could no longer ldapsearch -Y GSSAPI on the replica, could not > ipa-finduser on the replica) You broke it indeed. > * Server to Server SASL/GSSAPI > I modified Fedora DS to do SASL/GSSAPI bind for replication from the > master to the replica. I then had to modify /etc/sysconfig/dirsrv to do > the following: > kinit -k -t /etc/dirsrv/ds.keytab ldap/fqdn.of.master at REALM > parse klist to get the tgt filename > export KRB5CCNAME=tgtfilename > chown dirsrv:dirsrv $KRB5CCNAME This will not work, you need to teach dirsrv how to do these operations itself, and how to handle renewals when the TGT expires. Otherwise you just get a hackish thing that works a few hours and then breaks. > I then had to add the ldap host principal for ldap/fqdn.of.replica at REALM > (not sure why it wasn't there?). After startup, the master attempts to > do a SASL/GSSAPI bind to the replica, and gets this error in kdc5krb log > on the master: > NO PREAUTH: authtime xxxx, ldap/fqdn.of.master at REALM > for ldap/fqdn.of.replica at REALM > , Generic error (see e-text) I think this is related to the above explanation. > Is what I'm trying to do possible within the IPA kerberos framework? Yes. Simo. From mike at flyn.org Sat Oct 18 15:15:19 2008 From: mike at flyn.org (W. Michael Petullo) Date: Sat, 18 Oct 2008 11:15:19 -0400 Subject: [Freeipa-devel] Adding groups broken? Message-ID: <41E30B42-B2DD-4E41-AA24-7F466364F30C@flyn.org> I am having trouble adding groups using ipa-server-1.1.0-4.fc9.i386. I added a group, mygroup, using the web interface. However, my user is not a member of the group when I log in. "getent group" says: mock:x:490:user [...] mygroup:*:1100:user "groups" reports that I am a member of mock, but not mygroup. Why is '*' used for IPA groups, while 'x' is used by /etc/group? If I manually add mygroup to /etc/group and use 'x', then my user gets added to mygroup. -- Mike From ssorce at redhat.com Sun Oct 19 22:10:29 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 19 Oct 2008 18:10:29 -0400 Subject: [Freeipa-devel] Adding groups broken? In-Reply-To: <41E30B42-B2DD-4E41-AA24-7F466364F30C@flyn.org> References: <41E30B42-B2DD-4E41-AA24-7F466364F30C@flyn.org> Message-ID: <1224454229.30024.30.camel@hopeson> On Sat, 2008-10-18 at 11:15 -0400, W. Michael Petullo wrote: > I am having trouble adding groups using ipa-server-1.1.0-4.fc9.i386. > I added a group, mygroup, using the web interface. However, my user > is not a member of the group when I log in. > > "getent group" says: > > mock:x:490:user > [...] > mygroup:*:1100:user > > "groups" reports that I am a member of mock, but not mygroup. > > Why is '*' used for IPA groups, while 'x' is used by /etc/group? IT does not matter, the password field for group entries is totally ignored today. > If I manually add mygroup to /etc/group and use 'x', then my user > gets added to mygroup. If you use nscd (as we do) you might not see a change up to one hour after you made it. IIRC You may run 'service nscd reload' to flush the caches. Simo. From rmeggins at redhat.com Mon Oct 20 16:53:13 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 20 Oct 2008 10:53:13 -0600 Subject: [Freeipa-devel] Notes on server to server sasl In-Reply-To: <1224326534.30024.24.camel@hopeson> References: <48F91C81.90805@redhat.com> <1224326534.30024.24.camel@hopeson> Message-ID: <48FCB779.30408@redhat.com> Simo Sorce wrote: > On Fri, 2008-10-17 at 17:15 -0600, Rich Megginson wrote: > >> I'm using the current HEAD code. My master is F9 x86_64 and my replica >> is F8 i386. For the most part, the setup documented here >> http://freeipa.org/page/InstallAndDeploy works pretty well. >> >> Setup >> 1) I'm not using DNS, just testing with VMs, so I had to make sure my >> VMs were assigned a consistent IP address via dhcp - and edit /etc/hosts >> to use the fqdn >> 2) I did not assign a hostname at install time, so I had to edit >> /etc/sysconfig/network to assign the hostname and reboot - probably >> could have done that with dhcp too (anyone know how?) >> 3) I had to edit the firewall settings to allow 389 and 636 tcp (and udp >> for good measure) on both the master and replica >> 4) I added the --no-host-dns option to ipa-server-install, but I'll need >> to add that to several other ipa- cmd line tools as well - I just hacked >> them instead to pass in verify_fqdn(name, True) >> >> Notes >> 1) ipa-replica-install did not add a replication agreement from the >> replica to the master, but it configured the replica as a master (for >> MMR) - is this expected? >> > > Yes they are all masters in freeipa-land so far. > I did this again after fixing some problems - still no replication agreement from replica->master > >> 2) There was no principal for ldap/fqdn.of.replica at REALM - do I have to >> add this manually? >> > > It should be under cn=kerberos, if you manually add another one in > cn=services I guess all you get is a broken system. > At the very least you reset the secret and /etc/dirsrv/ds.keytab gets > out of sync. > Ok. I fixed my problem - now all the principals are there. > >> I did anyway and it made kerberos happier (but not >> work) with replication, but it seemed to break lots of stuff on the >> replica (could no longer ldapsearch -Y GSSAPI on the replica, could not >> ipa-finduser on the replica) >> > > You broke it indeed. > Yep, now fixed. > >> * Server to Server SASL/GSSAPI >> I modified Fedora DS to do SASL/GSSAPI bind for replication from the >> master to the replica. I then had to modify /etc/sysconfig/dirsrv to do >> the following: >> kinit -k -t /etc/dirsrv/ds.keytab ldap/fqdn.of.master at REALM >> parse klist to get the tgt filename >> export KRB5CCNAME=tgtfilename >> chown dirsrv:dirsrv $KRB5CCNAME >> > > This will not work, you need to teach dirsrv how to do these operations > itself, and how to handle renewals when the TGT expires. Otherwise you > just get a hackish thing that works a few hours and then breaks. > Sure. I'll note that this is how openldap does it for server to server sasl - they typically have some sort of script or daemon that renews the ticket. How else should this be done? > >> I then had to add the ldap host principal for ldap/fqdn.of.replica at REALM >> (not sure why it wasn't there?). After startup, the master attempts to >> do a SASL/GSSAPI bind to the replica, and gets this error in kdc5krb log >> on the master: >> NO PREAUTH: authtime xxxx, ldap/fqdn.of.master at REALM >> for ldap/fqdn.of.replica at REALM >> , Generic error (see e-text) >> > > I think this is related to the above explanation. > > >> Is what I'm trying to do possible within the IPA kerberos framework? >> > > Yes. > > Simo. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Tue Oct 21 03:24:35 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 21 Oct 2008 14:24:35 +1100 Subject: [Freeipa-devel] using with samba In-Reply-To: <48EB7B60.2010001@priefert.com> References: <48EB7B60.2010001@priefert.com> Message-ID: <1224559475.3494.49.camel@ruth> On Tue, 2008-10-07 at 10:08 -0500, William Baker wrote: > I would like to get FreeIPA working with Samba. Where would I start? > My guess is to review the schema requirements for samba. Would 3.2 be a > reasonable Samba version to target, or should it be 4.0? > > Somebody must know of some show stoppers, otherwise it would work > out-of-the-box. Are you aiming for an AD domain controller, an NT4 domain controller or a member (file) server? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Tue Oct 21 10:17:12 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 21 Oct 2008 06:17:12 -0400 Subject: [Freeipa-devel] Notes on server to server sasl In-Reply-To: <48FCB779.30408@redhat.com> References: <48F91C81.90805@redhat.com> <1224326534.30024.24.camel@hopeson> <48FCB779.30408@redhat.com> Message-ID: <1224584232.8815.32.camel@hopeson> On Mon, 2008-10-20 at 10:53 -0600, Rich Megginson wrote: > Simo Sorce wrote: > > On Fri, 2008-10-17 at 17:15 -0600, Rich Megginson wrote: > > > >> I'm using the current HEAD code. My master is F9 x86_64 and my replica > >> is F8 i386. For the most part, the setup documented here > >> http://freeipa.org/page/InstallAndDeploy works pretty well. > >> > >> Setup > >> 1) I'm not using DNS, just testing with VMs, so I had to make sure my > >> VMs were assigned a consistent IP address via dhcp - and edit /etc/hosts > >> to use the fqdn > >> 2) I did not assign a hostname at install time, so I had to edit > >> /etc/sysconfig/network to assign the hostname and reboot - probably > >> could have done that with dhcp too (anyone know how?) > >> 3) I had to edit the firewall settings to allow 389 and 636 tcp (and udp > >> for good measure) on both the master and replica > >> 4) I added the --no-host-dns option to ipa-server-install, but I'll need > >> to add that to several other ipa- cmd line tools as well - I just hacked > >> them instead to pass in verify_fqdn(name, True) > >> > >> Notes > >> 1) ipa-replica-install did not add a replication agreement from the > >> replica to the master, but it configured the replica as a master (for > >> MMR) - is this expected? > >> > > > > Yes they are all masters in freeipa-land so far. > > > I did this again after fixing some problems - still no replication > agreement from replica->master The script failed to create it ? > > This will not work, you need to teach dirsrv how to do these operations > > itself, and how to handle renewals when the TGT expires. Otherwise you > > just get a hackish thing that works a few hours and then breaks. > > > Sure. I'll note that this is how openldap does it for server to server > sasl - they typically have some sort of script or daemon that renews the > ticket. > > How else should this be done? I think you have a couple of ways. 1. if the connections are long lived you could decide to always acquire a new TGT before try to establish a connection. 2. if connections are frequent, you might decide to check before a connection if credentials are still valid and renew if not. 3. You have another task running periodically that refreshes credentials. Simo. From rmeggins at redhat.com Tue Oct 21 14:09:43 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 21 Oct 2008 08:09:43 -0600 Subject: [Freeipa-devel] Notes on server to server sasl In-Reply-To: <1224584232.8815.32.camel@hopeson> References: <48F91C81.90805@redhat.com> <1224326534.30024.24.camel@hopeson> <48FCB779.30408@redhat.com> <1224584232.8815.32.camel@hopeson> Message-ID: <48FDE2A7.3060206@redhat.com> Simo Sorce wrote: > On Mon, 2008-10-20 at 10:53 -0600, Rich Megginson wrote: > >> Simo Sorce wrote: >> >>> On Fri, 2008-10-17 at 17:15 -0600, Rich Megginson wrote: >>> >>> >>>> I'm using the current HEAD code. My master is F9 x86_64 and my replica >>>> is F8 i386. For the most part, the setup documented here >>>> http://freeipa.org/page/InstallAndDeploy works pretty well. >>>> >>>> Setup >>>> 1) I'm not using DNS, just testing with VMs, so I had to make sure my >>>> VMs were assigned a consistent IP address via dhcp - and edit /etc/hosts >>>> to use the fqdn >>>> 2) I did not assign a hostname at install time, so I had to edit >>>> /etc/sysconfig/network to assign the hostname and reboot - probably >>>> could have done that with dhcp too (anyone know how?) >>>> 3) I had to edit the firewall settings to allow 389 and 636 tcp (and udp >>>> for good measure) on both the master and replica >>>> 4) I added the --no-host-dns option to ipa-server-install, but I'll need >>>> to add that to several other ipa- cmd line tools as well - I just hacked >>>> them instead to pass in verify_fqdn(name, True) >>>> >>>> Notes >>>> 1) ipa-replica-install did not add a replication agreement from the >>>> replica to the master, but it configured the replica as a master (for >>>> MMR) - is this expected? >>>> >>>> >>> Yes they are all masters in freeipa-land so far. >>> >>> >> I did this again after fixing some problems - still no replication >> agreement from replica->master >> > > The script failed to create it ? > Yes. And I didn't see any errors in ipareplica-install.log, or any attempt to add a replication agreement that might have failed. > >>> This will not work, you need to teach dirsrv how to do these operations >>> itself, and how to handle renewals when the TGT expires. Otherwise you >>> just get a hackish thing that works a few hours and then breaks. >>> >>> >> Sure. I'll note that this is how openldap does it for server to server >> sasl - they typically have some sort of script or daemon that renews the >> ticket. >> >> How else should this be done? >> > > I think you have a couple of ways. > > 1. if the connections are long lived you could decide to always acquire > a new TGT before try to establish a connection. > > 2. if connections are frequent, you might decide to check before a > connection if credentials are still valid and renew if not. > > 3. You have another task running periodically that refreshes > credentials. > Andrew pointed me at some code in Samba4 that should do what we need. I'm going to test it out with the ds. > Simo. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From bbaker at priefert.com Mon Oct 27 19:41:21 2008 From: bbaker at priefert.com (William Baker) Date: Mon, 27 Oct 2008 14:41:21 -0500 Subject: [Freeipa-devel] using with samba In-Reply-To: <1224559475.3494.49.camel@ruth> References: <48EB7B60.2010001@priefert.com> <1224559475.3494.49.camel@ruth> Message-ID: <49061961.2040306@priefert.com> My question was about both, though vague. For samba 3.2, the objective would be NT4 domain controller, and for samba 4.0 the objective would be AD domain controller. I've since narrowed my objective to AD domain controller. I've been following the mail list, but haven't been able to characterize the magnitude of changes going into 4.0 or its usability. I was hoping to see another alpha release to use as a starting point. I think I'm just going to have to dive into the git repository and see what happens. I haven't done anything on it yet, but I know where to start. With any luck, I'll start putting the pieces together later this week. bbaker > On Tue, 2008-10-07 at 10:08 -0500, William Baker wrote: > >> I would like to get FreeIPA working with Samba. Where would I start? >> My guess is to review the schema requirements for samba. Would 3.2 be a >> reasonable Samba version to target, or should it be 4.0? >> >> Somebody must know of some show stoppers, otherwise it would work >> out-of-the-box. >> > > Are you aiming for an AD domain controller, an NT4 domain controller or > a member (file) server? > > Andrew Bartlett > > From dpal at redhat.com Mon Oct 27 21:49:56 2008 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 27 Oct 2008 17:49:56 -0400 Subject: [Freeipa-devel] using with samba In-Reply-To: <49061961.2040306@priefert.com> References: <48EB7B60.2010001@priefert.com> <1224559475.3494.49.camel@ruth> <49061961.2040306@priefert.com> Message-ID: <49063784.8010903@redhat.com> William, I think the main challenge on this route is overcoming schema differences. This is probably the main issue - mapping attributes in Samba 4 and IPA's back end DS. Other problems include that fact that IPA uses MIT kerberos and Fedora DS while Samba is based on Heimdal and OpenLDAP. If you plan to use one and the same back end this would have to be sorted out first. If you plan to use some kind of synchronization between Samba back end and IPA's DS you would need to solve at least mapping problem and then the synchronization itself which is usually a big task. May be using some kind of the virtual directory solution like Penrose for mapping of two structures to each other would be a good starting point. Thank you Dmitri William Baker wrote: > My question was about both, though vague. For samba 3.2, the > objective would be NT4 domain controller, and for samba 4.0 the > objective would be AD domain controller. > > I've since narrowed my objective to AD domain controller. I've been > following the mail list, but haven't been able to characterize the > magnitude of changes going into 4.0 or its usability. I was hoping to > see another alpha release to use as a starting point. I think I'm > just going to have to dive into the git repository and see what happens. > > I haven't done anything on it yet, but I know where to start. With > any luck, I'll start putting the pieces together later this week. > > bbaker > >> On Tue, 2008-10-07 at 10:08 -0500, William Baker wrote: >> >>> I would like to get FreeIPA working with Samba. Where would I >>> start? My guess is to review the schema requirements for samba. >>> Would 3.2 be a reasonable Samba version to target, or should it be 4.0? >>> >>> Somebody must know of some show stoppers, otherwise it would work >>> out-of-the-box. >>> >> >> Are you aiming for an AD domain controller, an NT4 domain controller or >> a member (file) server? >> >> Andrew Bartlett >> >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Wed Oct 29 17:40:18 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 29 Oct 2008 13:40:18 -0400 Subject: [Freeipa-devel] [PATCH] assign unique replica ID to all instances Message-ID: <4908A002.1090906@redhat.com> Ensure that every replica gets a unique replication ID. Otherwise changes won't propogate between all replicas. I create a new entry, cn=replication, cn=etc, that will hold the next replication ID to assign. When a new replica is being created it requests this number, then increments it and writes it back. This does leave some amount of exposure to a collision but I think the risk is quite low. Creating replicas is a very uncommon activity. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-94-replication.patch Type: text/x-patch Size: 4832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Oct 29 18:36:19 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 29 Oct 2008 14:36:19 -0400 Subject: [Freeipa-devel] [PATCH] fix apache conf upgrade tool Message-ID: <4908AD23.2030402@redhat.com> Don't report spurious upgrade message if IPA has not been configured yet. This was throwing the error "Unable to determine hostname from ipa-rewrite.conf" during RPM %post on unconfigured servers where there is nothing to do. Instead exit gracefully if ipa-rewrite.conf diesn't exist. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-95-upgrade.patch Type: text/x-patch Size: 1904 bytes Desc: not available URL: From mnagy at redhat.com Wed Oct 29 19:16:19 2008 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 29 Oct 2008 20:16:19 +0100 Subject: [Freeipa-devel] [PATCH] fix apache conf upgrade tool In-Reply-To: <4908AD23.2030402@redhat.com> References: <4908AD23.2030402@redhat.com> Message-ID: <20081029201619.531ed5ba@notas> Rob Crittenden wrote: > Don't report spurious upgrade message if IPA has not been configured > yet. > > This was throwing the error > "Unable to determine hostname from ipa-rewrite.conf" > during RPM %post on unconfigured servers where there is nothing to do. > > Instead exit gracefully if ipa-rewrite.conf diesn't exist. > > rob ack From rcritten at redhat.com Wed Oct 29 21:10:10 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 29 Oct 2008 17:10:10 -0400 Subject: [Freeipa-devel] [PATCH] fix apache conf upgrade tool In-Reply-To: <20081029201619.531ed5ba@notas> References: <4908AD23.2030402@redhat.com> <20081029201619.531ed5ba@notas> Message-ID: <4908D132.1050401@redhat.com> Martin Nagy wrote: > Rob Crittenden wrote: >> Don't report spurious upgrade message if IPA has not been configured >> yet. >> >> This was throwing the error >> "Unable to determine hostname from ipa-rewrite.conf" >> during RPM %post on unconfigured servers where there is nothing to do. >> >> Instead exit gracefully if ipa-rewrite.conf diesn't exist. >> >> rob > ack Pushed to master and ipa-1-2 rob From rcritten at redhat.com Wed Oct 29 21:10:28 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 29 Oct 2008 17:10:28 -0400 Subject: [Freeipa-devel] [PATCH] assign unique replica ID to all instances In-Reply-To: <4908CAF3.6070302@redhat.com> References: <4908A002.1090906@redhat.com> <4908CAF3.6070302@redhat.com> Message-ID: <4908D144.3090109@redhat.com> Nathan Kinder wrote: > Rob Crittenden wrote: >> Ensure that every replica gets a unique replication ID. Otherwise >> changes won't propogate between all replicas. >> >> I create a new entry, cn=replication, cn=etc, that will hold the next >> replication ID to assign. When a new replica is being created it >> requests this number, then increments it and writes it back. >> >> This does leave some amount of exposure to a collision but I think the >> risk is quite low. Creating replicas is a very uncommon activity. > ack >> > pushed to master and ipa-1-2 From ssorce at redhat.com Thu Oct 30 12:51:27 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 30 Oct 2008 08:51:27 -0400 Subject: [Freeipa-devel] [PATCH] assign unique replica ID to all instances In-Reply-To: <4908A002.1090906@redhat.com> References: <4908A002.1090906@redhat.com> Message-ID: <1225371087.5137.1.camel@localhost.localdomain> On Wed, 2008-10-29 at 13:40 -0400, Rob Crittenden wrote: > Ensure that every replica gets a unique replication ID. Otherwise > changes won't propogate between all replicas. > > I create a new entry, cn=replication, cn=etc, that will hold the next > replication ID to assign. When a new replica is being created it > requests this number, then increments it and writes it back. > > This does leave some amount of exposure to a collision but I think > the > risk is quite low. Creating replicas is a very uncommon activity. Does it need to be a progressive number ? If the integer is big enough we could also use a timestamp instead and avoid having to keep track in tree ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Oct 30 12:54:31 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 30 Oct 2008 08:54:31 -0400 Subject: [Freeipa-devel] [PATCH] assign unique replica ID to all instances In-Reply-To: <1225371087.5137.1.camel@localhost.localdomain> References: <4908A002.1090906@redhat.com> <1225371087.5137.1.camel@localhost.localdomain> Message-ID: <4909AE87.2000101@redhat.com> Simo Sorce wrote: > On Wed, 2008-10-29 at 13:40 -0400, Rob Crittenden wrote: >> Ensure that every replica gets a unique replication ID. Otherwise >> changes won't propogate between all replicas. >> >> I create a new entry, cn=replication, cn=etc, that will hold the next >> replication ID to assign. When a new replica is being created it >> requests this number, then increments it and writes it back. >> >> This does leave some amount of exposure to a collision but I think >> the >> risk is quite low. Creating replicas is a very uncommon activity. > > Does it need to be a progressive number ? > If the integer is big enough we could also use a timestamp instead and > avoid having to keep track in tree ? > > Simo. > It has to be an int between 0 and something like 65534. rob From rcritten at redhat.com Thu Oct 30 13:36:16 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 30 Oct 2008 09:36:16 -0400 Subject: [Freeipa-devel] [PATCH] handle exception in ipa-ldap-updater Message-ID: <4909B850.3050302@redhat.com> Catch an unconfigured IPA server exception in ipa-ldap-updater. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-96-updater.patch Type: text/x-patch Size: 781 bytes Desc: not available URL: From ssorce at redhat.com Thu Oct 30 13:54:35 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 30 Oct 2008 09:54:35 -0400 Subject: [Freeipa-devel] [PATCH] assign unique replica ID to all instances In-Reply-To: <4909AE87.2000101@redhat.com> References: <4908A002.1090906@redhat.com> <1225371087.5137.1.camel@localhost.localdomain> <4909AE87.2000101@redhat.com> Message-ID: <1225374875.5137.14.camel@localhost.localdomain> On Thu, 2008-10-30 at 08:54 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Wed, 2008-10-29 at 13:40 -0400, Rob Crittenden wrote: > >> Ensure that every replica gets a unique replication ID. Otherwise > >> changes won't propogate between all replicas. > >> > >> I create a new entry, cn=replication, cn=etc, that will hold the next > >> replication ID to assign. When a new replica is being created it > >> requests this number, then increments it and writes it back. > >> > >> This does leave some amount of exposure to a collision but I think > >> the > >> risk is quite low. Creating replicas is a very uncommon activity. > > > > Does it need to be a progressive number ? > > If the integer is big enough we could also use a timestamp instead and > > avoid having to keep track in tree ? > > > > Simo. > > > > It has to be an int between 0 and something like 65534. oh, ok, then the current approach is the best one. thanks! Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Oct 30 14:10:28 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 30 Oct 2008 10:10:28 -0400 Subject: [Freeipa-devel] [PATCH] handle exception in ipa-ldap-updater In-Reply-To: <4909B850.3050302@redhat.com> References: <4909B850.3050302@redhat.com> Message-ID: <1225375828.5137.16.camel@localhost.localdomain> On Thu, 2008-10-30 at 09:36 -0400, Rob Crittenden wrote: > Catch an unconfigured IPA server exception in ipa-ldap-updater. ack -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Oct 30 14:25:52 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 30 Oct 2008 10:25:52 -0400 Subject: [Freeipa-devel] [PATCH] handle exception in ipa-ldap-updater In-Reply-To: <1225375828.5137.16.camel@localhost.localdomain> References: <4909B850.3050302@redhat.com> <1225375828.5137.16.camel@localhost.localdomain> Message-ID: <4909C3F0.70100@redhat.com> Simo Sorce wrote: > On Thu, 2008-10-30 at 09:36 -0400, Rob Crittenden wrote: >> Catch an unconfigured IPA server exception in ipa-ldap-updater. > > ack > pushed to master and ipa-1-2 From rcritten at redhat.com Thu Oct 30 19:20:22 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 30 Oct 2008 15:20:22 -0400 Subject: [Freeipa-devel] [PATCH] fix groups in UI Message-ID: <490A08F6.2060307@redhat.com> The UI was throwing an error in validation when adding new groups. Ignore attributes that we don't know about, but don't consider them an error. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-97-group.patch Type: text/x-patch Size: 894 bytes Desc: not available URL: From dpal at redhat.com Fri Oct 31 14:39:13 2008 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 Oct 2008 10:39:13 -0400 Subject: [Freeipa-devel] using with samba In-Reply-To: <49063784.8010903@redhat.com> References: <48EB7B60.2010001@priefert.com> <1224559475.3494.49.camel@ruth> <49061961.2040306@priefert.com> <49063784.8010903@redhat.com> Message-ID: <490B1891.6060001@redhat.com> Hi William, I need to correct myself a bit. Samba 4 can use different back ends. The primary back end it uses is the LDB - internal LDAP style storage. It is fast and efficient. The alternative back end Samba 4 can use is OpenLDAP. This work more experimental but OpenLDAP currently seems to be more feature rich from the prospective of Samba4 then Fedora DS. The FreeIPA uses Fedora DS as a back end. For the task of bringing Samba 4 and IPA together the options would be to try to use one and the same back end or synch data if there will be two. In both cases the mapping of entries, attributes and DITs would be the first biggest problem to solve. Thank you Dmitri Dmitri Pal wrote: > William, > > I think the main challenge on this route is overcoming schema > differences. This is probably the main issue - mapping attributes in > Samba 4 and IPA's back end DS. > Other problems include that fact that IPA uses MIT kerberos and Fedora > DS while Samba is based on Heimdal and OpenLDAP. If you plan to use > one and the same back end this would have to be sorted out first. If > you plan to use some kind of synchronization between Samba back end > and IPA's DS you would need to solve at least mapping problem and then > the synchronization itself which is usually a big task. May be using > some kind of the virtual directory solution like Penrose for mapping > of two structures to each other would be a good starting point. > > Thank you > Dmitri > > William Baker wrote: >> My question was about both, though vague. For samba 3.2, the >> objective would be NT4 domain controller, and for samba 4.0 the >> objective would be AD domain controller. >> >> I've since narrowed my objective to AD domain controller. I've been >> following the mail list, but haven't been able to characterize the >> magnitude of changes going into 4.0 or its usability. I was hoping >> to see another alpha release to use as a starting point. I think I'm >> just going to have to dive into the git repository and see what happens. >> >> I haven't done anything on it yet, but I know where to start. With >> any luck, I'll start putting the pieces together later this week. >> >> bbaker >> >>> On Tue, 2008-10-07 at 10:08 -0500, William Baker wrote: >>> >>>> I would like to get FreeIPA working with Samba. Where would I >>>> start? My guess is to review the schema requirements for samba. >>>> Would 3.2 be a reasonable Samba version to target, or should it be >>>> 4.0? >>>> >>>> Somebody must know of some show stoppers, otherwise it would work >>>> out-of-the-box. >>>> >>> >>> Are you aiming for an AD domain controller, an NT4 domain controller or >>> a member (file) server? >>> >>> Andrew Bartlett >>> >>> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rmeggins at redhat.com Fri Oct 31 14:51:40 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 31 Oct 2008 08:51:40 -0600 Subject: [Freeipa-devel] Notes on server to server sasl In-Reply-To: <1224584232.8815.32.camel@hopeson> References: <48F91C81.90805@redhat.com> <1224326534.30024.24.camel@hopeson> <48FCB779.30408@redhat.com> <1224584232.8815.32.camel@hopeson> Message-ID: <490B1B7C.9070106@redhat.com> Simo Sorce wrote: > On Mon, 2008-10-20 at 10:53 -0600, Rich Megginson wrote: > >> Simo Sorce wrote: >> >>> On Fri, 2008-10-17 at 17:15 -0600, Rich Megginson wrote: >>> >>> >>>> I'm using the current HEAD code. My master is F9 x86_64 and my replica >>>> is F8 i386. For the most part, the setup documented here >>>> http://freeipa.org/page/InstallAndDeploy works pretty well. >>>> >>>> Setup >>>> 1) I'm not using DNS, just testing with VMs, so I had to make sure my >>>> VMs were assigned a consistent IP address via dhcp - and edit /etc/hosts >>>> to use the fqdn >>>> 2) I did not assign a hostname at install time, so I had to edit >>>> /etc/sysconfig/network to assign the hostname and reboot - probably >>>> could have done that with dhcp too (anyone know how?) >>>> 3) I had to edit the firewall settings to allow 389 and 636 tcp (and udp >>>> for good measure) on both the master and replica >>>> 4) I added the --no-host-dns option to ipa-server-install, but I'll need >>>> to add that to several other ipa- cmd line tools as well - I just hacked >>>> them instead to pass in verify_fqdn(name, True) >>>> >>>> Notes >>>> 1) ipa-replica-install did not add a replication agreement from the >>>> replica to the master, but it configured the replica as a master (for >>>> MMR) - is this expected? >>>> >>>> >>> Yes they are all masters in freeipa-land so far. >>> >>> >> I did this again after fixing some problems - still no replication >> agreement from replica->master >> > > The script failed to create it ? > > >>> This will not work, you need to teach dirsrv how to do these operations >>> itself, and how to handle renewals when the TGT expires. Otherwise you >>> just get a hackish thing that works a few hours and then breaks. >>> >>> >> Sure. I'll note that this is how openldap does it for server to server >> sasl - they typically have some sort of script or daemon that renews the >> ticket. >> >> How else should this be done? >> > > I think you have a couple of ways. > > 1. if the connections are long lived you could decide to always acquire > a new TGT before try to establish a connection. > I decided to take this approach. The connections are relatively long lived and infrequently acquired. > 2. if connections are frequent, you might decide to check before a > connection if credentials are still valid and renew if not. > Is there a way to do this without actually attempting to authenticate? I've tried the validation functions, but I get an error from the KDC to the effect of "validation is not permitted". > 3. You have another task running periodically that refreshes > credentials. > > Simo. > > From ssorce at redhat.com Fri Oct 31 15:16:42 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 31 Oct 2008 11:16:42 -0400 Subject: [Freeipa-devel] Notes on server to server sasl In-Reply-To: <490B1B7C.9070106@redhat.com> References: <48F91C81.90805@redhat.com> <1224326534.30024.24.camel@hopeson> <48FCB779.30408@redhat.com> <1224584232.8815.32.camel@hopeson> <490B1B7C.9070106@redhat.com> Message-ID: <1225466202.5137.47.camel@localhost.localdomain> On Fri, 2008-10-31 at 08:51 -0600, Rich Megginson wrote: > Simo Sorce wrote: > > 1. if the connections are long lived you could decide to always acquire > > a new TGT before try to establish a connection. > > > I decided to take this approach. The connections are relatively long > lived and infrequently acquired. Just one thing. Depending on kerberos libraries, if you run paste the credential expiration the connection may be dropped. I assume that is not a problem as a connection may always be dropped for whatever reason and I assume DS already have code to handle the situation in these cases. > > 2. if connections are frequent, you might decide to check before a > > connection if credentials are still valid and renew if not. > > > Is there a way to do this without actually attempting to authenticate? > I've tried the validation functions, but I get an error from the KDC to > the effect of "validation is not permitted". The credential cache contains the expiration date of the credentials, you should be able to check without contacting the KDC (and we do not want to contact the KDC at all, unless we need to acquire a ticket). Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Fri Oct 31 15:18:54 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 31 Oct 2008 09:18:54 -0600 Subject: [Freeipa-devel] Notes on server to server sasl In-Reply-To: <1225466202.5137.47.camel@localhost.localdomain> References: <48F91C81.90805@redhat.com> <1224326534.30024.24.camel@hopeson> <48FCB779.30408@redhat.com> <1224584232.8815.32.camel@hopeson> <490B1B7C.9070106@redhat.com> <1225466202.5137.47.camel@localhost.localdomain> Message-ID: <490B21DE.106@redhat.com> Simo Sorce wrote: > On Fri, 2008-10-31 at 08:51 -0600, Rich Megginson wrote: > >> Simo Sorce wrote: >> > > >>> 1. if the connections are long lived you could decide to always acquire >>> a new TGT before try to establish a connection. >>> >>> >> I decided to take this approach. The connections are relatively long >> lived and infrequently acquired. >> > > Just one thing. Depending on kerberos libraries, if you run paste the > credential expiration the connection may be dropped. I assume that is > not a problem as a connection may always be dropped for whatever reason > and I assume DS already have code to handle the situation in these > cases. > Yes, that should be fine. > >>> 2. if connections are frequent, you might decide to check before a >>> connection if credentials are still valid and renew if not. >>> >>> >> Is there a way to do this without actually attempting to authenticate? >> I've tried the validation functions, but I get an error from the KDC to >> the effect of "validation is not permitted". >> > > The credential cache contains the expiration date of the credentials, > you should be able to check without contacting the KDC (and we do not > want to contact the KDC at all, unless we need to acquire a ticket). > So if current datetime < cred expiration datetime, then the creds are ok? No other validation needs to be done? > Simo. > > From ssorce at redhat.com Fri Oct 31 16:21:11 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 31 Oct 2008 12:21:11 -0400 Subject: [Freeipa-devel] Notes on server to server sasl In-Reply-To: <490B21DE.106@redhat.com> References: <48F91C81.90805@redhat.com> <1224326534.30024.24.camel@hopeson> <48FCB779.30408@redhat.com> <1224584232.8815.32.camel@hopeson> <490B1B7C.9070106@redhat.com> <1225466202.5137.47.camel@localhost.localdomain> <490B21DE.106@redhat.com> Message-ID: <1225470071.5137.51.camel@localhost.localdomain> On Fri, 2008-10-31 at 09:18 -0600, Rich Megginson wrote: > > The credential cache contains the expiration date of the credentials, > > you should be able to check without contacting the KDC (and we do not > > want to contact the KDC at all, unless we need to acquire a ticket). > > > So if current datetime < cred expiration datetime, then the creds are > ok? No other validation needs to be done? Usually it is safe to assume so. The only exception is someone generating a new key for the service, and replacing the service keytab instead of appending to it (so that the older key material with the previous kvno is not longer available to the server which cannot verify older credentials still valid). In this case you should get back an auth error. You may decide at this point to discard the current ticket and try to acquire a new one. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Fri Oct 31 16:26:35 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 31 Oct 2008 10:26:35 -0600 Subject: [Freeipa-devel] Notes on server to server sasl In-Reply-To: <1225470071.5137.51.camel@localhost.localdomain> References: <48F91C81.90805@redhat.com> <1224326534.30024.24.camel@hopeson> <48FCB779.30408@redhat.com> <1224584232.8815.32.camel@hopeson> <490B1B7C.9070106@redhat.com> <1225466202.5137.47.camel@localhost.localdomain> <490B21DE.106@redhat.com> <1225470071.5137.51.camel@localhost.localdomain> Message-ID: <490B31BB.2070501@redhat.com> Simo Sorce wrote: > On Fri, 2008-10-31 at 09:18 -0600, Rich Megginson wrote: > > >>> The credential cache contains the expiration date of the credentials, >>> you should be able to check without contacting the KDC (and we do not >>> want to contact the KDC at all, unless we need to acquire a ticket). >>> >>> >> So if current datetime < cred expiration datetime, then the creds are >> ok? No other validation needs to be done? >> > > Usually it is safe to assume so. > The only exception is someone generating a new key for the service, and > replacing the service keytab instead of appending to it (so that the > older key material with the previous kvno is not longer available to the > server which cannot verify older credentials still valid). > > In this case you should get back an auth error. You may decide at this > point to discard the current ticket and try to acquire a new one. > Ok. Hmm - seems that my code will need to add some further complexity. Right now it just takes the first entry from the server's keytab file and uses that for authentication. Is it possible the keytab may contain entries that cannot/should not be used? > Simo. > > From rcritten at redhat.com Fri Oct 31 16:35:49 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 31 Oct 2008 12:35:49 -0400 Subject: [Freeipa-devel] [PATCH] ship replication update file Message-ID: <490B33E5.2060306@redhat.com> I forgot to update Makefile.am with the last replication patch. I've gone and and pushed this to master and ipa-1-0 under the 1-liner rule. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-98-replication.patch Type: text/x-patch Size: 770 bytes Desc: not available URL: From ssorce at redhat.com Fri Oct 31 17:35:01 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 31 Oct 2008 13:35:01 -0400 Subject: [Freeipa-devel] Notes on server to server sasl In-Reply-To: <490B31BB.2070501@redhat.com> References: <48F91C81.90805@redhat.com> <1224326534.30024.24.camel@hopeson> <48FCB779.30408@redhat.com> <1224584232.8815.32.camel@hopeson> <490B1B7C.9070106@redhat.com> <1225466202.5137.47.camel@localhost.localdomain> <490B21DE.106@redhat.com> <1225470071.5137.51.camel@localhost.localdomain> <490B31BB.2070501@redhat.com> Message-ID: <1225474501.5137.61.camel@localhost.localdomain> On Fri, 2008-10-31 at 10:26 -0600, Rich Megginson wrote: > Simo Sorce wrote: > > On Fri, 2008-10-31 at 09:18 -0600, Rich Megginson wrote: > > > > > >>> The credential cache contains the expiration date of the credentials, > >>> you should be able to check without contacting the KDC (and we do not > >>> want to contact the KDC at all, unless we need to acquire a ticket). > >>> > >>> > >> So if current datetime < cred expiration datetime, then the creds are > >> ok? No other validation needs to be done? > >> > > > > Usually it is safe to assume so. > > The only exception is someone generating a new key for the service, and > > replacing the service keytab instead of appending to it (so that the > > older key material with the previous kvno is not longer available to the > > server which cannot verify older credentials still valid). > > > > In this case you should get back an auth error. You may decide at this > > point to discard the current ticket and try to acquire a new one. > > > Ok. Hmm - seems that my code will need to add some further complexity. > Right now it just takes the first entry from the server's keytab file > and uses that for authentication. Is it possible the keytab may contain > entries that cannot/should not be used? You manually parse the keytab ? In a keytab you can have entries for many different services, as well multiple entries for the same service but with different kvno. The highest kvno is the newest one and should be the one to be used. Older keys can be used only to accept valid tickets in the time-frame that the old keys are still valid. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Oct 31 18:17:15 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 31 Oct 2008 14:17:15 -0400 Subject: [Freeipa-devel] [PATCH] fix groups in UI In-Reply-To: <490A08F6.2060307@redhat.com> References: <490A08F6.2060307@redhat.com> Message-ID: <1225477035.5137.65.camel@localhost.localdomain> On Thu, 2008-10-30 at 15:20 -0400, Rob Crittenden wrote: > The UI was throwing an error in validation when adding new groups. > Ignore attributes that we don't know about, but don't consider them > an > error. ack -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Oct 31 18:29:15 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 31 Oct 2008 14:29:15 -0400 Subject: [Freeipa-devel] [PATCH] fix groups in UI In-Reply-To: <1225477035.5137.65.camel@localhost.localdomain> References: <490A08F6.2060307@redhat.com> <1225477035.5137.65.camel@localhost.localdomain> Message-ID: <490B4E7B.1060508@redhat.com> Simo Sorce wrote: > On Thu, 2008-10-30 at 15:20 -0400, Rob Crittenden wrote: >> The UI was throwing an error in validation when adding new groups. >> Ignore attributes that we don't know about, but don't consider them >> an >> error. > > ack > Pushed to ipa-1-2 and master rob From rmeggins at redhat.com Fri Oct 31 18:36:19 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 31 Oct 2008 12:36:19 -0600 Subject: [Freeipa-devel] Notes on server to server sasl In-Reply-To: <1225474501.5137.61.camel@localhost.localdomain> References: <48F91C81.90805@redhat.com> <1224326534.30024.24.camel@hopeson> <48FCB779.30408@redhat.com> <1224584232.8815.32.camel@hopeson> <490B1B7C.9070106@redhat.com> <1225466202.5137.47.camel@localhost.localdomain> <490B21DE.106@redhat.com> <1225470071.5137.51.camel@localhost.localdomain> <490B31BB.2070501@redhat.com> <1225474501.5137.61.camel@localhost.localdomain> Message-ID: <490B5023.70000@redhat.com> Simo Sorce wrote: > On Fri, 2008-10-31 at 10:26 -0600, Rich Megginson wrote: > >> Simo Sorce wrote: >> >>> On Fri, 2008-10-31 at 09:18 -0600, Rich Megginson wrote: >>> >>> >>> >>>>> The credential cache contains the expiration date of the credentials, >>>>> you should be able to check without contacting the KDC (and we do not >>>>> want to contact the KDC at all, unless we need to acquire a ticket). >>>>> >>>>> >>>>> >>>> So if current datetime < cred expiration datetime, then the creds are >>>> ok? No other validation needs to be done? >>>> >>>> >>> Usually it is safe to assume so. >>> The only exception is someone generating a new key for the service, and >>> replacing the service keytab instead of appending to it (so that the >>> older key material with the previous kvno is not longer available to the >>> server which cannot verify older credentials still valid). >>> >>> In this case you should get back an auth error. You may decide at this >>> point to discard the current ticket and try to acquire a new one. >>> >>> >> Ok. Hmm - seems that my code will need to add some further complexity. >> Right now it just takes the first entry from the server's keytab file >> and uses that for authentication. Is it possible the keytab may contain >> entries that cannot/should not be used? >> > > You manually parse the keytab ? > I need a principal to pass to krb5_get_init_creds_keytab. I do not have a way for the user to specify the principal. I need a principal that actually exists in the keytab, so I use krb5_kt_start_seq_get/krb5_kt_next_entry/krb5_kt_end_seq_get to iterate the keytab entries, grabbing the first principal. > In a keytab you can have entries for many different services, For the directory server service keytab? It will have principals other than ldap/fqdn at REALM? > as well > multiple entries for the same service but with different kvno. > The highest kvno is the newest one and should be the one to be used. > Older keys can be used only to accept valid tickets in the time-frame > that the old keys are still valid. > eek - then how is the code supposed to know which principal to use? > Simo. > > From ssorce at redhat.com Fri Oct 31 18:49:21 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 31 Oct 2008 14:49:21 -0400 Subject: [Freeipa-devel] Notes on server to server sasl In-Reply-To: <490B5023.70000@redhat.com> References: <48F91C81.90805@redhat.com> <1224326534.30024.24.camel@hopeson> <48FCB779.30408@redhat.com> <1224584232.8815.32.camel@hopeson> <490B1B7C.9070106@redhat.com> <1225466202.5137.47.camel@localhost.localdomain> <490B21DE.106@redhat.com> <1225470071.5137.51.camel@localhost.localdomain> <490B31BB.2070501@redhat.com> <1225474501.5137.61.camel@localhost.localdomain> <490B5023.70000@redhat.com> Message-ID: <1225478961.5137.72.camel@localhost.localdomain> On Fri, 2008-10-31 at 12:36 -0600, Rich Megginson wrote: > Simo Sorce wrote: > > On Fri, 2008-10-31 at 10:26 -0600, Rich Megginson wrote: > > > >> Simo Sorce wrote: > >> > >>> On Fri, 2008-10-31 at 09:18 -0600, Rich Megginson wrote: > >>> > >>> > >>> > >>>>> The credential cache contains the expiration date of the credentials, > >>>>> you should be able to check without contacting the KDC (and we do not > >>>>> want to contact the KDC at all, unless we need to acquire a ticket). > >>>>> > >>>>> > >>>>> > >>>> So if current datetime < cred expiration datetime, then the creds are > >>>> ok? No other validation needs to be done? > >>>> > >>>> > >>> Usually it is safe to assume so. > >>> The only exception is someone generating a new key for the service, and > >>> replacing the service keytab instead of appending to it (so that the > >>> older key material with the previous kvno is not longer available to the > >>> server which cannot verify older credentials still valid). > >>> > >>> In this case you should get back an auth error. You may decide at this > >>> point to discard the current ticket and try to acquire a new one. > >>> > >>> > >> Ok. Hmm - seems that my code will need to add some further complexity. > >> Right now it just takes the first entry from the server's keytab file > >> and uses that for authentication. Is it possible the keytab may contain > >> entries that cannot/should not be used? > >> > > > > You manually parse the keytab ? > > > I need a principal to pass to krb5_get_init_creds_keytab. I do not have > a way for the user to specify the principal. I need a principal that > actually exists in the keytab, so I use > krb5_kt_start_seq_get/krb5_kt_next_entry/krb5_kt_end_seq_get to iterate > the keytab entries, grabbing the first principal. The principal is ldap/fqdn.of.host at DEFAULT-REALM The default realm is easy to get with kerberos calls. The host fqdn is what you get from gethostname() The ldap prefix is fixed. No matter what's in the keytab, that's your principal. If that's not what's in the keytab it is an error anyway, clients will never be able to reach you. If you want to make it configurable you should have a configure option in dse.ldif Parsing the keytab is not a good idea IMO. > > In a keytab you can have entries for many different services, > For the directory server service keytab? It will have principals other > than ldap/fqdn at REALM? it may easily be a symlink to /etc/krb5.keytab and there you will probably have at least host/fqdn at REALM, and maybe nfs/fqdn at REALM, or something else ... do not assume what's in the keytab, there is no need to, let the kerberos libraries handle details as much as possible. > > as well > > multiple entries for the same service but with different kvno. > > The highest kvno is the newest one and should be the one to be used. > > Older keys can be used only to accept valid tickets in the time-frame > > that the old keys are still valid. > > > eek - then how is the code supposed to know which principal to use? See above. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Oct 31 19:13:15 2008 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 Oct 2008 15:13:15 -0400 Subject: [Freeipa-devel] New IPA v2 draft designs posted on freeIPA Message-ID: <490B58CB.8080509@redhat.com> Hello, We collected a lot of different design materials that we have written over the last month but have not made public yet. Sorry for being a little bit behind. We are trying to advance project in a lot of different directions and I really did not anticipate the volume of the information I will have to deal with. So the draft design pages are now published on the http://www.freeipa.org/page/DocumentationV2. They are not curved in stone. All these ideas are subject for your review and feedback. Everybody is welcome to suggest alternative approaches or add to proposed vision. Your opinion is important! Let us discuss these designs on different freeIPA lists. More pages to come soon. Thank you, Dmitri Pal From dpal at redhat.com Fri Oct 31 19:56:19 2008 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 Oct 2008 15:56:19 -0400 Subject: [Freeipa-devel] Suggested additions to codding standard page on freeIPA wiki. Message-ID: <490B62E3.2070705@redhat.com> Hello, In addition to the coding guidelines published on freeIPA.org the following (currently undefined) rules are suggested: *Spaces:* No tabs all indentation 4 spaces. *Length of line: * Not more than 100-110 characters. Just keep it reasonable. Longer lines are harder to deal with due to different sized of monitors and different editors used. *Module structure: * The module should be structured in the following order: * Copyright boilerplate * Includes * Local defines ? used only inside module. Global/shared defines should be in the header * Local module typedefs - Global/shared typedefs should be in the header * Module variable declarations ? variables that are global for the module. * Declarations of external functions * Declarations of static functions * Implementation of the exposed functions from the module * Implementation of the static functions It is not required but recommended to group and position functions in the module so that it is easier to understand. *Comments: * Sections (groups of functions) can be separated with a line of comments like this: /************ Main Interface Functions ****************/ Or this /********* Static Internal Functions **********/ Each function must have a comment describing what this function does and returns. There is no specific format for this but it is a good practice to describe what parameters mean and what return codes function returns under what conditions. Inside the function comments should help reader to digest the logic of the function. They should answer the main question ?why is this line of code here and what it tries to accomplish??. Not everything should be commented but practice shows that comments giving the hint about what the developer what trying to accomplish with this or that construct usually turn out to be pretty helpful. *Naming of the variables: * There are multiple different styles that developers usually use to name variables. It can be very short like ?ctx? or ??buf?; more explicit ?context? or ?buffer? ; detailed using underscore ?hash_context? or ?input_buffer?; detailed using capital letters ?hashContext? or ?inputBuffer? all these ways of naming variables are acceptable though low case with underscore is preferable and highly recommended. The developers should not start variables with capital letter. It is beneficial and thus suggested to use self explanatory names for variables that carry significant information. Variables that are used to perform a simple operation and act as a temporary storage can have shorter names. Do not use Hungarian notation (prefixing variable with the type). The only exception to the rule is pointers. The following example illustrates the case: void function_that_does_something(data_set inventory) { int number_items =0; err=get_number_of_items_in_set(inventory, number_items); ... } int get_number_of_items_in_set(data_set inventory, int* p_number_items) { ... } In this case the variable in the second function is related to the variable in the calling function but it is a pointer. This is useful since naming variables same will cause confusion with type (especially if there will be cutting and pasting of code which I use to do a lot), and naming them differently will break the relation. Like having number_items in one function and item_count in the other and one is actually a pointer to another is hard to work with. Prefixing with "p_" solves the issue nicely. *Names of the functions: * Looking at the code (server.c for example) I have seen all sorts of names for functions used in one module: setup_signals(void) BlockSignals(true, SIGPIPE); poptGetNextOpt(pc) We should try to stick to one style which will be low case, multi word, _ separated like: monitor_task_init(struct task_server *task); * Declarations * Major declarations such as typedef's, stuct tags, etc. deserve to be identifiable on their own in some fashion. Often this was done with an initial cap, but since we're using lower_case_with_underscores then I think the convention of appending "_t" is a good way to go and is consistent with the Posix and kernel conventions. Other name formats should not be used unless it is an external function we do not have control over. The wiki page will be updated based on this discussion. Thanks Dmitri From ssorce at redhat.com Fri Oct 31 20:35:18 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 31 Oct 2008 16:35:18 -0400 Subject: [Freeipa-devel] Suggested additions to codding standard page on freeIPA wiki. In-Reply-To: <490B62E3.2070705@redhat.com> References: <490B62E3.2070705@redhat.com> Message-ID: <1225485318.5137.104.camel@localhost.localdomain> On Fri, 2008-10-31 at 15:56 -0400, Dmitri Pal wrote: > Hello, > > In addition to the coding guidelines published on freeIPA.org the > following (currently undefined) rules are suggested: > > *Spaces:* > > No tabs all indentation 4 spaces. ack > *Length of line: * > > Not more than 100-110 characters. Just keep it reasonable. Longer lines > are harder to deal with due to different sized of monitors and different > editors used. I am for strict adherence to not more than 80 chars per line. While I myself used to use up to 120 chars I found out that 80 lines is more usable in many situations, including debugging python code/C code on a console, letting people use their tools of choice, and yes, fitting 3 terminals in a row :-) > *Module structure: * > > The module should be structured in the following order: > * Copyright boilerplate > * Includes > * Local defines ? used only inside module. Global/shared defines should > be in the header > * Local module typedefs - Global/shared typedefs should be in the header I would like to discourage use of typdefs unless really necessary, like when a very basic type is defined. I find the code is much more comprehensible if a struct is immediately recognizable as such as well as pointers. > * Module variable declarations ? variables that are global for the module. Global variables should be discouraged as well, they make for very poor code. Should be used only if no other way can be found. They tend to be not thread/async safe > * Declarations of external functions Should not be needed, usually headers should contain foreign functions definitions. > * Declarations of static functions I find it much easier to declare functions only if they need to be referenced before the body of the function is defined. Otherwise just use the ordering in the file to avoid declarations. > * Implementation of the exposed functions from the module > * Implementation of the static functions Given the above comment, static functions usually come first. > It is not required but recommended to group and position functions in > the module so that it is easier to understand. This is very controversial, for me easier to understand is when the innermost function is first in the file and the outermost is last, but for some that seem an unnatural bottom to top ordering. > *Comments: * > > Sections (groups of functions) can be separated with a line of comments > like this: > > /************ Main Interface Functions ****************/ > > Or this > > /********* Static Internal Functions **********/ Is it really necessary to state this? Static functions are usually pretty obviously static ... Also I usually prefer to keep static functions related to a specific public function close to said function so that there is no need to jump around the file when checking what a related function does. > Each function must have a comment describing what this function does and > returns. > There is no specific format for this but it is a good practice to > describe what parameters mean and what return codes function returns > under what conditions. > > Inside the function comments should help reader to digest the logic of > the function. They should answer the main question ?why is this line of > code here and what it tries to accomplish??. Not everything should be > commented but practice shows that comments giving the hint about what > the developer what trying to accomplish with this or that construct > usually turn out to be pretty helpful. This is fine as long as we don't have things like: int i = x +1; /* add 1 to x and assign it to i */ Let's avoid useless comments :-) > *Naming of the variables: * > > > There are multiple different styles that developers usually use to name > variables. It can be very short like ?ctx? or ??buf?; more explicit > ?context? or ?buffer? ; detailed using underscore ?hash_context? or > ?input_buffer?; detailed using capital letters ?hashContext? or > ?inputBuffer? all these ways of naming variables are acceptable though > low case with underscore is preferable and highly recommended. +1 > The > developers should not start variables with capital letter. It is > beneficial and thus suggested to use self explanatory names for > variables that carry significant information. Variables that are used to > perform a simple operation and act as a temporary storage can have > shorter names. +1 > Do not use Hungarian notation (prefixing variable with the type). The > only exception to the rule is pointers. The following example > illustrates the case: > > void function_that_does_something(data_set inventory) { > int number_items =0; > > err=get_number_of_items_in_set(inventory, number_items); > ... > } > > int get_number_of_items_in_set(data_set inventory, int* p_number_items) { > ... > } This definition is redundant, int * already defines the variable as pointer. Please let's avoid the insane Hungarian Notation completely. > In this case the variable in the second function is related to the > variable in the calling function but it is a pointer. This is useful > since naming variables same will cause confusion with type (especially > if there will be cutting and pasting of code which I use to do a lot), > and naming them differently will break the relation. Like having > number_items in one function and item_count in the other and one is > actually a pointer to another is hard to work with. Prefixing with "p_" > solves the issue nicely. No, the compiler solves any issue nicely, it will tell you if you are using the wrong type. > *Names of the functions: * > > Looking at the code (server.c for example) I have seen all sorts of > names for functions used in one module: > > setup_signals(void) > BlockSignals(true, SIGPIPE); > poptGetNextOpt(pc) > > We should try to stick to one style which will be low case, multi word, > _ separated like: > monitor_task_init(struct task_server *task); The later is the preferred form, poptGetNextOpt and BlockSignals come from external libraries, so we have no control over them. > * Declarations * > Major declarations such as typedef's, stuct tags, etc. deserve to be > identifiable on their own in some fashion. > Often this was done with an initial cap, but since we're using > lower_case_with_underscores then I think the convention of appending > "_t" is a good way to go and is consistent with the Posix and kernel > conventions. Only if we are defining a new type, something very rare. Again I am for avoiding typedefs altogether except for rare cases. If I need a structure to hold something a bout a socket this is how it should be defined: struct socket_stuff { int foo; long bar; struct baz; }; no typdefs. > Other name formats should not be used unless it is an external function > we do not have control over. > > The wiki page will be updated based on this discussion. Thanks. I'd like to add some more style related conventions I tend to use. Function definitions: Always define a function on one line with the opening parenthesis on the next line. Example: struct foobar *foo_bar_fn(int foo, int bar) { Do not put the "{" on the same line or the return type on a previous line like. Example of NOT ok declaration: struct foobar * foo_bar_fn(int foo, int bar) { if the function declaration does not fit 80 chars, put arguments after the first on following lines and indent them to start after the "(" Example: int very_long_function_name_that_makes_arguments_not_fit_80(int foo, int bar) { Do not put spaces before or after parenthesis: OK: int foo(int bar, int baz); NOT OK: bad ( arg1 , arg2 ); Avoid complex variable initializations (like calling functions) when declaring variables like: int foobar = get_foobar(baz); but split it in: int foobar; foobar = get_foobar(baz); This makes it simpler to follow code in a debugger, and also avoid forgetting to test the return value of the function for errors. Always declare all variables at the top of the function, normally try to avoid declaring local variables in internal loops. Use only C style comments /* blah */ and not C++ style comment: // blah Add to these the coding style predicaments already available on freeipa.org :-) Simo -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Oct 31 21:14:19 2008 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 Oct 2008 17:14:19 -0400 Subject: [Freeipa-devel] Suggested additions to codding standard page on freeIPA wiki. In-Reply-To: <1225485318.5137.104.camel@localhost.localdomain> References: <490B62E3.2070705@redhat.com> <1225485318.5137.104.camel@localhost.localdomain> Message-ID: <490B752B.9010305@redhat.com> Simo Sorce wrote: > On Fri, 2008-10-31 at 15:56 -0400, Dmitri Pal wrote: > > >> *Length of line: * >> >> Not more than 100-110 characters. Just keep it reasonable. Longer lines >> are harder to deal with due to different sized of monitors and different >> editors used. >> > > I am for strict adherence to not more than 80 chars per line. > While I myself used to use up to 120 chars I found out that 80 lines is > more usable in many situations, including debugging python code/C code > on a console, letting people use their tools of choice, and yes, fitting > 3 terminals in a row :-) > > I think 80 is to short with the modern monitors and screens. We should not limit us but try no to be overwhelmingly long >> *Module structure: * >> >> The module should be structured in the following order: >> * Copyright boilerplate >> * Includes >> * Local defines ? used only inside module. Global/shared defines should >> be in the header >> * Local module typedefs - Global/shared typedefs should be in the header >> > > I would like to discourage use of typdefs unless really necessary, like > when a very basic type is defined. I find the code is much more > comprehensible if a struct is immediately recognizable as such as well > as pointers. > > I think this is should be formulated as preference with suggestion not to use typedefs. >> * Module variable declarations ? variables that are global for the module. >> > > Global variables should be discouraged as well, they make for very poor > code. Should be used only if no other way can be found. They tend to be > not thread/async safe > > Agree. But if there are some they should be covered. >> * Declarations of external functions >> > > Should not be needed, usually headers should contain foreign functions > definitions. > > Agree. The word usually is crucial here. Sometimes you have collisions on the headers in this case you need to include things explicitly. But this is more an indication of the bad header design. >> * Declarations of static functions >> > > I find it much easier to declare functions only if they need to be > referenced before the body of the function is defined. Otherwise just > use the ordering in the file to avoid declarations. > > I agree but this should be a preference not a rule. >> * Implementation of the exposed functions from the module >> * Implementation of the static functions >> > > Given the above comment, static functions usually come first. > > I kind of disagree. This should be a preference. >> It is not required but recommended to group and position functions in >> the module so that it is easier to understand. >> > > This is very controversial, for me easier to understand is when the > innermost function is first in the file and the outermost is last, but > for some that seem an unnatural bottom to top ordering. > > No it is not. I think this allows you to follow your natural flaw of logic and me mine. I prefer implementing the functions that are main to the module first and stub out the functions that I need. So naturally I read the code the same way. I do not care about the details and low level functions that act as helpers. I want to see and concentrate on the core functionality and not dig it into the module to find it scattered somewhere in the middle or in the bottom. I guess this is a personal preference so I would suggest leaving it as it was spelled. >> *Comments: * >> >> Sections (groups of functions) can be separated with a line of comments >> like this: >> >> /************ Main Interface Functions ****************/ >> >> Or this >> >> /********* Static Internal Functions **********/ >> > > Is it really necessary to state this? Static functions are usually > pretty obviously static ... Also I usually prefer to keep static > functions related to a specific public function close to said function > so that there is no need to jump around the file when checking what a > related function does. > > Yes. I think it will. It will help you with your approach to processing code to read the code I write and vice versa. These things are very helpful when you face the code that is organized in the way it is not intuitive for you to digest. >> Each function must have a comment describing what this function does and >> returns. >> There is no specific format for this but it is a good practice to >> describe what parameters mean and what return codes function returns >> under what conditions. >> >> Inside the function comments should help reader to digest the logic of >> the function. They should answer the main question ?why is this line of >> code here and what it tries to accomplish??. Not everything should be >> commented but practice shows that comments giving the hint about what >> the developer what trying to accomplish with this or that construct >> usually turn out to be pretty helpful. >> > > This is fine as long as we don't have things like: > > int i = x +1; /* add 1 to x and assign it to i */ > > Let's avoid useless comments :-) > > Agree. > > >> Do not use Hungarian notation (prefixing variable with the type). The >> only exception to the rule is pointers. The following example >> illustrates the case: >> >> void function_that_does_something(data_set inventory) { >> int number_items =0; >> >> err=get_number_of_items_in_set(inventory, number_items); >> ... >> } >> >> int get_number_of_items_in_set(data_set inventory, int* p_number_items) { >> ... >> } >> > > This definition is redundant, int * already defines the variable as pointer. > Please let's avoid the insane Hungarian Notation completely. > > >> In this case the variable in the second function is related to the >> variable in the calling function but it is a pointer. This is useful >> since naming variables same will cause confusion with type (especially >> if there will be cutting and pasting of code which I use to do a lot), >> and naming them differently will break the relation. Like having >> number_items in one function and item_count in the other and one is >> actually a pointer to another is hard to work with. Prefixing with "p_" >> solves the issue nicely. >> > > No, the compiler solves any issue nicely, it will tell you if you are > using the wrong type. > > There are cases when these things caused a lot of trouble. Not explicitly indicating pointers where variables are both pointers and just variables IMO makes the code much harder to read and maintain. I just makes things harder for no value but if others insist I would not resist. Any other opinions? >> *Names of the functions: * >> >> Looking at the code (server.c for example) I have seen all sorts of >> names for functions used in one module: >> >> setup_signals(void) >> BlockSignals(true, SIGPIPE); >> poptGetNextOpt(pc) >> >> We should try to stick to one style which will be low case, multi word, >> _ separated like: >> monitor_task_init(struct task_server *task); >> > > The later is the preferred form, poptGetNextOpt and BlockSignals come > from external libraries, so we have no control over them. > > Yes. >> * Declarations * >> Major declarations such as typedef's, stuct tags, etc. deserve to be >> identifiable on their own in some fashion. >> Often this was done with an initial cap, but since we're using >> lower_case_with_underscores then I think the convention of appending >> "_t" is a good way to go and is consistent with the Posix and kernel >> conventions. >> > > Only if we are defining a new type, something very rare. Again I am for > avoiding typedefs altogether except for rare cases. > > If I need a structure to hold something a bout a socket this is how it > should be defined: > > struct socket_stuff { > int foo; > long bar; > struct baz; > }; > > no typdefs. > > Well... I kind of disagree but I can live with that. >> Other name formats should not be used unless it is an external function >> we do not have control over. >> >> The wiki page will be updated based on this discussion. >> > > Thanks. > > > I'd like to add some more style related conventions I tend to use. > > Function definitions: > > Always define a function on one line with the opening parenthesis on the > next line. > Example: > struct foobar *foo_bar_fn(int foo, int bar) > { > > Do not put the "{" on the same line or the return type on a previous > line like. > > +1 > Example of NOT ok declaration: > struct foobar * > foo_bar_fn(int foo, int bar) { > > if the function declaration does not fit 80 chars, put arguments after > the first on following lines and indent them to start after the "(" > > Example: > int very_long_function_name_that_makes_arguments_not_fit_80(int foo, > int bar) > { > > > +1 > Do not put spaces before or after parenthesis: > > OK: int foo(int bar, int baz); > NOT OK: bad ( arg1 , arg2 ); > > > +1 > Avoid complex variable initializations (like calling functions) when > declaring variables like: > > int foobar = get_foobar(baz); > > but split it in: > int foobar; > > foobar = get_foobar(baz); > > +1 > This makes it simpler to follow code in a debugger, and also avoid > forgetting to test the return value of the function for errors. > > > Always declare all variables at the top of the function, normally try to > avoid declaring local variables in internal loops. > > +1 > Use only C style comments /* blah */ and not C++ style comment: // blah > > > +1 > Add to these the coding style predicaments already available on > freeipa.org :-) > > > I am planning to add this back to freeIPA.org Any other opinions and suggestions? > Simo > >