From ssorce at redhat.com Mon Nov 2 12:33:52 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 02 Nov 2009 07:33:52 -0500 Subject: Fwd: [Freeipa-users] Library to change expired password In-Reply-To: <6835906b0911011926j231f1722w4f52b85ce3a095ec@mail.gmail.com> References: <6835906b0910291456h455cea3axae38727060ce9532@mail.gmail.com> <1256878441.16193.20.camel@jgd-dsk> <4AEAEA4D.1020609@redhat.com> <6835906b0910301426y632ed652x7172d65515bbf93a@mail.gmail.com> <4AEB5DD5.9000105@redhat.com> <6835906b0910301515x7f7801c8wf7e919b942a2643d@mail.gmail.com> <6835906b0910301516g781c2325q487bddefcfa1723d@mail.gmail.com> <1257011440.3553.1.camel@willson.li.ssimo.org> <6835906b0911011926j231f1722w4f52b85ce3a095ec@mail.gmail.com> Message-ID: <1257165232.3553.11.camel@willson.li.ssimo.org> On Sun, 2009-11-01 at 22:26 -0500, Dan Scott wrote: > On Sat, Oct 31, 2009 at 12:50, Simo Sorce wrote: > > On Fri, 2009-10-30 at 18:16 -0400, Dan Scott wrote: > >> OK, that makes sense, thanks. But there's still one thing I don't > >> really understand. How do the ipa tools obtain a ticket for the RPC > >> when the password has expired? > > > > They don't, password change is done via kpasswd (or direct connection to > > ldap and ldappasswd operation). > > So kpasswd can alter the LDAP directory without a ticket? kpasswd can take a ticket for kadmin/changepw at REALM > Let me check to see if I've got this straight. There are no IPA > specific tools for changing an expired password? Admin can always reset other users passwords, but they will be expired. > It can be done using > kpasswd (Which I really don't understand) or with a simple ldap bind > where the expired password is used for binding? Further, there is no > python library for changing the expired password? Is the above > correct? Correct. > The only way that I can see at the moment is to 'manually' alter the > LDAP directory. i.e. Hash the password myself and insert it into the > database. Could someone point me in the right direction for the cn and > hashing algorithm I need to use? No prehashed password are refused, we need the clear text password to be able to create the kerberos keys. The best way is to use the ldappasswd extended operation, although probably writing the clear text password to userPassword should also work. Simo. -- Simo Sorce * Red Hat, Inc * New York From danieljamesscott at gmail.com Mon Nov 2 03:26:36 2009 From: danieljamesscott at gmail.com (Dan Scott) Date: Sun, 1 Nov 2009 22:26:36 -0500 Subject: Fwd: [Freeipa-users] Library to change expired password In-Reply-To: <1257011440.3553.1.camel@willson.li.ssimo.org> References: <6835906b0910291456h455cea3axae38727060ce9532@mail.gmail.com> <1256878441.16193.20.camel@jgd-dsk> <4AEAEA4D.1020609@redhat.com> <6835906b0910301426y632ed652x7172d65515bbf93a@mail.gmail.com> <4AEB5DD5.9000105@redhat.com> <6835906b0910301515x7f7801c8wf7e919b942a2643d@mail.gmail.com> <6835906b0910301516g781c2325q487bddefcfa1723d@mail.gmail.com> <1257011440.3553.1.camel@willson.li.ssimo.org> Message-ID: <6835906b0911011926j231f1722w4f52b85ce3a095ec@mail.gmail.com> On Sat, Oct 31, 2009 at 12:50, Simo Sorce wrote: > On Fri, 2009-10-30 at 18:16 -0400, Dan Scott wrote: >> OK, that makes sense, thanks. But there's still one thing I don't >> really understand. How do the ipa tools obtain a ticket for the RPC >> when the password has expired? > > They don't, password change is done via kpasswd (or direct connection to > ldap and ldappasswd operation). So kpasswd can alter the LDAP directory without a ticket? Let me check to see if I've got this straight. There are no IPA specific tools for changing an expired password? It can be done using kpasswd (Which I really don't understand) or with a simple ldap bind where the expired password is used for binding? Further, there is no python library for changing the expired password? Is the above correct? The only way that I can see at the moment is to 'manually' alter the LDAP directory. i.e. Hash the password myself and insert it into the database. Could someone point me in the right direction for the cn and hashing algorithm I need to use? Thanks again for all the replies, Dan From rmeggins at redhat.com Mon Nov 2 21:32:15 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 02 Nov 2009 14:32:15 -0700 Subject: Fwd: [Freeipa-users] Library to change expired password In-Reply-To: <6835906b0911011926j231f1722w4f52b85ce3a095ec@mail.gmail.com> References: <6835906b0910291456h455cea3axae38727060ce9532@mail.gmail.com> <1256878441.16193.20.camel@jgd-dsk> <4AEAEA4D.1020609@redhat.com> <6835906b0910301426y632ed652x7172d65515bbf93a@mail.gmail.com> <4AEB5DD5.9000105@redhat.com> <6835906b0910301515x7f7801c8wf7e919b942a2643d@mail.gmail.com> <6835906b0910301516g781c2325q487bddefcfa1723d@mail.gmail.com> <1257011440.3553.1.camel@willson.li.ssimo.org> <6835906b0911011926j231f1722w4f52b85ce3a095ec@mail.gmail.com> Message-ID: <4AEF4FDF.9070401@redhat.com> Dan Scott wrote: > On Sat, Oct 31, 2009 at 12:50, Simo Sorce wrote: > >> On Fri, 2009-10-30 at 18:16 -0400, Dan Scott wrote: >> >>> OK, that makes sense, thanks. But there's still one thing I don't >>> really understand. How do the ipa tools obtain a ticket for the RPC >>> when the password has expired? >>> >> They don't, password change is done via kpasswd (or direct connection to >> ldap and ldappasswd operation). >> > > So kpasswd can alter the LDAP directory without a ticket? > > Let me check to see if I've got this straight. There are no IPA > specific tools for changing an expired password? It can be done using > kpasswd (Which I really don't understand) or with a simple ldap bind > where the expired password is used for binding? Further, there is no > python library for changing the expired password? Is the above > correct? > > The only way that I can see at the moment is to 'manually' alter the > LDAP directory. i.e. Hash the password myself and insert it into the > database. Could someone point me in the right direction for the cn and > hashing algorithm I need to use? > No, you should not change a password using a pre-hashed value. You should always send a clear text password - otherwise, IPA has no way to generate the different hashes/keys it needs. > Thanks again for all the replies, > > Dan > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From theiosx at gmail.com Tue Nov 3 05:09:31 2009 From: theiosx at gmail.com (Jesster Leight) Date: Tue, 3 Nov 2009 11:09:31 +0600 Subject: [Freeipa-users] tcl_cacert Utility Message-ID: Hello, i haven't tcl_cacert utility. Wich rpm-packet contain that ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From theiosx at gmail.com Tue Nov 3 06:18:34 2009 From: theiosx at gmail.com (Jesster Leight) Date: Tue, 3 Nov 2009 12:18:34 +0600 Subject: [Freeipa-users] Administration URL in 389DS Message-ID: How i can find my default Administration URL for 389 DS ? I can't use 389-console from this problem ;( -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Nov 3 14:14:18 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 03 Nov 2009 09:14:18 -0500 Subject: [Freeipa-users] tcl_cacert Utility In-Reply-To: References: Message-ID: <4AF03ABA.7090208@redhat.com> Jesster Leight wrote: > Hello, i haven't tcl_cacert utility. > Wich rpm-packet contain that ? I'm not familiar with this utility. Where did you see a reference to it? 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 Tue Nov 3 14:16:01 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 03 Nov 2009 09:16:01 -0500 Subject: [Freeipa-users] Administration URL in 389DS In-Reply-To: References: Message-ID: <4AF03B21.2020104@redhat.com> Jesster Leight wrote: > How i can find my default Administration URL for 389 DS ? I can't use > 389-console from this problem ;( That is correct. IPA does not install or configure the admin server or console for 389 DS. This is on purpose because user/group management in the console is not necessarily compatible with IPA and can cause large headaches. It should be possible, if one is very careful, to manage IPA users via the console but we do not support it. Is there some capability you need that only the console provides? 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 tomasz.napierala at allegro.pl Tue Nov 3 21:35:05 2009 From: tomasz.napierala at allegro.pl (Tomasz 'Zen' Napierala) Date: Tue, 3 Nov 2009 22:35:05 +0100 Subject: [Freeipa-users] Administration URL in 389DS In-Reply-To: <4AF03B21.2020104@redhat.com> References: <4AF03B21.2020104@redhat.com> Message-ID: <1257284105.6389.2.camel@powerdrag> Dnia 2009-11-03, wto o godzinie 15:16 +0100, Rob Crittenden pisze: > Jesster Leight wrote: > > How i can find my default Administration URL for 389 DS ? I can't use > > 389-console from this problem ;( > > That is correct. IPA does not install or configure the admin server or > console for 389 DS. This is on purpose because user/group management in > the console is not necessarily compatible with IPA and can cause large > headaches. It should be possible, if one is very careful, to manage IPA > users via the console but we do not support it. > > Is there some capability you need that only the console provides? I'll take a chance to ask similar question here (sorry for hijacking thread ;) I need some system users (e.g for configuring LDAPbind for apache authentication), and I'd like them to be under say CN=sysaccounts,CN=etc Is there any way to do this simply? The thing is I don't want to be subject of IPA password policy. Regards, -- Tomasz Z. Napiera?a Systems Architecture Engineer, IT Infrastructure Department Allegro Team http://www.allegro.pl/ QXL Poland sp. z o.o. ul. Marceli?ska 90, 60-324 Pozna? NIP 779-21-25-257; S?d Rejonowy Pozna? - Nowe Miasto i Wilda w Poznaniu, Wydzia? VIII Gospodarczy KRS nr 0000104322 Kapita? zak?adowy: 1.046.000 z?. From danieljamesscott at gmail.com Tue Nov 3 21:31:37 2009 From: danieljamesscott at gmail.com (Dan Scott) Date: Tue, 3 Nov 2009 16:31:37 -0500 Subject: Fwd: [Freeipa-users] Library to change expired password In-Reply-To: <6835906b0911031310q20c58dftb2ef1623cbfb76cf@mail.gmail.com> References: <6835906b0910291456h455cea3axae38727060ce9532@mail.gmail.com> <4AEAEA4D.1020609@redhat.com> <6835906b0910301426y632ed652x7172d65515bbf93a@mail.gmail.com> <4AEB5DD5.9000105@redhat.com> <6835906b0910301515x7f7801c8wf7e919b942a2643d@mail.gmail.com> <6835906b0910301516g781c2325q487bddefcfa1723d@mail.gmail.com> <1257011440.3553.1.camel@willson.li.ssimo.org> <6835906b0911011926j231f1722w4f52b85ce3a095ec@mail.gmail.com> <1257165232.3553.11.camel@willson.li.ssimo.org> <6835906b0911031310q20c58dftb2ef1623cbfb76cf@mail.gmail.com> Message-ID: <6835906b0911031331k58bcd514ub5dbd5d4d3f5b5fd@mail.gmail.com> Sorry again, forgot to CC the mailing list. Dan On Tue, Nov 3, 2009 at 16:10, Dan Scott wrote: > Hi, > > On Mon, Nov 2, 2009 at 07:33, Simo Sorce wrote: >> On Sun, 2009-11-01 at 22:26 -0500, Dan Scott wrote: >>> On Sat, Oct 31, 2009 at 12:50, Simo Sorce wrote: >>> > On Fri, 2009-10-30 at 18:16 -0400, Dan Scott wrote: >>> >> OK, that makes sense, thanks. But there's still one thing I don't >>> >> really understand. How do the ipa tools obtain a ticket for the RPC >>> >> when the password has expired? >>> > >>> > They don't, password change is done via kpasswd (or direct connection to >>> > ldap and ldappasswd operation). >>> >>> So kpasswd can alter the LDAP directory without a ticket? >> >> kpasswd can take a ticket for kadmin/changepw at REALM > > So is that a 'special' ticket, which can be obtained with an expired > password? Which can then be used to change the user's password? > >>> Let me check to see if I've got this straight. There are no IPA >>> specific tools for changing an expired password? >> >> Admin can always reset other users passwords, but they will be expired. > > Well sure, :) but changing a users expired password for another > expired password doesn't really help. I meant more along the lines > that there are no IPA specific tools which allow a non-admin user to > change their own expired password. > >>> The only way that I can see at the moment is to 'manually' alter the >>> LDAP directory. i.e. Hash the password myself and insert it into the >>> database. Could someone point me in the right direction for the cn and >>> hashing algorithm I need to use? >> >> No prehashed password are refused, we need the clear text password to be >> able to create the kerberos keys. >> The best way is to use the ldappasswd extended operation, although >> probably writing the clear text password to userPassword should also >> work. > > OK, thanks. I've located a Java library which implements the correct > LDAP extended operations. I can change a non-expired password with no > problem, but I still can't change an expired password. I am using: > > http://www.unboundid.com/products/ldapsdk/ > > and I am attempting to bind to the LDAP directory using SimpleBindRequest > > http://www.unboundid.com/products/ldapsdk/docs/javadoc/com/unboundid/ldap/sdk/SimpleBindRequest.html > > This works fine for changing currently valid passwords, but I receive > "LDAPException :invalid credentials" when attempting to bind using an > expired password. Do I need to use a different bind type? There are > several available: ANONYMOUSBindRequest, CRAMMD5BindRequest, > DIGESTMD5BindRequest, EXTERNALBindRequest, GSSAPIBindRequest, > PLAINBindRequest, SASLBindRequest. I assume that anonymous won't work. > Maybe I need to request the kadmin/changepw ticket requested above > using Kerberos and use this to bind to LDAP? > > Is there any documentation related to all this? Anything would be > great but if there's anything related to the way it works in FreeIPA > that would be even better. I've been searching high and low and I'm > not really having much luck. > > Thanks, > > Dan > From dpal at redhat.com Wed Nov 4 00:42:45 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Nov 2009 19:42:45 -0500 Subject: [Freeipa-users] Administration URL in 389DS In-Reply-To: <1257284105.6389.2.camel@powerdrag> References: <4AF03B21.2020104@redhat.com> <1257284105.6389.2.camel@powerdrag> Message-ID: <4AF0CE05.7010908@redhat.com> Tomasz 'Zen' Napierala wrote: > Dnia 2009-11-03, wto o godzinie 15:16 +0100, Rob Crittenden pisze: > >> Jesster Leight wrote: >> >>> How i can find my default Administration URL for 389 DS ? I can't use >>> 389-console from this problem ;( >>> >> That is correct. IPA does not install or configure the admin server or >> console for 389 DS. This is on purpose because user/group management in >> the console is not necessarily compatible with IPA and can cause large >> headaches. It should be possible, if one is very careful, to manage IPA >> users via the console but we do not support it. >> >> Is there some capability you need that only the console provides? >> > > I'll take a chance to ask similar question here (sorry for hijacking > thread ;) > > I need some system users (e.g for configuring LDAPbind for apache > authentication), and I'd like them to be under say CN=sysaccounts,CN=etc > Is there any way to do this simply? > The thing is I don't want to be subject of IPA password policy. > > Regards, > We are planning to have different password policies per group in IPAv2. As far as I remember it made our Alpha release last week. Would you be interested to give it a try? In IPA all accounts are on the same level but they can be grouped in different ways and in v2 pwd policies can be applied on per group basis. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Nov 4 02:26:00 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 03 Nov 2009 21:26:00 -0500 Subject: [Freeipa-users] Administration URL in 389DS In-Reply-To: <4AF0CE05.7010908@redhat.com> References: <4AF03B21.2020104@redhat.com> <1257284105.6389.2.camel@powerdrag> <4AF0CE05.7010908@redhat.com> Message-ID: <4AF0E638.6090903@redhat.com> Dmitri Pal wrote: > Tomasz 'Zen' Napierala wrote: >> Dnia 2009-11-03, wto o godzinie 15:16 +0100, Rob Crittenden pisze: >> >>> Jesster Leight wrote: >>> >>>> How i can find my default Administration URL for 389 DS ? I can't use >>>> 389-console from this problem ;( >>>> >>> That is correct. IPA does not install or configure the admin server or >>> console for 389 DS. This is on purpose because user/group management in >>> the console is not necessarily compatible with IPA and can cause large >>> headaches. It should be possible, if one is very careful, to manage IPA >>> users via the console but we do not support it. >>> >>> Is there some capability you need that only the console provides? >>> >> I'll take a chance to ask similar question here (sorry for hijacking >> thread ;) >> >> I need some system users (e.g for configuring LDAPbind for apache >> authentication), and I'd like them to be under say CN=sysaccounts,CN=etc >> Is there any way to do this simply? >> The thing is I don't want to be subject of IPA password policy. >> >> Regards, >> > We are planning to have different password policies per group in IPAv2. > As far as I remember it made our Alpha release last week. > Would you be interested to give it a try? > In IPA all accounts are on the same level but they can be grouped in > different ways and in v2 pwd policies can be applied on per group basis. > And for v1 you'll need to use ldapmodify. It only appears scary at first, it isn't so bad once you understand the syntax. I think the most bare-bones non-Posix account would look something like: dn: uid=apacheldap,cn=sysaccounts,cn=etc,dc=example,d=com changetype: add objectclass: account objectclass: simplesecurityobject uid: apacheldap userPassword: superSecret123 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 tomasz.napierala at allegro.pl Wed Nov 4 09:49:43 2009 From: tomasz.napierala at allegro.pl (Tomasz Z. Napierala) Date: Wed, 4 Nov 2009 09:49:43 +0000 Subject: [Freeipa-users] Administration URL in 389DS In-Reply-To: <4AF0CE05.7010908@redhat.com> References: <4AF03B21.2020104@redhat.com> <1257284105.6389.2.camel@powerdrag> <4AF0CE05.7010908@redhat.com> Message-ID: <1257328183.18189.20.camel@alledrag> Dnia 2009-11-04, ?ro o godzinie 01:42 +0100, Dmitri Pal pisze: > > I'll take a chance to ask similar question here (sorry for hijacking > > thread ;) > > > > I need some system users (e.g for configuring LDAPbind for apache > > authentication), and I'd like them to be under say CN=sysaccounts,CN=etc > > Is there any way to do this simply? > > The thing is I don't want to be subject of IPA password policy. > > > > Regards, > > > We are planning to have different password policies per group in IPAv2. > As far as I remember it made our Alpha release last week. > Would you be interested to give it a try? > In IPA all accounts are on the same level but they can be grouped in > different ways and in v2 pwd policies can be applied on per group basis. No problem, I'll install it today and try out. -- Tomasz Napiera?a Systems Architecture Engineer, IT Infrastructure Department Allegro Team http://www.allegro.pl/ QXL Poland sp. z o.o. ul. Marceli?ska 90, 60-324 Pozna? NIP 779-21-25-257; S?d Rejonowy Pozna? - Nowe Miasto i Wilda w Poznaniu, Wydzia? VIII Gospodarczy KRS nr 0000104322 Kapita? zak?adowy: 1.046.000 z?. From tomasz.napierala at allegro.pl Wed Nov 4 09:51:06 2009 From: tomasz.napierala at allegro.pl (Tomasz Z. Napierala) Date: Wed, 4 Nov 2009 10:51:06 +0100 Subject: [Freeipa-users] Administration URL in 389DS In-Reply-To: <4AF0E638.6090903@redhat.com> References: <4AF03B21.2020104@redhat.com> <1257284105.6389.2.camel@powerdrag> <4AF0CE05.7010908@redhat.com> <4AF0E638.6090903@redhat.com> Message-ID: <1257328266.18189.22.camel@alledrag> Dnia 2009-11-04, ?ro o godzinie 03:26 +0100, Rob Crittenden pisze: > > > > And for v1 you'll need to use ldapmodify. It only appears scary at > first, it isn't so bad once you understand the syntax. > > I think the most bare-bones non-Posix account would look something like: > > dn: uid=apacheldap,cn=sysaccounts,cn=etc,dc=example,d=com > changetype: add > objectclass: account > objectclass: simplesecurityobject > uid: apacheldap > userPassword: superSecret123 > Thanks, I'm not scared by middle level ldap commands ;) I was just wondering if there's any cli tool that can do "idiot proofing" ;) Regards, -- Tomasz Napiera?a Systems Architecture Engineer, IT Infrastructure Department Allegro Team http://www.allegro.pl/ QXL Poland sp. z o.o. ul. Marceli?ska 90, 60-324 Pozna? NIP 779-21-25-257; S?d Rejonowy Pozna? - Nowe Miasto i Wilda w Poznaniu, Wydzia? VIII Gospodarczy KRS nr 0000104322 Kapita? zak?adowy: 1.046.000 z?. From theiosx at gmail.com Wed Nov 4 11:42:32 2009 From: theiosx at gmail.com (Jesster Leight) Date: Wed, 4 Nov 2009 17:42:32 +0600 Subject: [Freeipa-users] Can't find ipa-user Message-ID: I installed FreeIPA with manual Implementing FreeIPA in a mixed Environment. My IPA OS: Fedora 11 Leonidas (Default without update. Clean OS, new installation) All steps compled sucessfully, except one: [root at ipa ~]# kinit admin Password for admin at EXAMPLE.COM: 12345678 [root at ipa ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at EXAMPLE.COM Valid starting Expires Service principal 11/04/09 17:36:08 11/05/09 17:36:05 krbtgt/EXAMPLE.COM at EXAMPLE.COM Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached And ... [root at ipa ~]# ipa-finduser admin _ssl.c:480: EOF occurred in violation of protocol Re-run with -v flag for more details. [root at ipa ~]# ipa-finduser -v admin Connecting to IPA server: https://ipa.example.com/ipa/xml _ssl.c:480: EOF occurred in violation of protocol Re-run with -v flag for more details. In what can be problem ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Wed Nov 4 13:44:12 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 04 Nov 2009 08:44:12 -0500 Subject: Fwd: [Freeipa-users] Library to change expired password In-Reply-To: <6835906b0911031331k58bcd514ub5dbd5d4d3f5b5fd@mail.gmail.com> References: <6835906b0910291456h455cea3axae38727060ce9532@mail.gmail.com> <4AEAEA4D.1020609@redhat.com> <6835906b0910301426y632ed652x7172d65515bbf93a@mail.gmail.com> <4AEB5DD5.9000105@redhat.com> <6835906b0910301515x7f7801c8wf7e919b942a2643d@mail.gmail.com> <6835906b0910301516g781c2325q487bddefcfa1723d@mail.gmail.com> <1257011440.3553.1.camel@willson.li.ssimo.org> <6835906b0911011926j231f1722w4f52b85ce3a095ec@mail.gmail.com> <1257165232.3553.11.camel@willson.li.ssimo.org> <6835906b0911031310q20c58dftb2ef1623cbfb76cf@mail.gmail.com> <6835906b0911031331k58bcd514ub5dbd5d4d3f5b5fd@mail.gmail.com> Message-ID: <1257342252.3553.62.camel@willson.li.ssimo.org> On Tue, 2009-11-03 at 16:31 -0500, Dan Scott wrote: > Sorry again, forgot to CC the mailing list. > > Dan > > On Tue, Nov 3, 2009 at 16:10, Dan Scott wrote: > > Hi, > > > > On Mon, Nov 2, 2009 at 07:33, Simo Sorce wrote: > >> On Sun, 2009-11-01 at 22:26 -0500, Dan Scott wrote: > >>> On Sat, Oct 31, 2009 at 12:50, Simo Sorce wrote: > >>> > On Fri, 2009-10-30 at 18:16 -0400, Dan Scott wrote: > >>> >> OK, that makes sense, thanks. But there's still one thing I don't > >>> >> really understand. How do the ipa tools obtain a ticket for the RPC > >>> >> when the password has expired? > >>> > > >>> > They don't, password change is done via kpasswd (or direct connection to > >>> > ldap and ldappasswd operation). > >>> > >>> So kpasswd can alter the LDAP directory without a ticket? > >> > >> kpasswd can take a ticket for kadmin/changepw at REALM > > > > So is that a 'special' ticket, which can be obtained with an expired > > password? Which can then be used to change the user's password? Pretty much. > >>> Let me check to see if I've got this straight. There are no IPA > >>> specific tools for changing an expired password? > >> > >> Admin can always reset other users passwords, but they will be expired. > > > > Well sure, :) but changing a users expired password for another > > expired password doesn't really help. I meant more along the lines > > that there are no IPA specific tools which allow a non-admin user to > > change their own expired password. Yes the tool is called "kpasswd" :) Or if you have properly configured (and it should if you use ipa-client-install) you should also be able to use the normal "passwd" command and perform the password change through the pam password stack. > >>> The only way that I can see at the moment is to 'manually' alter the > >>> LDAP directory. i.e. Hash the password myself and insert it into the > >>> database. Could someone point me in the right direction for the cn and > >>> hashing algorithm I need to use? > >> > >> No prehashed password are refused, we need the clear text password to be > >> able to create the kerberos keys. > >> The best way is to use the ldappasswd extended operation, although > >> probably writing the clear text password to userPassword should also > >> work. > > > > OK, thanks. I've located a Java library which implements the correct > > LDAP extended operations. I can change a non-expired password with no > > problem, but I still can't change an expired password. I am using: > > > > http://www.unboundid.com/products/ldapsdk/ > > > > and I am attempting to bind to the LDAP directory using SimpleBindRequest > > > > http://www.unboundid.com/products/ldapsdk/docs/javadoc/com/unboundid/ldap/sdk/SimpleBindRequest.html > > > > This works fine for changing currently valid passwords, but I receive > > "LDAPException :invalid credentials" when attempting to bind using an > > expired password. Do I need to use a different bind type? There are > > several available: ANONYMOUSBindRequest, CRAMMD5BindRequest, > > DIGESTMD5BindRequest, EXTERNALBindRequest, GSSAPIBindRequest, > > PLAINBindRequest, SASLBindRequest. I assume that anonymous won't work. > > Maybe I need to request the kadmin/changepw ticket requested above > > using Kerberos and use this to bind to LDAP? > > > > Is there any documentation related to all this? Anything would be > > great but if there's anything related to the way it works in FreeIPA > > that would be even better. I've been searching high and low and I'm > > not really having much luck. > > What have you used so far ? Simple auth ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Nov 4 14:02:15 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Nov 2009 09:02:15 -0500 Subject: [Freeipa-users] tcl_cacert Utility In-Reply-To: References: <4AF03ABA.7090208@redhat.com> Message-ID: <4AF18967.5040504@redhat.com> Jesster Leight wrote: > http://freeipa.org/docs/1.2/Client_Setup_Guide/en-US/html/sect-Client_Configuration_Guide-Configuring_Fedora_as_an_IPA_Client-Configuring_Client_TLS.html Ah, ok, that is a documentation bug. tls_cacert isn't a command, it is a directive you'd put into /etc/ldap.conf to point directly at a single CA. Normally you'd want to use tls_cacertdir but if you're having problems, one solution is to use tls_cacert to point to the IPA CA PEM file. rob > > 2009/11/3 Rob Crittenden > > > Jesster Leight wrote: > > Hello, i haven't tcl_cacert utility. > Wich rpm-packet contain that ? > > > I'm not familiar with this utility. Where did you see a reference to it? > > 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 jgalipea at redhat.com Wed Nov 4 14:04:19 2009 From: jgalipea at redhat.com (Jenny Galipeau) Date: Wed, 04 Nov 2009 09:04:19 -0500 Subject: [Freeipa-users] Can't find ipa-user In-Reply-To: References: Message-ID: <4AF189E3.3020905@redhat.com> Jesster Leight wrote: > I installed FreeIPA with manual Implementing FreeIPA in a mixed > Environment. > My IPA OS: Fedora 11 Leonidas (Default without update. Clean OS, new > installation) > All steps compled sucessfully, except one: > > [root at ipa ~]# kinit admin > Password for admin at EXAMPLE.COM : 12345678 > > [root at ipa ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at EXAMPLE.COM > Valid starting Expires Service principal > 11/04/09 17:36:08 11/05/09 17:36:05 krbtgt/EXAMPLE.COM > @EXAMPLE.COM > Kerberos 4 ticket cache: /tmp/tkt0 > klist: You have no tickets cached > > And ... > > [root at ipa ~]# ipa-finduser admin > _ssl.c:480: EOF occurred in violation of protocol > Re-run with -v flag for more details. > > [root at ipa ~]# ipa-finduser -v admin > Connecting to IPA server: https://ipa.example.com/ipa/xml > _ssl.c:480: EOF occurred in violation of protocol > Re-run with -v flag for more details. > > In what can be problem ? The ipa commands have changed. "ipa user-find admin" is the new command. Run ipa help for more information. ~Jenny > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Jenny Galipeau Principal Software QA Engineer Red Hat, Inc. Security Engineering Register now for Red Hat Virtual Experience, December 9. Enterprise Linux, virtualization, cloud, and more. http://www.redhat.com/virtualexperience Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ From rcritten at redhat.com Wed Nov 4 14:05:20 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Nov 2009 09:05:20 -0500 Subject: [Freeipa-users] Can't find ipa-user In-Reply-To: References: Message-ID: <4AF18A20.2010603@redhat.com> Jesster Leight wrote: > I installed FreeIPA with manual Implementing FreeIPA in a mixed Environment. > My IPA OS: Fedora 11 Leonidas (Default without update. Clean OS, new > installation) > All steps compled sucessfully, except one: > > [root at ipa ~]# kinit admin > Password for admin at EXAMPLE.COM : 12345678 > > [root at ipa ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at EXAMPLE.COM > Valid starting Expires Service principal > 11/04/09 17:36:08 11/05/09 17:36:05 krbtgt/EXAMPLE.COM > @EXAMPLE.COM > Kerberos 4 ticket cache: /tmp/tkt0 > klist: You have no tickets cached > > And ... > > [root at ipa ~]# ipa-finduser admin > _ssl.c:480: EOF occurred in violation of protocol > Re-run with -v flag for more details. > > [root at ipa ~]# ipa-finduser -v admin > Connecting to IPA server: https://ipa.example.com/ipa/xml > _ssl.c:480: EOF occurred in violation of protocol > Re-run with -v flag for more details. > > In what can be problem ? What version of IPA do you have? (rpm -q ipa-client) The admin tools communicate with the IPA server over SSL. I'm not sure if this is an SSL trust problem or not. Can you /var/log/httpd/error_log when you do this request to see what is logged? 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 Wed Nov 4 14:06:45 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Nov 2009 09:06:45 -0500 Subject: [Freeipa-users] Can't find ipa-user In-Reply-To: <4AF189E3.3020905@redhat.com> References: <4AF189E3.3020905@redhat.com> Message-ID: <4AF18A75.5000007@redhat.com> Jenny Galipeau wrote: > Jesster Leight wrote: >> I installed FreeIPA with manual Implementing FreeIPA in a mixed >> Environment. >> My IPA OS: Fedora 11 Leonidas (Default without update. Clean OS, new >> installation) >> All steps compled sucessfully, except one: >> >> [root at ipa ~]# kinit admin >> Password for admin at EXAMPLE.COM : 12345678 >> >> [root at ipa ~]# klist >> Ticket cache: FILE:/tmp/krb5cc_0 >> Default principal: admin at EXAMPLE.COM >> Valid starting Expires Service principal >> 11/04/09 17:36:08 11/05/09 17:36:05 krbtgt/EXAMPLE.COM >> @EXAMPLE.COM >> Kerberos 4 ticket cache: /tmp/tkt0 >> klist: You have no tickets cached >> >> And ... >> >> [root at ipa ~]# ipa-finduser admin >> _ssl.c:480: EOF occurred in violation of protocol >> Re-run with -v flag for more details. >> >> [root at ipa ~]# ipa-finduser -v admin >> Connecting to IPA server: https://ipa.example.com/ipa/xml >> _ssl.c:480: EOF occurred in violation of protocol >> Re-run with -v flag for more details. >> >> In what can be problem ? > The ipa commands have changed. "ipa user-find admin" is the new command. > Run ipa help for more information. What Jenny means is that the CLI tools in v2 uses a different naming convention from v1. Since the ipa-finduser command exists at all it tells me he is running v1 so this is a non-issue. 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 jgalipea at redhat.com Wed Nov 4 14:09:10 2009 From: jgalipea at redhat.com (Jenny Galipeau) Date: Wed, 04 Nov 2009 09:09:10 -0500 Subject: [Freeipa-users] Can't find ipa-user In-Reply-To: <4AF18A75.5000007@redhat.com> References: <4AF189E3.3020905@redhat.com> <4AF18A75.5000007@redhat.com> Message-ID: <4AF18B06.2070808@redhat.com> Rob Crittenden wrote: > Jenny Galipeau wrote: >> Jesster Leight wrote: >>> I installed FreeIPA with manual Implementing FreeIPA in a mixed >>> Environment. >>> My IPA OS: Fedora 11 Leonidas (Default without update. Clean OS, new >>> installation) >>> All steps compled sucessfully, except one: >>> >>> [root at ipa ~]# kinit admin >>> Password for admin at EXAMPLE.COM : 12345678 >>> >>> [root at ipa ~]# klist >>> Ticket cache: FILE:/tmp/krb5cc_0 >>> Default principal: admin at EXAMPLE.COM >>> Valid starting Expires Service principal >>> 11/04/09 17:36:08 11/05/09 17:36:05 krbtgt/EXAMPLE.COM >>> @EXAMPLE.COM >>> Kerberos 4 ticket cache: /tmp/tkt0 >>> klist: You have no tickets cached >>> >>> And ... >>> >>> [root at ipa ~]# ipa-finduser admin >>> _ssl.c:480: EOF occurred in violation of protocol >>> Re-run with -v flag for more details. >>> >>> [root at ipa ~]# ipa-finduser -v admin >>> Connecting to IPA server: https://ipa.example.com/ipa/xml >>> _ssl.c:480: EOF occurred in violation of protocol >>> Re-run with -v flag for more details. >>> >>> In what can be problem ? >> The ipa commands have changed. "ipa user-find admin" is the new >> command. >> Run ipa help for more information. > > What Jenny means is that the CLI tools in v2 uses a different naming > convention from v1. Since the ipa-finduser command exists at all it > tells me he is running v1 so this is a non-issue. Oh, thanks Rob! > > rob -- Jenny Galipeau Principal Software QA Engineer Red Hat, Inc. Security Engineering Register now for Red Hat Virtual Experience, December 9. Enterprise Linux, virtualization, cloud, and more. http://www.redhat.com/virtualexperience Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ From james.roman at ssaihq.com Wed Nov 4 14:40:47 2009 From: james.roman at ssaihq.com (James Roman) Date: Wed, 04 Nov 2009 09:40:47 -0500 Subject: [Freeipa-users] Rekeying Third-party signed certificate Message-ID: <4AF1926F.6070403@ssaihq.com> An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Nov 4 15:14:53 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Nov 2009 10:14:53 -0500 Subject: [Freeipa-users] Rekeying Third-party signed certificate In-Reply-To: <4AF1926F.6070403@ssaihq.com> References: <4AF1926F.6070403@ssaihq.com> Message-ID: <4AF19A6D.7030202@redhat.com> James Roman wrote: > Can't believe that time is up already. The third-party signed > certificate that I deployed my freeipa server with is about to expire. > Our certificate signer has now set the minimum key length to 2048 bit, > which means I have to re-key our primary freeipa SSL certificate. Before > I install the new certificate, I was wondering what impact this will > have on the other directory servers in my topology? I have one Active > Directory domain controller performing AD sync. I have four domain > controllers running password sync. I have one other freeipa replication > server. As you point out, the chain is remaining the same, so I think you just need to replace this one expiring cert. > > *freeipa replica server* > I assume that since the replication server has its own third-party > signed SSL certificate installed, it will not be affected at all by > installing a new certificate, since the certificate trust chain of the > new freeipa master certificate will be the same as the old one (and the > same as the cert used by the replication server). Right, unless it is about to expire too! > *AD Sync Agreement* > I also do not expect any issues here, since the Certificate chain > remains the same and is already trusted by the AD domain controller. I agree. > *Passsync Domain Controllers* > I am less sure about this one. Again, the certificate chain will remain > the same, but I will probably need to replace the peer certificate in > the DC's cert database. I plan on just using certutil to remove and > import the new peer certificate. I don't think you need to do anything here. The passsync database just needs to trust the cert that DS is using. Since you are using the same CA I think you'll be fine. > Should I use ipa-server-certinstall to install the new certificate on > the freeipa master, or should I just use certutil to remove and replace > the existing server cert (making sure to use the same certificate > friendly name)? Either should work. ipa-server-certinstall assumes (perhaps poorly) that the PKCS#12 file you provide includes the CA chain as well, so be sure that is included. If you are comfortable with certutil that is certainly an option. Where are you going to generate the CSR for this new cert? 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 davido at redhat.com Thu Nov 5 00:46:15 2009 From: davido at redhat.com (David O'Brien) Date: Thu, 05 Nov 2009 10:46:15 +1000 Subject: [Freeipa-users] tcl_cacert Utility In-Reply-To: <4AF18967.5040504@redhat.com> References: <4AF03ABA.7090208@redhat.com> <4AF18967.5040504@redhat.com> Message-ID: <4AF22057.4060308@redhat.com> Rob Crittenden wrote: > Jesster Leight wrote: >> http://freeipa.org/docs/1.2/Client_Setup_Guide/en-US/html/sect-Client_Configuration_Guide-Configuring_Fedora_as_an_IPA_Client-Configuring_Client_TLS.html >> > > Ah, ok, that is a documentation bug. > > tls_cacert isn't a command, it is a directive you'd put into > /etc/ldap.conf to point directly at a single CA. > > Normally you'd want to use tls_cacertdir but if you're having problems, > one solution is to use tls_cacert to point to the IPA CA PEM file. > Just to clarify, if tls_cacertdir /etc/cacerts/ in /etc/ldap.conf fails, then use tls_cacert /etc/cacerts/cacert.crt This is an alternative directive to put in ldap.conf, not a CLI tool. "# tls_cacert /etc/cacerts/cacert.crt" is the part in error thanks /David > rob > >> >> 2009/11/3 Rob Crittenden > > >> >> Jesster Leight wrote: >> >> Hello, i haven't tcl_cacert utility. >> Wich rpm-packet contain that ? >> >> >> I'm not familiar with this utility. Where did you see a reference >> to it? >> >> rob >> >> > -- David O'Brien Red Hat Asia Pacific +61 7 3514 8189 http://freeipa.org/page/DocumentationPortal http://git.fedorahosted.org/git/ipadocs.git "The most valuable of all talents is that of never using two words when one will do." Thomas Jefferson From theiosx at gmail.com Thu Nov 5 10:56:39 2009 From: theiosx at gmail.com (Jesster Leight) Date: Thu, 5 Nov 2009 16:56:39 +0600 Subject: [Freeipa-users] Re: Can't find ipa-user In-Reply-To: References: Message-ID: Ok i solve this problem. I configured config file /etc/http/conf.d/ipa.conf as writing in manuals. After reboot httpd service I see admin user and WEB. But I have one problem! Web interface is not work! IN Firefox i see Browser Kerberos Setup and i complete all steps sucessfully, but nothing results =\ I refreshing browser and same error. In Internet Explorer on WindowsXP i enter login and password admin:12345678 (as kinit admin) and see only blank screen, but in address bar i can see https://ipa.example.com/ipa/ui. In what can be problem ? 2009/11/4 Jesster Leight > I installed FreeIPA with manual Implementing FreeIPA in a mixed > Environment. > My IPA OS: Fedora 11 Leonidas (Default without update. Clean OS, new > installation) > All steps compled sucessfully, except one: > > [root at ipa ~]# kinit admin > Password for admin at EXAMPLE.COM: 12345678 > > [root at ipa ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at EXAMPLE.COM > Valid starting Expires Service principal > 11/04/09 17:36:08 11/05/09 17:36:05 krbtgt/EXAMPLE.COM at EXAMPLE.COM > Kerberos 4 ticket cache: /tmp/tkt0 > klist: You have no tickets cached > > And ... > > [root at ipa ~]# ipa-finduser admin > _ssl.c:480: EOF occurred in violation of protocol > Re-run with -v flag for more details. > > [root at ipa ~]# ipa-finduser -v admin > Connecting to IPA server: https://ipa.example.com/ipa/xml > _ssl.c:480: EOF occurred in violation of protocol > Re-run with -v flag for more details. > > In what can be problem ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Nov 5 14:31:31 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Nov 2009 09:31:31 -0500 Subject: [Freeipa-users] Re: Can't find ipa-user In-Reply-To: References: Message-ID: <4AF2E1C3.8070504@redhat.com> Jesster Leight wrote: > Ok i solve this problem. I configured config file > /etc/http/conf.d/ipa.conf as writing in manuals. > After reboot httpd service I see admin user and WEB. > But I have one problem! Web interface is not work! IN Firefox i see > Browser Kerberos Setup and i complete all steps sucessfully, but nothing > results =\ I refreshing browser and same error. I would recommend quitting the browser, running kdestroy, kinit, then relaunching the browser and trying again. > In Internet Explorer on WindowsXP i enter login and password > admin:12345678 (as kinit admin) and see only blank screen, but in > address bar i can see https://ipa.example.com/ipa/ui. > In what can be problem ? So you modified the Apache server to set KrbMethodK5Passwd on? You'll need to check the Apache and IPA UI logs for more details. /var/log/httpd/error_log and /var/log/ipa_error.log rob > > 2009/11/4 Jesster Leight > > > I installed FreeIPA with manual Implementing FreeIPA in a mixed > Environment. > My IPA OS: Fedora 11 Leonidas (Default without update. Clean OS, new > installation) > All steps compled sucessfully, except one: > > [root at ipa ~]# kinit admin > Password for admin at EXAMPLE.COM : 12345678 > > [root at ipa ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at EXAMPLE.COM > Valid starting Expires Service principal > 11/04/09 17:36:08 11/05/09 17:36:05 krbtgt/EXAMPLE.COM > @EXAMPLE.COM > Kerberos 4 ticket cache: /tmp/tkt0 > klist: You have no tickets cached > > And ... > > [root at ipa ~]# ipa-finduser admin > _ssl.c:480: EOF occurred in violation of protocol > Re-run with -v flag for more details. > > [root at ipa ~]# ipa-finduser -v admin > Connecting to IPA server: https://ipa.example.com/ipa/xml > _ssl.c:480: EOF occurred in violation of protocol > Re-run with -v flag for more details. > > In what can be problem ? > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From samh.work at gmail.com Thu Nov 5 20:38:43 2009 From: samh.work at gmail.com (Sam Hartsfield) Date: Thu, 5 Nov 2009 15:38:43 -0500 Subject: [Freeipa-users] Deploying FreeIPA 1.2.2 on RHEL 5 Message-ID: Hello, I am interested in deploying FreeIPA along with my company's software to allow us to implement Single Sign On. All of our software is deployed on Red Hat Enterprise Linux, so I would like to get the FreeIPA server to run there (on RHEL 5). I am aware of Red Hat IPA, but if I'm not mistaken, it is based on an earlier version that does not have the ability to sync to Active Directory. Most of the dependencies are available either from the official package repositories or from EPEL, and Fedora/389 Directory Server has its own repository for Enterpise Linux. However, there are two packages that are unavailable: 'mod_nss >= 1.0.7-2' and 'slapi-nis'. Looking at the commit (f018c2123c2b0018af5d41ec007ac8ddf0f04d31), it appears that an earlier version of mod_nss is okay as long as we don't need to pass it through mod_proxy. As far as I can tell, slapi-nis is used for providing an NIS interface, which I don't think we need (RHEL4 and RHEL5 clients should be able to use LDAP for user information). Does this sound accurate, or is there anything I'm missing? Would it be sufficient to remove these dependencies from the RPM spec (for mod_nss just remove the version restriction) before I build the package, or would I need to make other modifications? After trying it (installing with 'rpm --nodeps'), it appears to work at first glance. Are there any other issues with running on RHEL 5 that I should be aware of? Any comments on this configuration? Thank you, Sam Hartsfield From loris at lgs.com.ve Thu Nov 5 21:14:25 2009 From: loris at lgs.com.ve (Loris Santamaria) Date: Thu, 05 Nov 2009 16:44:25 -0430 Subject: [Freeipa-users] Deploying FreeIPA 1.2.2 on RHEL 5 In-Reply-To: References: Message-ID: <1257455665.10514.98.camel@arepa.pzo.lgs.com.ve> El jue, 05-11-2009 a las 15:38 -0500, Sam Hartsfield escribi?: > Hello, > > I am interested in deploying FreeIPA along with my company's software > to allow us to implement Single Sign On. All of our software is > deployed on Red Hat Enterprise Linux, so I would like to get the > FreeIPA server to run there (on RHEL 5). I am aware of Red Hat IPA, > but if I'm not mistaken, it is based on an earlier version that does > not have the ability to sync to Active Directory. > > Most of the dependencies are available either from the official > package repositories or from EPEL, and Fedora/389 Directory Server has > its own repository for Enterpise Linux. However, there are two > packages that are unavailable: 'mod_nss >= 1.0.7-2' and 'slapi-nis'. One could just use the relevant .src.rpm from Fedora and recompile them on RHEL. At least I did that with no problems (*) whatsoever several times with the .src.rpms from Fedora 9 an 10 You can't use directly rpms from Fedora 11 because the formath has changed slightly, but you can install the .src.rpm in Fedora, and copy the contents (spec, sources and patches) to RHEL to rebuild it. (*) You should edit the ipa.spec and change BuildRequires: popt-devel to BuildRequires: popt > Looking at the commit (f018c2123c2b0018af5d41ec007ac8ddf0f04d31), it > appears that an earlier version of mod_nss is okay as long as we don't > need to pass it through mod_proxy. As far as I can tell, slapi-nis is > used for providing an NIS interface, which I don't think we need > (RHEL4 and RHEL5 clients should be able to use LDAP for user > information). Does this sound accurate, or is there anything I'm > missing? Would it be sufficient to remove these dependencies from the > RPM spec (for mod_nss just remove the version restriction) before I > build the package, or would I need to make other modifications? After > trying it (installing with 'rpm --nodeps'), it appears to work at > first glance. > > Are there any other issues with running on RHEL 5 that I should be > aware of? Any comments on this configuration? > > Thank you, > Sam Hartsfield > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ -O9 -omg-optimize -fomit-instructions -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3149 bytes Desc: not available URL: From theiosx at gmail.com Fri Nov 6 06:34:00 2009 From: theiosx at gmail.com (Jesster Leight) Date: Fri, 6 Nov 2009 12:34:00 +0600 Subject: [Freeipa-users] Remove ipa-client configuration Message-ID: How i can remove ipa-client configuration ? I have client station on Fedora 11. $ ipa-client-install Failed to verify that freeipa.example.com is an IPA Server. This may mean that the remote server is not up or is not reachable due to network or firewall settings. $ rm -f /var/kerberos/krb5kdc/kpasswd.keytab $ ipa-client-install --uninstall Restoring client configuration files Disabling client Kerberos and Ldap configurations The original nsswitch.conf configuration has been restored. You may need to restart services or reboot the machine. Do you want to reboot the machine? [no]: yes Broadcast message from jess at satellite.example.com (/dev/pts/0) at 12:31 ... The system is going down for reboot NOW! After reboot same problem. Not working ipa-client-install. In what can be problem ? Maybe i forget some to remove ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Fri Nov 6 14:03:37 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 06 Nov 2009 09:03:37 -0500 Subject: [Freeipa-users] Remove ipa-client configuration In-Reply-To: References: Message-ID: <1257516217.3553.132.camel@willson.li.ssimo.org> On Fri, 2009-11-06 at 12:34 +0600, Jesster Leight wrote: > > $ rm -f /var/kerberos/krb5kdc/kpasswd.keytab Can you explain this ? If you do this on your ipa server you are doing very bad things ... Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Nov 6 14:24:59 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Nov 2009 09:24:59 -0500 Subject: [Freeipa-users] Remove ipa-client configuration In-Reply-To: References: Message-ID: <4AF431BB.3070701@redhat.com> Jesster Leight wrote: > How i can remove ipa-client configuration ? > I have client station on Fedora 11. > > $ ipa-client-install > Failed to verify that freeipa.example.com > is an IPA Server. > This may mean that the remote server is not up or is not reachable > due to network or firewall settings. > > $ rm -f /var/kerberos/krb5kdc/kpasswd.keytab > $ ipa-client-install --uninstall > Restoring client configuration files > Disabling client Kerberos and Ldap configurations > The original nsswitch.conf configuration has been restored. > You may need to restart services or reboot the machine. > Do you want to reboot the machine? [no]: yes > > Broadcast message from jess at satellite.example.com > > (/dev/pts/0) at 12:31 ... > > The system is going down for reboot NOW! > > After reboot same problem. Not working ipa-client-install. > In what can be problem ? Maybe i forget some to remove ? Do you have an AD domain using the same realm name you are using for IPA? IPA uses DNS discovery to find the LDAP and kerberos server to use. It connects to the LDAP server it gets and verifies that it is an IPA LDAP server. Perhaps it is finding the wrong one? 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 sgallagh at redhat.com Fri Nov 6 21:11:40 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 06 Nov 2009 16:11:40 -0500 Subject: [Freeipa-users] Deploying FreeIPA 1.2.2 on RHEL 5 In-Reply-To: <1257455665.10514.98.camel@arepa.pzo.lgs.com.ve> References: <1257455665.10514.98.camel@arepa.pzo.lgs.com.ve> Message-ID: <4AF4910C.3080409@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/05/2009 04:14 PM, Loris Santamaria wrote: > El jue, 05-11-2009 a las 15:38 -0500, Sam Hartsfield escribi?: >> Hello, >> >> I am interested in deploying FreeIPA along with my company's software >> to allow us to implement Single Sign On. All of our software is >> deployed on Red Hat Enterprise Linux, so I would like to get the >> FreeIPA server to run there (on RHEL 5). I am aware of Red Hat IPA, >> but if I'm not mistaken, it is based on an earlier version that does >> not have the ability to sync to Active Directory. >> >> Most of the dependencies are available either from the official >> package repositories or from EPEL, and Fedora/389 Directory Server has >> its own repository for Enterpise Linux. However, there are two >> packages that are unavailable: 'mod_nss >= 1.0.7-2' and 'slapi-nis'. > > One could just use the relevant .src.rpm from Fedora and recompile them > on RHEL. At least I did that with no problems (*) whatsoever several > times with the .src.rpms from Fedora 9 an 10 > > You can't use directly rpms from Fedora 11 because the formath has > changed slightly, but you can install the .src.rpm in Fedora, and copy > the contents (spec, sources and patches) to RHEL to rebuild it. > How to make a RHEL SRPM in Fedora in a few easy steps. (All of the below commands must be run on Fedora) Prerequisites: 1. yum install cpio rpm-build 2. rpmdev-setuptree This will create a directory structure inside ~/rpmbuild Create the SRPM: 1. yumdownloader --source ipa This will download ipa-1.2.2-1.fc11.src.rpm to the current directory. 2. rpm2cpio ipa-1.2.2-1.fc11.src.rpm |cpio --extract This will extract the source tarball to the current directory. 3. cp freeipa-1.2.2.tar.gz ~/rpmbuild/SOURCES 4. Edit ipa.spec as described in a previous email to change 'popt-devel' to 'popt' 4. rpmbuild -bs --define _source_filedigest_algorithm=1 ipa.spec You now will have a source RPM in ~/rpmbuild/SRPMS. (Pay no mind that it still says .fc11 in the name, that's just because you're generating it on an FC11 system) that can be built on a RHEL system with the command rpmbuild --rebuild ipa-1.2.2-1.fc11.src.rpm * If you're curious, the reason behind these steps are twofold. 1) The name of the popt package changed between RHEL5 and F11, so you need to fix that in the spec. 2) The RPM format now uses a different digest algorithm in F11 and later that RHEL5 cannot read. So we force it to use the old digest algorithm in the rpmbuild step above. > (*) You should edit the ipa.spec and change > > BuildRequires: popt-devel > > to > > BuildRequires: popt > > >> Looking at the commit (f018c2123c2b0018af5d41ec007ac8ddf0f04d31), it >> appears that an earlier version of mod_nss is okay as long as we don't >> need to pass it through mod_proxy. As far as I can tell, slapi-nis is >> used for providing an NIS interface, which I don't think we need >> (RHEL4 and RHEL5 clients should be able to use LDAP for user >> information). Does this sound accurate, or is there anything I'm >> missing? Would it be sufficient to remove these dependencies from the >> RPM spec (for mod_nss just remove the version restriction) before I >> build the package, or would I need to make other modifications? After >> trying it (installing with 'rpm --nodeps'), it appears to work at >> first glance. >> >> Are there any other issues with running on RHEL 5 that I should be >> aware of? Any comments on this configuration? >> >> Thank you, >> Sam Hartsfield >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkr0kQcACgkQeiVVYja6o6PifgCfbjBXeN9uRMJ1DwCr8AnbNNGJ QD8An1yAu9rYUNtrwJi+/E0SIESt6Q06 =/S16 -----END PGP SIGNATURE----- From theiosx at gmail.com Mon Nov 9 04:15:48 2009 From: theiosx at gmail.com (Jesster Leight) Date: Mon, 9 Nov 2009 10:15:48 +0600 Subject: [Freeipa-users] Remove ipa-client configuration Message-ID: Hello. I had IPA server with another configuration. Then i reinstall my IPA server with new domain and new configuration. Now I whant configure my client-station to new IPA server. She configure now to old IPA server freeipa.example.com. I can reinstall OS on my client station and configure with clean list, but it is not exit. What config files i must remove or edit for remove old IPA-client configuration ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Nov 9 14:24:21 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Nov 2009 09:24:21 -0500 Subject: [Freeipa-users] Remove ipa-client configuration In-Reply-To: References: Message-ID: <4AF82615.40708@redhat.com> Jesster Leight wrote: > Hello. I had IPA server with another configuration. Then i reinstall my > IPA server with new domain and new configuration. Now I whant configure > my client-station to new IPA server. She configure now to old IPA server > freeipa.example.com . I can reinstall OS on > my client station and configure with clean list, but it is not exit. > What config files i must remove or edit for remove old IPA-client > configuration ? ipa-client-install --uninstall should do it. 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 stephen at sandifers.net Wed Nov 11 22:53:04 2009 From: stephen at sandifers.net (Stephen P. Sandifer) Date: Wed, 11 Nov 2009 16:53:04 -0600 Subject: [Freeipa-users] Question about the FreeIPA 2.x alpha Message-ID: <1257979984.1694.1.camel@localhost> Has anyone successfully built the alpha package from source? I thought I'd solved all the dependencies but it does not seem to build successfully. For those who did, would you mind letting me know what your Linux distribution is? Thank you, Stephen Sandifer From jhrozek at redhat.com Thu Nov 12 09:36:06 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 12 Nov 2009 10:36:06 +0100 Subject: [Freeipa-users] Question about the FreeIPA 2.x alpha In-Reply-To: <1257979984.1694.1.camel@localhost> References: <1257979984.1694.1.camel@localhost> Message-ID: <4AFBD706.6020401@redhat.com> On 11/11/2009 11:53 PM, Stephen P. Sandifer wrote: > Has anyone successfully built the alpha package from source? > > I thought I'd solved all the dependencies but it does not seem to build > successfully. For those who did, would you mind letting me know what > your Linux distribution is? > > Thank you, > Stephen Sandifer Stephen, what is the particular error you are seeing? I did rebuild the alpha release for demo purposes last week on Fedora 11. I think I had to manually rebuild and install the wehjit and assets packages (WebUI infrastructure packages) as they are not available for F11. Jakub From sbose at redhat.com Thu Nov 12 11:03:32 2009 From: sbose at redhat.com (Sumit Bose) Date: Thu, 12 Nov 2009 12:03:32 +0100 Subject: [Freeipa-users] Question about the FreeIPA 2.x alpha In-Reply-To: <4AFBD706.6020401@redhat.com> References: <1257979984.1694.1.camel@localhost> <4AFBD706.6020401@redhat.com> Message-ID: <20091112110332.GB2224@localhost.localdomain> On Thu, Nov 12, 2009 at 10:36:06AM +0100, Jakub Hrozek wrote: > On 11/11/2009 11:53 PM, Stephen P. Sandifer wrote: > > Has anyone successfully built the alpha package from source? > > > > I thought I'd solved all the dependencies but it does not seem to build > > successfully. For those who did, would you mind letting me know what > > your Linux distribution is? > > > > Thank you, > > Stephen Sandifer > > Stephen, > what is the particular error you are seeing? I did rebuild the alpha > release for demo purposes last week on Fedora 11. > > I think I had to manually rebuild and install the wehjit and assets > packages (WebUI infrastructure packages) as they are not available for F11. > > Jakub > The fc13 packages from koji: http://kojipkgs.fedoraproject.org/packages/python-assets/0.1.1/2.fc13/noarch/python-assets-0.1.1-2.fc13.noarch.rpm http://kojipkgs.fedoraproject.org/packages/python-wehjit/0.1.1/2.fc13/noarch/python-wehjit-0.1.1-2.fc13.noarch.rpm are working for me on F11, too. bye, Sumit From samh.work at gmail.com Thu Nov 12 19:44:26 2009 From: samh.work at gmail.com (Sam Hartsfield) Date: Thu, 12 Nov 2009 14:44:26 -0500 Subject: [Freeipa-users] IPA to AD sync, certificate verify failed Message-ID: I am using FreeIPA 1.2.2 and trying to synchronize with AD on Windows Server 2003. Are password changes in FreeIPA supposed to be synced to Active Directory? I couldn't find any reference to this specific in the documentation, but on my test setup passwords are not being changed in AD (using the ipa-passwd command; I also tried the Windows XP password change dialog). Password changes in AD /are/ properly reflected in FreeIPA. When I the run command to add the sync (I'm using Administrator just for testing purposes): ipa-replica-manage add --winsync --binddn CN=Administrator,CN=Users,DC=prism,DC=internal --bindpw password --cacert /home/samh/prism_ad.cer prism_ad.prism.internal -v --passsync password I get this: INFO:root:Added CA certificate /home/samh/prism_ad.cer to certificate database for ipaserver.prism.internal INFO:root:Restarted directory server ipaserver.prism.internal INFO:root:Could not validate connection to remote server prism_ad.prism.internal:636 - continuing INFO:root:The error was: {'info': 'error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', 'desc': "Can't contact LDAP server"} indicating a certificate problem, and there are similar connection errors in the dirsrv error log. However, I was able to connect with the ldapsearch command after adding a line for that same file to my ".ldaprc" ("TLS_CACERT /home/samh/prism_ad.cer"): ldapsearch -x -D CN=Administrator,CN=Users,DC=prism,DC=internal -w password -H ldaps://prism_ad.prism.internal -b "dc=prism,dc=internal" I exported the certificate using the directions http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html, and the file is readable by all users. This seems to be similar to Jeff Moody's problem earlier this year in the topic "IPA Windows Sync - Windows 2003 R2 SP2 and Fedora 10". I also created an "Enterprise root CA", but he didn't specify how he finally found the correct certificate, just that it wasn't easy! I've searched the computer, and the only ".crt" file is the one I used. In the "Certification Authority" tool, I see that there are two certificates in the chain, but if I export the other one, ipa-replica-manage says "could not add certificate to token or database: Error adding certificate to database." Does anyone have any idea what might be going wrong? Thank you, Sam Hartsfield From rmeggins at redhat.com Thu Nov 12 20:38:23 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 12 Nov 2009 13:38:23 -0700 Subject: [Freeipa-users] IPA to AD sync, certificate verify failed In-Reply-To: References: Message-ID: <4AFC723F.8000201@redhat.com> Sam Hartsfield wrote: > I am using FreeIPA 1.2.2 and trying to synchronize with AD on Windows > Server 2003. > > Are password changes in FreeIPA supposed to be synced to Active > Directory? Yes. > I couldn't find any reference to this specific in the > documentation, but on my test setup passwords are not being changed in > AD (using the ipa-passwd command; I also tried the Windows XP password > change dialog). Password changes in AD /are/ properly reflected in > FreeIPA. > You could try using the replication error log level to debug winsync problems - http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting > When I the run command to add the sync (I'm using Administrator just > for testing purposes): > > ipa-replica-manage add --winsync --binddn > CN=Administrator,CN=Users,DC=prism,DC=internal --bindpw password > --cacert /home/samh/prism_ad.cer prism_ad.prism.internal -v --passsync > password > > I get this: > > INFO:root:Added CA certificate /home/samh/prism_ad.cer to certificate > database for ipaserver.prism.internal > INFO:root:Restarted directory server ipaserver.prism.internal > INFO:root:Could not validate connection to remote server > prism_ad.prism.internal:636 - continuing > INFO:root:The error was: {'info': 'error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', > 'desc': "Can't contact LDAP server"} > > indicating a certificate problem, This just means the script could not open and verify the connection. This is due to a "bug" in python-ldap or openldap, in that if you have already specified a CA cert, it will not let you specify another one. This is usually ok and can be ignored. > and there are similar connection > errors in the dirsrv error log. That's not so good. That usually means the CA cert from AD was not properly installed in the directory server cert db. What errors do you see? > However, I was able to connect with > the ldapsearch command after adding a line for that same file to my > ".ldaprc" ("TLS_CACERT /home/samh/prism_ad.cer"): > > ldapsearch -x -D CN=Administrator,CN=Users,DC=prism,DC=internal -w > password -H ldaps://prism_ad.prism.internal -b "dc=prism,dc=internal" > Ok. Try this: certutil -d /etc/dirsrv/slapd-YOUR-INSTANCE-HERE -L you should see an entry for your MS CA - if you do, then try this /usr/lib/mozldap/ldapsearch -h adhostname -p 636 -Z -P /etc/dirsrv/slapd-YOUR-INSTANCE-HERE/cert8.db -D "CN=Administrator,CN=Users,DC=prism,DC=internal" -w password -s base -b "" > > I exported the certificate using the directions > http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html, > and the file is readable by all users. > > > This seems to be similar to Jeff Moody's problem earlier this year in > the topic "IPA Windows Sync - Windows 2003 R2 SP2 and Fedora 10". I > also created an "Enterprise root CA", but he didn't specify how he > finally found the correct certificate, just that it wasn't easy! I've > searched the computer, and the only ".crt" file is the one I used. In > the "Certification Authority" tool, I see that there are two > certificates in the chain, but if I export the other one, > ipa-replica-manage says "could not add certificate to token or > database: Error adding certificate to database." > > Does anyone have any idea what might be going wrong? > If you are able to successfully use openldap ldapsearch with that ca cert, then either it's not a problem with the CA cert, or you have no TLS/SSL checking whatsoever in your ldap configuration. > Thank you, > Sam Hartsfield > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From samh.work at gmail.com Sat Nov 14 00:33:22 2009 From: samh.work at gmail.com (Sam Hartsfield) Date: Fri, 13 Nov 2009 19:33:22 -0500 Subject: [Freeipa-users] IPA to AD sync, certificate verify failed In-Reply-To: <4AFC723F.8000201@redhat.com> References: <4AFC723F.8000201@redhat.com> Message-ID: On Thu, Nov 12, 2009 at 3:38 PM, Rich Megginson wrote: > Sam Hartsfield wrote: >> >> I am using FreeIPA 1.2.2 and trying to synchronize with AD on Windows >> Server 2003. >> >> Are password changes in FreeIPA supposed to be synced to Active >> Directory? > > Yes. >> >> I couldn't find any reference to this specific in the >> documentation, but on my test setup passwords are not being changed in >> AD (using the ipa-passwd command; I also tried the Windows XP password >> change dialog). Password changes in AD /are/ properly reflected in >> FreeIPA. >> > > You could try using the replication error log level to debug winsync > problems - http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting >> >> When I the run command to add the sync (I'm using Administrator just >> for testing purposes): >> >> ipa-replica-manage add --winsync --binddn >> CN=Administrator,CN=Users,DC=prism,DC=internal --bindpw password >> --cacert /home/samh/prism_ad.cer prism_ad.prism.internal -v --passsync >> password >> >> I get this: >> >> INFO:root:Added CA certificate /home/samh/prism_ad.cer to certificate >> database for ipaserver.prism.internal >> INFO:root:Restarted directory server ipaserver.prism.internal >> INFO:root:Could not validate connection to remote server >> prism_ad.prism.internal:636 - continuing >> INFO:root:The error was: {'info': 'error:14090086:SSL >> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', >> 'desc': "Can't contact LDAP server"} >> >> indicating a certificate problem, > > This just means the script could not open and verify the connection. ?This > is due to a "bug" in python-ldap or openldap, in that if you have already > specified a CA cert, it will not let you specify another one. ?This is > usually ok and can be ignored. Good to know. >> >> and there are similar connection >> errors in the dirsrv error log. > > That's not so good. ?That usually means the CA cert from AD was not properly > installed in the directory server cert db. > > What errors do you see? Hmm... I did see some errors, but not really anymore. I was seeing this, but maybe it was just when I was rebooting the AD server or something: [09/Nov/2009:12:30:46 -0500] slapi_ldap_bind - Error: could not send bind request for id [CN=Administrator,CN=Users,DC=prism,DC=internal] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) I also see a few of these: [13/Nov/2009:14:50:53 -0500] NSMMReplicationPlugin - failed to send dirsync search request: 2 Okay, I looked at the FAQ you linked above and changed the log level to 8192. Here's one of the messages I see after using ipa-passwd: [13/Nov/2009:19:05:34 -0500] NSMMReplicationPlugin - agmt="cn=meToprism_ad.prism.internal636" (prism_ad:636): AD already has the current password for CN=Sam Hartsfield,CN=Users,DC=prism,DC=internal. Not sending password modify to AD. I'm attaching a longer portion of the log. As far as I can tell, the password has not been changed on the AD side, only in IPA (using a Windows XP client attached to the domain, the new password does not allow me to log in). >> >> However, I was able to connect with >> the ldapsearch command after adding a line for that same file to my >> ".ldaprc" ("TLS_CACERT /home/samh/prism_ad.cer"): >> > >> ldapsearch -x -D CN=Administrator,CN=Users,DC=prism,DC=internal -w >> password -H ldaps://prism_ad.prism.internal -b "dc=prism,dc=internal" >> > > Ok. ?Try this: > certutil -d /etc/dirsrv/slapd-YOUR-INSTANCE-HERE -L > you should see an entry for your MS CA - if you do, then try this > /usr/lib/mozldap/ldapsearch -h adhostname -p 636 -Z -P > /etc/dirsrv/slapd-YOUR-INSTANCE-HERE/cert8.db -D > "CN=Administrator,CN=Users,DC=prism,DC=internal" -w password -s base -b "" I'm guessing "Imported CA" might be the AD certificate: > [root at ipaserver samh]# certutil -d /etc/dirsrv/slapd-PRISM-INTERNAL/ -L > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > CA certificate CTu,u,Cu > Imported CA CT,,C > Server-Cert u,u,u I was wondering where that version of ldapsearch was. I ran this, and got the expected output (all my attributes): /usr/lib/mozldap/ldapsearch -h prism_ad.prism.internal -p 636 -Z -P /etc/dirsrv/slapd-PRISM-INTERNAL/cert8.db -D "CN=Administrator,CN=Users,DC=prism,DC=internal" -w password -s base -b "" sAMAccountname=samh As expected, it did not run without the -P option ("SSL initialization failed: error -8174 (security library: bad database.)"). >> >> ?I exported the certificate using the directions >> >> http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html, >> and the file is readable by all users. >> >> >> This seems to be similar to Jeff Moody's problem earlier this year in >> the topic "IPA Windows Sync - Windows 2003 R2 SP2 and Fedora 10". I >> also created an "Enterprise root CA", but he didn't specify how he >> finally found the correct certificate, just that it wasn't easy! I've >> searched the computer, and the only ".crt" file is the one I used. In >> the "Certification Authority" tool, I see that there are two >> certificates in the chain, but if I export the other one, >> ipa-replica-manage says "could not add certificate to token or >> database: Error adding certificate to database." >> >> Does anyone have any idea what might be going wrong? >> > > If you are able to successfully use openldap ldapsearch with that ca cert, > then either it's not a problem with the CA cert, or you have no TLS/SSL > checking whatsoever in your ldap configuration. It certainly seems to be checking; it failed to work over SSL until I added that TLS_CACERT line. Thanks for your comments and suggestions, Rich. I'll continue working on this next week, and also try to set up a new sync agreement from scratch with two new machines. -- Sam Hartsfield -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-replication-excerpt.log Type: text/x-log Size: 7768 bytes Desc: not available URL: From rmeggins at redhat.com Mon Nov 16 15:16:39 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Nov 2009 08:16:39 -0700 Subject: [Freeipa-users] IPA to AD sync, certificate verify failed In-Reply-To: References: <4AFC723F.8000201@redhat.com> Message-ID: <4B016CD7.6000206@redhat.com> Sam Hartsfield wrote: > On Thu, Nov 12, 2009 at 3:38 PM, Rich Megginson wrote: > >> Sam Hartsfield wrote: >> >>> I am using FreeIPA 1.2.2 and trying to synchronize with AD on Windows >>> Server 2003. >>> >>> Are password changes in FreeIPA supposed to be synced to Active >>> Directory? >>> >> Yes. >> >>> I couldn't find any reference to this specific in the >>> documentation, but on my test setup passwords are not being changed in >>> AD (using the ipa-passwd command; I also tried the Windows XP password >>> change dialog). Password changes in AD /are/ properly reflected in >>> FreeIPA. >>> >>> >> You could try using the replication error log level to debug winsync >> problems - http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting >> >>> When I the run command to add the sync (I'm using Administrator just >>> for testing purposes): >>> >>> ipa-replica-manage add --winsync --binddn >>> CN=Administrator,CN=Users,DC=prism,DC=internal --bindpw password >>> --cacert /home/samh/prism_ad.cer prism_ad.prism.internal -v --passsync >>> password >>> >>> I get this: >>> >>> INFO:root:Added CA certificate /home/samh/prism_ad.cer to certificate >>> database for ipaserver.prism.internal >>> INFO:root:Restarted directory server ipaserver.prism.internal >>> INFO:root:Could not validate connection to remote server >>> prism_ad.prism.internal:636 - continuing >>> INFO:root:The error was: {'info': 'error:14090086:SSL >>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', >>> 'desc': "Can't contact LDAP server"} >>> >>> indicating a certificate problem, >>> >> This just means the script could not open and verify the connection. This >> is due to a "bug" in python-ldap or openldap, in that if you have already >> specified a CA cert, it will not let you specify another one. This is >> usually ok and can be ignored. >> > > Good to know. > > >>> and there are similar connection >>> errors in the dirsrv error log. >>> >> That's not so good. That usually means the CA cert from AD was not properly >> installed in the directory server cert db. >> >> What errors do you see? >> > > Hmm... I did see some errors, but not really anymore. I was seeing > this, but maybe it was just when I was rebooting the AD server or > something: > > [09/Nov/2009:12:30:46 -0500] slapi_ldap_bind - Error: could not send > bind request for id [CN=Administrator,CN=Users,DC=prism,DC=internal] > mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP > connection reset by peer.) 115 (Operation now in progress) > You would see this if you were rebooting the AD machine. If you see it otherwise, it could be a problem. > I also see a few of these: > > [13/Nov/2009:14:50:53 -0500] NSMMReplicationPlugin - failed to send > dirsync search request: 2 > This is benign and will be fixed in the next release. > > Okay, I looked at the FAQ you linked above and changed the log level > to 8192. Here's one of the messages I see after using ipa-passwd: > [13/Nov/2009:19:05:34 -0500] NSMMReplicationPlugin - > agmt="cn=meToprism_ad.prism.internal636" (prism_ad:636): AD already > has the current password for CN=Sam > Hartsfield,CN=Users,DC=prism,DC=internal. Not sending password modify > to AD. > > I'm attaching a longer portion of the log. As far as I can tell, the > password has not been changed on the AD side, only in IPA (using a > Windows XP client attached to the domain, the new password does not > allow me to log in). > Windows 2003 or 2008? 32-bit or 64-bit? > > >>> However, I was able to connect with >>> the ldapsearch command after adding a line for that same file to my >>> ".ldaprc" ("TLS_CACERT /home/samh/prism_ad.cer"): >>> >>> >>> ldapsearch -x -D CN=Administrator,CN=Users,DC=prism,DC=internal -w >>> password -H ldaps://prism_ad.prism.internal -b "dc=prism,dc=internal" >>> >>> >> Ok. Try this: >> certutil -d /etc/dirsrv/slapd-YOUR-INSTANCE-HERE -L >> you should see an entry for your MS CA - if you do, then try this >> /usr/lib/mozldap/ldapsearch -h adhostname -p 636 -Z -P >> /etc/dirsrv/slapd-YOUR-INSTANCE-HERE/cert8.db -D >> "CN=Administrator,CN=Users,DC=prism,DC=internal" -w password -s base -b "" >> > > I'm guessing "Imported CA" might be the AD certificate: > Yes. >> [root at ipaserver samh]# certutil -d /etc/dirsrv/slapd-PRISM-INTERNAL/ -L >> Certificate Nickname Trust Attributes >> SSL,S/MIME,JAR/XPI >> >> CA certificate CTu,u,Cu >> Imported CA CT,,C >> Server-Cert u,u,u >> > > I was wondering where that version of ldapsearch was. I ran this, and > got the expected output (all my attributes): > > /usr/lib/mozldap/ldapsearch -h prism_ad.prism.internal -p 636 -Z -P > /etc/dirsrv/slapd-PRISM-INTERNAL/cert8.db -D > "CN=Administrator,CN=Users,DC=prism,DC=internal" -w password -s base > -b "" sAMAccountname=samh > > As expected, it did not run without the -P option ("SSL initialization > failed: error -8174 (security library: bad database.)"). > Right. mozldap uses NSS for crypto, just like the directory server, so that's how you can test the cert db. This would seem to indicate that you have the correct MS CA cert in your cert db. > >>> I exported the certificate using the directions >>> >>> http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html, >>> and the file is readable by all users. >>> >>> >>> This seems to be similar to Jeff Moody's problem earlier this year in >>> the topic "IPA Windows Sync - Windows 2003 R2 SP2 and Fedora 10". I >>> also created an "Enterprise root CA", but he didn't specify how he >>> finally found the correct certificate, just that it wasn't easy! I've >>> searched the computer, and the only ".crt" file is the one I used. In >>> the "Certification Authority" tool, I see that there are two >>> certificates in the chain, but if I export the other one, >>> ipa-replica-manage says "could not add certificate to token or >>> database: Error adding certificate to database." >>> >>> Does anyone have any idea what might be going wrong? >>> >>> >> If you are able to successfully use openldap ldapsearch with that ca cert, >> then either it's not a problem with the CA cert, or you have no TLS/SSL >> checking whatsoever in your ldap configuration. >> > > It certainly seems to be checking; it failed to work over SSL until I > added that TLS_CACERT line. > > Thanks for your comments and suggestions, Rich. I'll continue working > on this next week, and also try to set up a new sync agreement from > scratch with two new machines. > > -- > Sam Hartsfield > -------------- 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 samh.work at gmail.com Tue Nov 17 19:28:34 2009 From: samh.work at gmail.com (Sam Hartsfield) Date: Tue, 17 Nov 2009 14:28:34 -0500 Subject: [Freeipa-users] IPA to AD sync, certificate verify failed In-Reply-To: <4B016CD7.6000206@redhat.com> References: <4AFC723F.8000201@redhat.com> <4B016CD7.6000206@redhat.com> Message-ID: On Mon, Nov 16, 2009 at 10:16 AM, Rich Megginson wrote: > Sam Hartsfield wrote: >> >> On Thu, Nov 12, 2009 at 3:38 PM, Rich Megginson >> wrote: >> >>> >>> Sam Hartsfield wrote: >>> >>>> >>>> I am using FreeIPA 1.2.2 and trying to synchronize with AD on Windows >>>> Server 2003. >>>> >>>> Are password changes in FreeIPA supposed to be synced to Active >>>> Directory? >>>> >>> >>> Yes. >>> >>>> >>>> I couldn't find any reference to this specific in the >>>> documentation, but on my test setup passwords are not being changed in >>>> AD (using the ipa-passwd command; I also tried the Windows XP password >>>> change dialog). Password changes in AD /are/ properly reflected in >>>> FreeIPA. >>>> >>>> >>> >>> You could try using the replication error log level to debug winsync >>> problems - http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting >>> >>>> >>>> When I the run command to add the sync (I'm using Administrator just >>>> for testing purposes): >>>> >>>> ipa-replica-manage add --winsync --binddn >>>> CN=Administrator,CN=Users,DC=prism,DC=internal --bindpw password >>>> --cacert /home/samh/prism_ad.cer prism_ad.prism.internal -v --passsync >>>> password >>>> >>>> I get this: >>>> >>>> INFO:root:Added CA certificate /home/samh/prism_ad.cer to certificate >>>> database for ipaserver.prism.internal >>>> INFO:root:Restarted directory server ipaserver.prism.internal >>>> INFO:root:Could not validate connection to remote server >>>> prism_ad.prism.internal:636 - continuing >>>> INFO:root:The error was: {'info': 'error:14090086:SSL >>>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', >>>> 'desc': "Can't contact LDAP server"} >>>> >>>> indicating a certificate problem, >>>> >>> >>> This just means the script could not open and verify the connection. >>> ?This >>> is due to a "bug" in python-ldap or openldap, in that if you have already >>> specified a CA cert, it will not let you specify another one. ?This is >>> usually ok and can be ignored. >>> >> >> Good to know. >> >> >>>> >>>> and there are similar connection >>>> errors in the dirsrv error log. >>>> >>> >>> That's not so good. ?That usually means the CA cert from AD was not >>> properly >>> installed in the directory server cert db. >>> >>> What errors do you see? >>> >> >> Hmm... I did see some errors, but not really anymore. I was seeing >> this, but maybe it was just when I was rebooting the AD server or >> something: >> >> [09/Nov/2009:12:30:46 -0500] slapi_ldap_bind - Error: could not send >> bind request for id [CN=Administrator,CN=Users,DC=prism,DC=internal] >> mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP >> connection reset by peer.) 115 (Operation now in progress) >> > > You would see this if you were rebooting the AD machine. ?If you see it > otherwise, it could be a problem. >> >> I also see a few of these: >> >> [13/Nov/2009:14:50:53 -0500] NSMMReplicationPlugin - failed to send >> dirsync search request: 2 >> > > This is benign and will be fixed in the next release. >> >> Okay, I looked at the FAQ you linked above and changed the log level >> to 8192. Here's one of the messages I see after using ipa-passwd: >> [13/Nov/2009:19:05:34 -0500] NSMMReplicationPlugin - >> agmt="cn=meToprism_ad.prism.internal636" (prism_ad:636): AD already >> has the current password for CN=Sam >> Hartsfield,CN=Users,DC=prism,DC=internal. Not sending password modify >> to AD. >> >> I'm attaching a longer portion of the log. As far as I can tell, the >> password has not been changed on the AD side, only in IPA (using a >> Windows XP client attached to the domain, the new password does not >> allow me to log in). >> > > Windows 2003 or 2008? ?32-bit or 64-bit? >> >> >>>> >>>> However, I was able to connect with >>>> the ldapsearch command after adding a line for that same file to my >>>> ".ldaprc" ("TLS_CACERT /home/samh/prism_ad.cer"): >>>> >>>> ? ? ?ldapsearch -x -D CN=Administrator,CN=Users,DC=prism,DC=internal -w >>>> password -H ldaps://prism_ad.prism.internal -b "dc=prism,dc=internal" >>>> >>>> >>> >>> Ok. ?Try this: >>> certutil -d /etc/dirsrv/slapd-YOUR-INSTANCE-HERE -L >>> you should see an entry for your MS CA - if you do, then try this >>> /usr/lib/mozldap/ldapsearch -h adhostname -p 636 -Z -P >>> /etc/dirsrv/slapd-YOUR-INSTANCE-HERE/cert8.db -D >>> "CN=Administrator,CN=Users,DC=prism,DC=internal" -w password -s base -b >>> "" >>> >> >> I'm guessing "Imported CA" might be the AD certificate: >> > > Yes. >>> >>> [root at ipaserver samh]# certutil -d /etc/dirsrv/slapd-PRISM-INTERNAL/ -L >>> Certificate Nickname ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Trust >>> Attributes >>> >>> ?SSL,S/MIME,JAR/XPI >>> >>> CA certificate ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CTu,u,Cu >>> Imported CA ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?CT,,C >>> Server-Cert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u,u,u >>> >> >> I was wondering where that version of ldapsearch was. I ran this, and >> got the expected output (all my attributes): >> >> /usr/lib/mozldap/ldapsearch -h prism_ad.prism.internal -p 636 -Z -P >> /etc/dirsrv/slapd-PRISM-INTERNAL/cert8.db -D >> "CN=Administrator,CN=Users,DC=prism,DC=internal" -w password -s base >> -b "" sAMAccountname=samh >> >> As expected, it did not run without the -P option ("SSL initialization >> failed: error -8174 (security library: bad database.)"). >> > > Right. ?mozldap uses NSS for crypto, just like the directory server, so > that's how you can test the cert db. > > This would seem to indicate that you have the correct MS CA cert in your > cert db. >> >> >>>> >>>> ?I exported the certificate using the directions >>>> >>>> >>>> http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html, >>>> and the file is readable by all users. >>>> >>>> >>>> This seems to be similar to Jeff Moody's problem earlier this year in >>>> the topic "IPA Windows Sync - Windows 2003 R2 SP2 and Fedora 10". I >>>> also created an "Enterprise root CA", but he didn't specify how he >>>> finally found the correct certificate, just that it wasn't easy! I've >>>> searched the computer, and the only ".crt" file is the one I used. In >>>> the "Certification Authority" tool, I see that there are two >>>> certificates in the chain, but if I export the other one, >>>> ipa-replica-manage says "could not add certificate to token or >>>> database: Error adding certificate to database." >>>> >>>> Does anyone have any idea what might be going wrong? >>>> >>>> >>> >>> If you are able to successfully use openldap ldapsearch with that ca >>> cert, >>> then either it's not a problem with the CA cert, or you have no TLS/SSL >>> checking whatsoever in your ldap configuration. >>> >> >> It certainly seems to be checking; it failed to work over SSL until I >> added that TLS_CACERT line. >> >> Thanks for your comments and suggestions, Rich. I'll continue working >> on this next week, and also try to set up a new sync agreement from >> scratch with two new machines. >> >> -- >> Sam Hartsfield >> > > I haven't seen anymore of the errors I mentioned, so I'm guessing that was just from a reboot. The AD server is Windows Server 2003, 32-bit. It sounds like the certificate is okay, but passwords still don't seem to be sent back to AD. I've been checking the dirsrv error log as I mentioned, and I don't see anything that looks like an error; I can attach another excerpt if that would help. Is there anything else I should be looking at? Thanks, Sam Hartsfield From rmeggins at redhat.com Tue Nov 17 20:13:55 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 17 Nov 2009 13:13:55 -0700 Subject: [Freeipa-users] IPA to AD sync, certificate verify failed In-Reply-To: References: <4AFC723F.8000201@redhat.com> <4B016CD7.6000206@redhat.com> Message-ID: <4B030403.2090505@redhat.com> Sam Hartsfield wrote: > On Mon, Nov 16, 2009 at 10:16 AM, Rich Megginson wrote: > >> Sam Hartsfield wrote: >> >>> On Thu, Nov 12, 2009 at 3:38 PM, Rich Megginson >>> wrote: >>> >>> >>>> Sam Hartsfield wrote: >>>> >>>> >>>>> I am using FreeIPA 1.2.2 and trying to synchronize with AD on Windows >>>>> Server 2003. >>>>> >>>>> Are password changes in FreeIPA supposed to be synced to Active >>>>> Directory? >>>>> >>>>> >>>> Yes. >>>> >>>> >>>>> I couldn't find any reference to this specific in the >>>>> documentation, but on my test setup passwords are not being changed in >>>>> AD (using the ipa-passwd command; I also tried the Windows XP password >>>>> change dialog). Password changes in AD /are/ properly reflected in >>>>> FreeIPA. >>>>> >>>>> >>>>> >>>> You could try using the replication error log level to debug winsync >>>> problems - http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting >>>> >>>> >>>>> When I the run command to add the sync (I'm using Administrator just >>>>> for testing purposes): >>>>> >>>>> ipa-replica-manage add --winsync --binddn >>>>> CN=Administrator,CN=Users,DC=prism,DC=internal --bindpw password >>>>> --cacert /home/samh/prism_ad.cer prism_ad.prism.internal -v --passsync >>>>> password >>>>> >>>>> I get this: >>>>> >>>>> INFO:root:Added CA certificate /home/samh/prism_ad.cer to certificate >>>>> database for ipaserver.prism.internal >>>>> INFO:root:Restarted directory server ipaserver.prism.internal >>>>> INFO:root:Could not validate connection to remote server >>>>> prism_ad.prism.internal:636 - continuing >>>>> INFO:root:The error was: {'info': 'error:14090086:SSL >>>>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', >>>>> 'desc': "Can't contact LDAP server"} >>>>> >>>>> indicating a certificate problem, >>>>> >>>>> >>>> This just means the script could not open and verify the connection. >>>> This >>>> is due to a "bug" in python-ldap or openldap, in that if you have already >>>> specified a CA cert, it will not let you specify another one. This is >>>> usually ok and can be ignored. >>>> >>>> >>> Good to know. >>> >>> >>> >>>>> and there are similar connection >>>>> errors in the dirsrv error log. >>>>> >>>>> >>>> That's not so good. That usually means the CA cert from AD was not >>>> properly >>>> installed in the directory server cert db. >>>> >>>> What errors do you see? >>>> >>>> >>> Hmm... I did see some errors, but not really anymore. I was seeing >>> this, but maybe it was just when I was rebooting the AD server or >>> something: >>> >>> [09/Nov/2009:12:30:46 -0500] slapi_ldap_bind - Error: could not send >>> bind request for id [CN=Administrator,CN=Users,DC=prism,DC=internal] >>> mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP >>> connection reset by peer.) 115 (Operation now in progress) >>> >>> >> You would see this if you were rebooting the AD machine. If you see it >> otherwise, it could be a problem. >> >>> I also see a few of these: >>> >>> [13/Nov/2009:14:50:53 -0500] NSMMReplicationPlugin - failed to send >>> dirsync search request: 2 >>> >>> >> This is benign and will be fixed in the next release. >> >>> Okay, I looked at the FAQ you linked above and changed the log level >>> to 8192. Here's one of the messages I see after using ipa-passwd: >>> [13/Nov/2009:19:05:34 -0500] NSMMReplicationPlugin - >>> agmt="cn=meToprism_ad.prism.internal636" (prism_ad:636): AD already >>> has the current password for CN=Sam >>> Hartsfield,CN=Users,DC=prism,DC=internal. Not sending password modify >>> to AD. >>> >>> I'm attaching a longer portion of the log. As far as I can tell, the >>> password has not been changed on the AD side, only in IPA (using a >>> Windows XP client attached to the domain, the new password does not >>> allow me to log in). >>> >>> >> Windows 2003 or 2008? 32-bit or 64-bit? >> >>> >>>>> However, I was able to connect with >>>>> the ldapsearch command after adding a line for that same file to my >>>>> ".ldaprc" ("TLS_CACERT /home/samh/prism_ad.cer"): >>>>> >>>>> ldapsearch -x -D CN=Administrator,CN=Users,DC=prism,DC=internal -w >>>>> password -H ldaps://prism_ad.prism.internal -b "dc=prism,dc=internal" >>>>> >>>>> >>>>> >>>> Ok. Try this: >>>> certutil -d /etc/dirsrv/slapd-YOUR-INSTANCE-HERE -L >>>> you should see an entry for your MS CA - if you do, then try this >>>> /usr/lib/mozldap/ldapsearch -h adhostname -p 636 -Z -P >>>> /etc/dirsrv/slapd-YOUR-INSTANCE-HERE/cert8.db -D >>>> "CN=Administrator,CN=Users,DC=prism,DC=internal" -w password -s base -b >>>> "" >>>> >>>> >>> I'm guessing "Imported CA" might be the AD certificate: >>> >>> >> Yes. >> >>>> [root at ipaserver samh]# certutil -d /etc/dirsrv/slapd-PRISM-INTERNAL/ -L >>>> Certificate Nickname Trust >>>> Attributes >>>> >>>> SSL,S/MIME,JAR/XPI >>>> >>>> CA certificate CTu,u,Cu >>>> Imported CA CT,,C >>>> Server-Cert u,u,u >>>> >>>> >>> I was wondering where that version of ldapsearch was. I ran this, and >>> got the expected output (all my attributes): >>> >>> /usr/lib/mozldap/ldapsearch -h prism_ad.prism.internal -p 636 -Z -P >>> /etc/dirsrv/slapd-PRISM-INTERNAL/cert8.db -D >>> "CN=Administrator,CN=Users,DC=prism,DC=internal" -w password -s base >>> -b "" sAMAccountname=samh >>> >>> As expected, it did not run without the -P option ("SSL initialization >>> failed: error -8174 (security library: bad database.)"). >>> >>> >> Right. mozldap uses NSS for crypto, just like the directory server, so >> that's how you can test the cert db. >> >> This would seem to indicate that you have the correct MS CA cert in your >> cert db. >> >>> >>>>> I exported the certificate using the directions >>>>> >>>>> >>>>> http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html, >>>>> and the file is readable by all users. >>>>> >>>>> >>>>> This seems to be similar to Jeff Moody's problem earlier this year in >>>>> the topic "IPA Windows Sync - Windows 2003 R2 SP2 and Fedora 10". I >>>>> also created an "Enterprise root CA", but he didn't specify how he >>>>> finally found the correct certificate, just that it wasn't easy! I've >>>>> searched the computer, and the only ".crt" file is the one I used. In >>>>> the "Certification Authority" tool, I see that there are two >>>>> certificates in the chain, but if I export the other one, >>>>> ipa-replica-manage says "could not add certificate to token or >>>>> database: Error adding certificate to database." >>>>> >>>>> Does anyone have any idea what might be going wrong? >>>>> >>>>> >>>>> >>>> If you are able to successfully use openldap ldapsearch with that ca >>>> cert, >>>> then either it's not a problem with the CA cert, or you have no TLS/SSL >>>> checking whatsoever in your ldap configuration. >>>> >>>> >>> It certainly seems to be checking; it failed to work over SSL until I >>> added that TLS_CACERT line. >>> >>> Thanks for your comments and suggestions, Rich. I'll continue working >>> on this next week, and also try to set up a new sync agreement from >>> scratch with two new machines. >>> >>> -- >>> Sam Hartsfield >>> >>> >> > > I haven't seen anymore of the errors I mentioned, so I'm guessing that > was just from a reboot. > > The AD server is Windows Server 2003, 32-bit. > > It sounds like the certificate is okay, but passwords still don't seem > to be sent back to AD. I've been checking the dirsrv error log as I > mentioned, and I don't see anything that looks like an error; I can > attach another excerpt if that would help. Is there anything else I > should be looking at? > I don't know. Other people in the 389 community have reported problems sync'ing password changes from DS to AD. I'm not sure what's going on. It seems that MS made some changes to the default AD password policies in 2003 SP1 and later (including 2008). One change is that AD allows you to use your old password for up to 1 hour after changing it - see http://support.microsoft.com/kb/906305/en-us - there may be other changes that cause problems. > Thanks, > Sam Hartsfield > -------------- 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 tomasz.napierala at allegro.pl Wed Nov 25 14:50:07 2009 From: tomasz.napierala at allegro.pl (Tomasz Z. Napierala) Date: Wed, 25 Nov 2009 15:50:07 +0100 Subject: [Freeipa-users] Problem with KRB DNS discovery (i think) Message-ID: <1259160607.12771.9.camel@alledrag> Hi, I'm getting problems installing clients with default ipa-client-install values. Relam and domain are both discovered successfully but then after issuing kinit admin I'm getting: kinit(v5): Cannot resolve network address for KDC in realm QXLTECH while getting initial credentials My krb5.conf looks like this: [libdefaults] default_realm = QXLTECH dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes [domain_realm] .dc2 = QXLTECH dc2 = QXLTECH [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false } Adding static kdc entry solved my problem. DNS is configured properly with all necessary SRV and TXT entries. Do you have any ideas what could be wrong? Regards, -- Tomasz Napiera?a Systems Architecture Engineer, IT Infrastructure Department Allegro Team http://www.allegro.pl/ QXL Poland sp. z o.o. ul. Marceli?ska 90, 60-324 Pozna? NIP 779-21-25-257; S?d Rejonowy Pozna? - Nowe Miasto i Wilda w Poznaniu, Wydzia? VIII Gospodarczy KRS nr 0000104322 Kapita? zak?adowy: 1.046.000 z?. From tomasz.napierala at allegro.pl Wed Nov 25 17:42:16 2009 From: tomasz.napierala at allegro.pl (Tomasz 'Zen' Napierala) Date: Wed, 25 Nov 2009 18:42:16 +0100 Subject: [Freeipa-users] Problem with KRB DNS discovery (i think) In-Reply-To: <1259160607.12771.9.camel@alledrag> References: <1259160607.12771.9.camel@alledrag> Message-ID: <1259170936.10567.10.camel@powerdrag> Dnia 2009-11-25, ?ro o godzinie 15:50 +0100, Tomasz Z. Napierala pisze: > Hi, > > I'm getting problems installing clients with default ipa-client-install > values. Relam and domain are both discovered successfully but then after > issuing kinit admin I'm getting: > > kinit(v5): Cannot resolve network address for KDC in realm QXLTECH while > getting initial credentials > > My krb5.conf looks like this: > [libdefaults] > default_realm = QXLTECH > dns_lookup_realm = true > dns_lookup_kdc = true > ticket_lifetime = 24h > forwardable = yes > > [domain_realm] > .dc2 = QXLTECH > dc2 = QXLTECH > > [appdefaults] > pam = { > debug = false > ticket_lifetime = 36000 > renew_lifetime = 36000 > forwardable = true > krb4_convert = false > } > > Adding static kdc entry solved my problem. DNS is configured properly > with all necessary SRV and TXT entries. > > Do you have any ideas what could be wrong? I dogged little bit deeper and straced kinit. It looks like kinit is picking up wrong domain name. My realm is QXLTECH but domain name .dc2 or .dc3 Kinit is requesting _kerberos._tcp.QXLTECH How can I change it? Regards, -- Tomasz Z. Napiera?a Systems Architecture Engineer, IT Infrastructure Department Allegro Team http://www.allegro.pl/ QXL Poland sp. z o.o. ul. Marceli?ska 90, 60-324 Pozna? NIP 779-21-25-257; S?d Rejonowy Pozna? - Nowe Miasto i Wilda w Poznaniu, Wydzia? VIII Gospodarczy KRS nr 0000104322 Kapita? zak?adowy: 1.046.000 z?. From nalin at redhat.com Wed Nov 25 18:32:38 2009 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 25 Nov 2009 13:32:38 -0500 Subject: [Freeipa-users] Problem with KRB DNS discovery (i think) In-Reply-To: <1259170936.10567.10.camel@powerdrag> References: <1259160607.12771.9.camel@alledrag> <1259170936.10567.10.camel@powerdrag> Message-ID: <20091125183238.GE28500@redhat.com> On Wed, Nov 25, 2009 at 06:42:16PM +0100, Tomasz 'Zen' Napierala wrote: > Dnia 2009-11-25, ?ro o godzinie 15:50 +0100, Tomasz Z. Napierala pisze: > > Hi, > > > > I'm getting problems installing clients with default ipa-client-install > > values. Relam and domain are both discovered successfully but then after > > issuing kinit admin I'm getting: > > > > kinit(v5): Cannot resolve network address for KDC in realm QXLTECH while > > getting initial credentials > > > > My krb5.conf looks like this: > > [libdefaults] > > default_realm = QXLTECH > > dns_lookup_realm = true > > dns_lookup_kdc = true > > ticket_lifetime = 24h > > forwardable = yes > > > > [domain_realm] > > .dc2 = QXLTECH > > dc2 = QXLTECH [snip] > I dogged little bit deeper and straced kinit. It looks like kinit is > picking up wrong domain name. > My realm is QXLTECH but domain name .dc2 or .dc3 Kinit is requesting > _kerberos._tcp.QXLTECH > How can I change it? I wouldn't recommend trying, not exactly. The client's doing what the standards say it should, but that might be confusing in cases where the realm name and domain name are different because the query is based on the realm name and not the domain name. To understand it, it's useful to know that there are two kinds of DNS queries being made here: 1. Kerberos is using DNS to figure out the name of the realm to which a given host belongs, and for that it's going to use the hostname and domain name to form its queries. For the configuration you provided, the records in DNS would probably look something like this: _kerberos.dc2. IN TXT "QXLTECH" 2. Kerberos is using DNS to get the hostname of a KDC for the realm. The important detail is that it uses the realm name and not a domain name to form the query, and I suspect that's what's missing in your setup. The records in DNS are regular SRV records, and they'd probably look like this: _kerberos._udp.qxltech. IN SRV 0 0 88 kdc-host.dc2. _kerberos._tcp.qxltech. IN SRV 0 0 88 kdc-host.dc2. _kerberos-master._udp.qxltech. IN SRV 0 0 88 kdc-host.dc2. _kerberos-master._tcp.qxltech. IN SRV 0 0 88 kdc-host.dc2. _kpasswd._udp.qxltech. IN SRV 0 0 464 kdc-host.dc2. _kpasswd._tcp.qxltech. IN SRV 0 0 464 kdc-host.dc2. It's pretty common to have the DNS domain name and the Kerberos realm name differ only by case (for example, "example.com" as a domain name, and "EXAMPLE.COM" as the realm), or to have the domain name look like a subdomain of the realm name (for example, "devel.example.com" for the domain name, "EXAMPLE.COM" for the realm) so most people end up not having to care that the second case uses the realm rather than the DNS domain name. But it looks as though, in your configuration, you do. HTH, Nalin From tomasz.napierala at allegro.pl Wed Nov 25 19:39:03 2009 From: tomasz.napierala at allegro.pl (Tomasz 'Zen' Napierala) Date: Wed, 25 Nov 2009 20:39:03 +0100 Subject: [Freeipa-users] Problem with KRB DNS discovery (i think) In-Reply-To: <20091125183238.GE28500@redhat.com> References: <1259160607.12771.9.camel@alledrag> <1259170936.10567.10.camel@powerdrag> <20091125183238.GE28500@redhat.com> Message-ID: <1259177943.10567.23.camel@powerdrag> Dnia 2009-11-25, ?ro o godzinie 19:32 +0100, Nalin Dahyabhai pisze: > On Wed, Nov 25, 2009 at 06:42:16PM +0100, Tomasz 'Zen' Napierala wrote: > > Dnia 2009-11-25, ?ro o godzinie 15:50 +0100, Tomasz Z. Napierala pisze: > > > Hi, > > > > > > I'm getting problems installing clients with default ipa-client-install > > > values. Relam and domain are both discovered successfully but then after > > > issuing kinit admin I'm getting: > > > > > > kinit(v5): Cannot resolve network address for KDC in realm QXLTECH while > > > getting initial credentials > > > > > > My krb5.conf looks like this: > > > [libdefaults] > > > default_realm = QXLTECH > > > dns_lookup_realm = true > > > dns_lookup_kdc = true > > > ticket_lifetime = 24h > > > forwardable = yes > > > > > > [domain_realm] > > > .dc2 = QXLTECH > > > dc2 = QXLTECH > [snip] > > I dogged little bit deeper and straced kinit. It looks like kinit is > > picking up wrong domain name. > > My realm is QXLTECH but domain name .dc2 or .dc3 Kinit is requesting > > _kerberos._tcp.QXLTECH > > How can I change it? > > I wouldn't recommend trying, not exactly. The client's doing what the > standards say it should, but that might be confusing in cases where the > realm name and domain name are different because the query is based on > the realm name and not the domain name. To understand it, it's useful > to know that there are two kinds of DNS queries being made here: > > 1. Kerberos is using DNS to figure out the name of the realm to which a > given host belongs, and for that it's going to use the hostname and > domain name to form its queries. For the configuration you provided, > the records in DNS would probably look something like this: > _kerberos.dc2. IN TXT "QXLTECH" > > 2. Kerberos is using DNS to get the hostname of a KDC for the realm. > The important detail is that it uses the realm name and not a domain > name to form the query, and I suspect that's what's missing in your > setup. The records in DNS are regular SRV records, and they'd > probably look like this: > _kerberos._udp.qxltech. IN SRV 0 0 88 kdc-host.dc2. > _kerberos._tcp.qxltech. IN SRV 0 0 88 kdc-host.dc2. > _kerberos-master._udp.qxltech. IN SRV 0 0 88 kdc-host.dc2. > _kerberos-master._tcp.qxltech. IN SRV 0 0 88 kdc-host.dc2. > _kpasswd._udp.qxltech. IN SRV 0 0 464 kdc-host.dc2. > _kpasswd._tcp.qxltech. IN SRV 0 0 464 kdc-host.dc2. > > It's pretty common to have the DNS domain name and the Kerberos realm > name differ only by case (for example, "example.com" as a domain name, > and "EXAMPLE.COM" as the realm), or to have the domain name look like a > subdomain of the realm name (for example, "devel.example.com" for the > domain name, "EXAMPLE.COM" for the realm) so most people end up not > having to care that the second case uses the realm rather than the DNS > domain name. But it looks as though, in your configuration, you do. Thanks for thorough explanation, I was just thinkign of examining MIT krb sources to figure out what is being taken into account when requesting kdc servers form DNS. That would be possibly hard, as I'm rather C illiterate ;) I'll modify DNS configuration in more thinking friendly hours, ale let you know of the outcome. Thanks again, that sounds like my issue indeed. Regards, -- Tomasz Z. Napiera?a Systems Architecture Engineer, IT Infrastructure Department Allegro Team http://www.allegro.pl/ QXL Poland sp. z o.o. ul. Marceli?ska 90, 60-324 Pozna? NIP 779-21-25-257; S?d Rejonowy Pozna? - Nowe Miasto i Wilda w Poznaniu, Wydzia? VIII Gospodarczy KRS nr 0000104322 Kapita? zak?adowy: 1.046.000 z?.