From wiz561 at gmail.com Thu Dec 3 16:14:44 2009 From: wiz561 at gmail.com (Michael Wisniewski) Date: Thu, 3 Dec 2009 10:14:44 -0600 Subject: [Freeipa-users] FreeIPA as a password backend to Samba Message-ID: <9314ecb90912030814w23577b46rff849a901750e89e@mail.gmail.com> Hi, I've discovered that back in September, a user was attempting to use FreeIPA as a password backend to Samba. I've followed the instructions from Loris, but ran into a problem. Whenever I create a new group, I get the following error through the web interface... Group add failed: A database error occurred Object class violation. missing attribute "sambaGroupType" required by object class "sambaGroupMapping" If I use the command line 'ipa-addgroup', I get a similar error. However, if I use a ldif and set everything, it works... # ldif2ldap "cn=Directory manager" /tmp/s1.ldif # cat /tmp/s1.ldif dn: cn=Cyber,cn=groups,cn=accounts,dc=test,dc=org objectClass: top objectClass: groupofnames objectClass: posixGroup cn: Cyber description: Cyber Security Group gidNumber: 1005 Now the strange thing. While I did add the "sambaGroupMapping", I don't see it when I do a ldapsearch and view the group. Also, if I add my user to the newly created group and run "id", it doesn't show up that I belong to that group. If anybody can help me with this, that would be great. Since I'm just starting, if somebody says FreeIPA v2 has this already, I don't mind switching to it. Thanks, Mike From ssorce at redhat.com Sat Dec 5 23:20:45 2009 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 05 Dec 2009 18:20:45 -0500 Subject: [Freeipa-users] FreeIPA as a password backend to Samba In-Reply-To: <9314ecb90912030814w23577b46rff849a901750e89e@mail.gmail.com> References: <9314ecb90912030814w23577b46rff849a901750e89e@mail.gmail.com> Message-ID: <1260055245.24247.9.camel@willson.li.ssimo.org> On Thu, 2009-12-03 at 10:14 -0600, Michael Wisniewski wrote: > Hi, > > I've discovered that back in September, a user was attempting to use > FreeIPA as a password backend to Samba. I've followed the > instructions from Loris, but ran into a problem. Whenever I create a > new group, I get the following error through the web interface... > > > Group add failed: A database error occurred > Object class violation. missing attribute "sambaGroupType" required by > object class "sambaGroupMapping" > > If I use the command line 'ipa-addgroup', I get a similar error. It looks like sambaGroupType is a required attribute for the sambaGroupMapping objectclass and it is not being added. You need to make sure to add a custom sambaGroupType attribute when you create the group. > However, if I use a ldif and set everything, it works... > > # ldif2ldap "cn=Directory manager" /tmp/s1.ldif > # cat /tmp/s1.ldif > dn: cn=Cyber,cn=groups,cn=accounts,dc=test,dc=org > objectClass: top > objectClass: groupofnames > objectClass: posixGroup > cn: Cyber > description: Cyber Security Group > gidNumber: 1005 > > Now the strange thing. While I did add the "sambaGroupMapping", I > don't see it when I do a ldapsearch and view the group. Also, if I > add my user to the newly created group and run "id", it doesn't show > up that I belong to that group. That may be due to nscd caching, make sure to reload/restart nscd when you change group memberships if you need to see the result immediately. The default group cache timeout can even be 1h on some system. > If anybody can help me with this, that would be great. Since I'm just > starting, if somebody says FreeIPA v2 has this already, I don't mind > switching to it. v2 is a bit experimental at the moment. It is great if you want to see what's going on and help testing but it is not production ready. Simo. -- Simo Sorce * Red Hat, Inc * New York From tomasz.napierala at allegro.pl Mon Dec 7 09:56:28 2009 From: tomasz.napierala at allegro.pl (Tomasz Z. Napierala) Date: Mon, 7 Dec 2009 10:56:28 +0100 Subject: [Freeipa-users] Setting nsslapd-maxdescriptors Message-ID: <1260179788.15681.11.camel@alledrag> Hi, I came across fds limit problem, and I wanted to change that parameter for my FDS instance. I tried to put it in /etc/dirsrv/slapd-INSTANCE/dse.ldif, but this file gets overwritten every time dirsrv is restarted. What is the best way to change that setting? 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 Mon Dec 7 10:31:02 2009 From: tomasz.napierala at allegro.pl (Tomasz Z. Napierala) Date: Mon, 7 Dec 2009 11:31:02 +0100 Subject: [Freeipa-users] Setting nsslapd-maxdescriptors In-Reply-To: <1260179788.15681.11.camel@alledrag> References: <1260179788.15681.11.camel@alledrag> Message-ID: <1260181862.15681.17.camel@alledrag> Dnia 2009-12-07, pon o godzinie 10:56 +0100, Tomasz Z. Napierala pisze: > Hi, > > I came across fds limit problem, and I wanted to change that parameter > for my FDS instance. I tried to put it > in /etc/dirsrv/slapd-INSTANCE/dse.ldif, but this file gets overwritten > every time dirsrv is restarted. What is the best way to change that > setting? Problem solved ;) I was editing the file, and then restarting dirsrv. It looks like you have to stop the instance, then edit the file, and start the instance after that. 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 rmeggins at redhat.com Mon Dec 7 15:19:23 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 07 Dec 2009 08:19:23 -0700 Subject: [Freeipa-users] Setting nsslapd-maxdescriptors In-Reply-To: <1260181862.15681.17.camel@alledrag> References: <1260179788.15681.11.camel@alledrag> <1260181862.15681.17.camel@alledrag> Message-ID: <4B1D1CFB.8030506@redhat.com> Tomasz Z. Napierala wrote: > Dnia 2009-12-07, pon o godzinie 10:56 +0100, Tomasz Z. Napierala pisze: > >> Hi, >> >> I came across fds limit problem, and I wanted to change that parameter >> for my FDS instance. I tried to put it >> in /etc/dirsrv/slapd-INSTANCE/dse.ldif, but this file gets overwritten >> every time dirsrv is restarted. What is the best way to change that >> setting? >> > > Problem solved ;) > I was editing the file, and then restarting dirsrv. It looks like you > have to stop the instance, then edit the file, and start the instance > after that. > You can also set the value using ldapmodify ldapmodify -x -D "cn=directory manager" -w password dn: cn=config changetype: modify replace: nsslapd-maxdescriptors nsslapd-maxdescriptors: 8192 You have to restart the server for this setting to take effect. See also http://directory.fedoraproject.org/wiki/Performance_Tuning#Linux > Regards, > From wiz561 at gmail.com Mon Dec 7 16:06:44 2009 From: wiz561 at gmail.com (Michael Wisniewski) Date: Mon, 7 Dec 2009 10:06:44 -0600 Subject: [Freeipa-users] FreeIPA as a password backend to Samba In-Reply-To: <1260055245.24247.9.camel@willson.li.ssimo.org> References: <9314ecb90912030814w23577b46rff849a901750e89e@mail.gmail.com> <1260055245.24247.9.camel@willson.li.ssimo.org> Message-ID: <9314ecb90912070806i51c62db8ucbe5ebcf696731f0@mail.gmail.com> On Sat, Dec 5, 2009 at 5:20 PM, Simo Sorce wrote: > On Thu, 2009-12-03 at 10:14 -0600, Michael Wisniewski wrote: >> Hi, >> >> I've discovered that back in September, a user was attempting to use >> FreeIPA as a password backend to Samba. ?I've followed the >> instructions from Loris, but ran into a problem. ?Whenever I create a >> new group, I get the following error through the web interface... >> >> >> Group add failed: A database error occurred >> Object class violation. missing attribute "sambaGroupType" required by >> object class "sambaGroupMapping" >> >> If I use the command line 'ipa-addgroup', I get a similar error. > > It looks like sambaGroupType is a required attribute for the > sambaGroupMapping objectclass and it is not being added. > > You need to make sure to add a custom sambaGroupType attribute when you > create the group. > You are correct, this did the trick. I'm not sure why this is required yet...I'm still working on it. >> However, if I use a ldif and set everything, it works... >> >> # ldif2ldap "cn=Directory manager" /tmp/s1.ldif >> # cat /tmp/s1.ldif >> dn: cn=Cyber,cn=groups,cn=accounts,dc=test,dc=org >> objectClass: top >> objectClass: groupofnames >> objectClass: posixGroup >> cn: Cyber >> description: Cyber Security Group >> gidNumber: 1005 >> >> Now the strange thing. ?While I did add the "sambaGroupMapping", I >> don't see it when I do a ldapsearch and view the group. ?Also, if I >> add my user to the newly created group and run "id", it doesn't show >> up that I belong to that group. > > That may be due to nscd caching, make sure to reload/restart nscd when > you change group memberships if you need to see the result immediately. > The default group cache timeout can even be 1h on some system. > What happened is that on the freeipa server, it seemed to automatically fix itself the next day. I'm guessing that if I restarted nscd, as you suggested, it would have been fine. The other issue I was running into was on the remote system that I have configured for ldap authentication, it wasn't seeing the new group. It showed the 'ipauser' group for myself, but not the new one. This was something I forgot to do; add the nss_base_group to the ldap.conf on the remote system. After I did this, everything is fine. Thanks! From wxiluo at gmail.com Tue Dec 8 04:35:18 2009 From: wxiluo at gmail.com (Michael Kang) Date: Tue, 8 Dec 2009 12:35:18 +0800 Subject: [Freeipa-users] Configuring Client SSH Access Problem Message-ID: <97725cf0912072035i3669280ewbbce05c9c2a5158f@mail.gmail.com> Dear all, I had setup a FreeIPA server and a FreeIPA client. After using the *ktutil*command to import the keytab, using the following command on another machine to test the configuration. This still need passwd. IPA Server: > kinit admin > ipa-addservice host/ipaclient.example.com > ipa-getkeytab -s ipaserver.example.com -p host/ipaclient.example.com -k > /tmp/krb5.keytab > scp /tmp/krb5.keytab root at ipaclient.example.com:/tmp/krb5.keytab > IPA client: > # ktutil > ktutil: read_kt /tmp/krb5.keytab > ktutil: write_kt /etc/krb5/krb5.keytab > ktutil: q > ssh admin@*ipaserver*.example.com (This don't need passwd.) PC or Mac: ssh admin@*ipaclient*.example.com (This still need passwd.) What should I do? Best Regards, Michael Kang -- Michael Kang?????? There is a giant asleep within every man. When the giant awakens,miracles happen. Personal blog: http://ufusion.org - United Fusion -------------- next part -------------- An HTML attachment was scrubbed... URL: From wiz561 at gmail.com Tue Dec 8 14:10:10 2009 From: wiz561 at gmail.com (Michael Wisniewski) Date: Tue, 8 Dec 2009 08:10:10 -0600 Subject: [Freeipa-users] LDAP-101 Message-ID: <9314ecb90912080610q4549d9e6w5dc2ab7e643d7a22@mail.gmail.com> Hi! I'm just starting to jump into freeipa/ldap, and have another question about it. Basically, you have LDAP, which from everything I read, is just a directory server. It's sole purpose is like a phone book. Integrated (or on top of) ldap, you can have authentication. There's kerberos, smb/ldap, etc... Now, my question is when you add something like "smb/windows" authentication, do you just add a field in LDAP so it stores the password hashes (and other windows stuff)? When you "extend" the schema, is all you're doing is adding the fields to the ldap database to allow the storage of this? If this is the case, what prevents a malicious user from dumping the hashes to the passwords? I know this is really a basic question, but it would help me understand how all this works. Thanks, Mike From rcritten at redhat.com Tue Dec 8 14:58:18 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Dec 2009 09:58:18 -0500 Subject: [Freeipa-users] LDAP-101 In-Reply-To: <9314ecb90912080610q4549d9e6w5dc2ab7e643d7a22@mail.gmail.com> References: <9314ecb90912080610q4549d9e6w5dc2ab7e643d7a22@mail.gmail.com> Message-ID: <4B1E698A.6040701@redhat.com> Michael Wisniewski wrote: > Hi! > > I'm just starting to jump into freeipa/ldap, and have another question > about it. Basically, you have LDAP, which from everything I read, is > just a directory server. It's sole purpose is like a phone book. > Integrated (or on top of) ldap, you can have authentication. There's > kerberos, smb/ldap, etc... > > Now, my question is when you add something like "smb/windows" > authentication, do you just add a field in LDAP so it stores the > password hashes (and other windows stuff)? When you "extend" the > schema, is all you're doing is adding the fields to the ldap database > to allow the storage of this? If this is the case, what prevents a > malicious user from dumping the hashes to the passwords? Schema is sort of a 2-step process. Step 1 is to tell the directory server about the schema at all. This can be done offline by dropping a schema file into a filesystem directory or online by uploading the schema. Either way this just tells the LDAP server about the new objectclasses and attributes available and their syntaxes. Step 2 is to add those objectclasses and attributes to entries. An objectclass tells which attributes are available to any entry, some of which are mandatory. Think of an objectclass as sort of a building block that adds more capabilities to an entry. There are access controls that manage who can do what. A typical user can write their password but cannot read it (e.g. you can't see the hash(es)). A typical user cannot see anyone else's password info and can't write any other records. > > I know this is really a basic question, but it would help me > understand how all this works. IPA will eventually hide most of this sort of detail so you can focus on managing your users and not on dealing with attribute-level stuff. rob From wiz561 at gmail.com Tue Dec 8 15:09:23 2009 From: wiz561 at gmail.com (Michael Wisniewski) Date: Tue, 8 Dec 2009 09:09:23 -0600 Subject: [Freeipa-users] LDAP-101 In-Reply-To: <4B1E698A.6040701@redhat.com> References: <9314ecb90912080610q4549d9e6w5dc2ab7e643d7a22@mail.gmail.com> <4B1E698A.6040701@redhat.com> Message-ID: <9314ecb90912080709tfae89e3jb4239f64f11a2064@mail.gmail.com> On Tue, Dec 8, 2009 at 8:58 AM, Rob Crittenden wrote: > > Schema is sort of a 2-step process. Step 1 is to tell the directory server > about the schema at all. This can be done offline by dropping a schema file > into a filesystem directory or online by uploading the schema. Either way > this just tells the LDAP server about the new objectclasses and attributes > available and their syntaxes. Thanks for the response. Another related question. Does freeipa 1.2.2 use the "cn=config" way, or the schema file in /etc/openldap/schema? Again, I'm just starting out, but I found configuration information in both places. I'm just wondering if I were to extend the schema for use with samba, do I want to go the cn=config route, or the /etc/openldap/schema file route. Thanks again, Mike From ssorce at redhat.com Tue Dec 8 19:23:31 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 08 Dec 2009 14:23:31 -0500 Subject: [Freeipa-users] LDAP-101 In-Reply-To: <9314ecb90912080709tfae89e3jb4239f64f11a2064@mail.gmail.com> References: <9314ecb90912080610q4549d9e6w5dc2ab7e643d7a22@mail.gmail.com> <4B1E698A.6040701@redhat.com> <9314ecb90912080709tfae89e3jb4239f64f11a2064@mail.gmail.com> Message-ID: <1260300211.24247.88.camel@willson.li.ssimo.org> On Tue, 2009-12-08 at 09:09 -0600, Michael Wisniewski wrote: > On Tue, Dec 8, 2009 at 8:58 AM, Rob Crittenden wrote: > > > > Schema is sort of a 2-step process. Step 1 is to tell the directory server > > about the schema at all. This can be done offline by dropping a schema file > > into a filesystem directory or online by uploading the schema. Either way > > this just tells the LDAP server about the new objectclasses and attributes > > available and their syntaxes. > > Thanks for the response. Another related question. Does freeipa > 1.2.2 use the "cn=config" way, or the schema file in > /etc/openldap/schema? > > Again, I'm just starting out, but I found configuration information in > both places. I'm just wondering if I were to extend the schema for > use with samba, do I want to go the cn=config route, or the > /etc/openldap/schema file route. FreeIPA uses 389DS as LDAP server not openldap. All the schema files for each instance can be seen under /etc/dirsrv//schema and also by quering the schema online. cn=config can be accessed by the Directory Manager to see or change configuration settings on the fly. Some apply immediately, some other changes may require a DS restart. Simo. -- Simo Sorce * Red Hat, Inc * New York From wxiluo at gmail.com Wed Dec 9 07:16:45 2009 From: wxiluo at gmail.com (Michael Kang) Date: Wed, 9 Dec 2009 15:16:45 +0800 Subject: [Freeipa-users] Re: Configuring Client SSH Access Problem In-Reply-To: <97725cf0912072035i3669280ewbbce05c9c2a5158f@mail.gmail.com> References: <97725cf0912072035i3669280ewbbce05c9c2a5158f@mail.gmail.com> Message-ID: <97725cf0912082316x15a5bc6cpf79dfd04db0c6f56@mail.gmail.com> Does anyone know what's wrong? On Tue, Dec 8, 2009 at 12:35 PM, Michael Kang wrote: > Dear all, > > I had setup a FreeIPA server and a FreeIPA client. After using the *ktutil > * command to import the keytab, using the following command on another > machine to test the configuration. This still need passwd. > > IPA Server: > >> kinit admin >> ipa-addservice host/ipaclient.example.com >> ipa-getkeytab -s ipaserver.example.com -p host/ipaclient.example.com -k >> /tmp/krb5.keytab >> scp /tmp/krb5.keytab root at ipaclient.example.com:/tmp/krb5.keytab >> > > IPA client: > >> # ktutil >> ktutil: read_kt /tmp/krb5.keytab >> ktutil: write_kt /etc/krb5/krb5.keytab >> ktutil: q >> > ssh admin@*ipaserver*.example.com (This don't need passwd.) > > PC or Mac: > ssh admin@*ipaclient*.example.com (This still need passwd.) > > What should I do? > > Best Regards, > Michael Kang > -- > Michael Kang?????? > There is a giant asleep within every man. When the giant awakens,miracles > happen. > > Personal blog: http://ufusion.org - United Fusion > -- Michael Kang?????? There is a giant asleep within every man. When the giant awakens,miracles happen. Personal blog: http://ufusion.org - United Fusion -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Wed Dec 9 13:25:29 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Dec 2009 08:25:29 -0500 Subject: [Freeipa-users] Re: Configuring Client SSH Access Problem In-Reply-To: <97725cf0912082316x15a5bc6cpf79dfd04db0c6f56@mail.gmail.com> References: <97725cf0912072035i3669280ewbbce05c9c2a5158f@mail.gmail.com> <97725cf0912082316x15a5bc6cpf79dfd04db0c6f56@mail.gmail.com> Message-ID: <1260365129.24247.107.camel@willson.li.ssimo.org> On Wed, 2009-12-09 at 15:16 +0800, Michael Kang wrote: > Does anyone know what's wrong? > > On Tue, Dec 8, 2009 at 12:35 PM, Michael Kang > wrote: > Dear all, > > I had setup a FreeIPA server and a FreeIPA client. After using > the ktutil command to import the keytab, using the following > command on another machine to test the configuration. This > still need passwd. > > IPA Server: > kinit admin > ipa-addservice host/ipaclient.example.com > ipa-getkeytab -s ipaserver.example.com -p > host/ipaclient.example.com -k /tmp/krb5.keytab > scp /tmp/krb5.keytab > root at ipaclient.example.com:/tmp/krb5.keytab > > IPA client: > # ktutil > ktutil: read_kt /tmp/krb5.keytab > ktutil: write_kt /etc/krb5/krb5.keytab > ktutil: q > ssh admin at ipaserver.example.com (This don't need passwd.) > > > PC or Mac: > ssh admin at ipaclient.example.com (This still need passwd.) So you did successfully kinit on the PC and on the Mac ? You can get more info on what is going on by using ssh -vvv Simo. -- Simo Sorce * Red Hat, Inc * New York From asn at redhat.com Wed Dec 9 10:50:56 2009 From: asn at redhat.com (Andreas Schneider) Date: Wed, 9 Dec 2009 11:50:56 +0100 Subject: [Freeipa-users] Re: Configuring Client SSH Access Problem In-Reply-To: <97725cf0912082316x15a5bc6cpf79dfd04db0c6f56@mail.gmail.com> References: <97725cf0912072035i3669280ewbbce05c9c2a5158f@mail.gmail.com> <97725cf0912082316x15a5bc6cpf79dfd04db0c6f56@mail.gmail.com> Message-ID: <200912091150.57244.asn@redhat.com> On Wednesday 09 December 2009 08:16:45 Michael Kang wrote: > > ssh admin@*ipaserver*.example.com (This don't need passwd.) > > > > PC or Mac: > > ssh admin@*ipaclient*.example.com (This still need passwd.) > > OpenSSH has disabled gssapi (kerberos) support by default for client and server. You have to enable it in /etc/ssh/ssh_config or/and /etc/ssh/sshd_config. Cheers, -- andreas From danieljamesscott at gmail.com Wed Dec 9 12:30:24 2009 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 9 Dec 2009 07:30:24 -0500 Subject: [Freeipa-users] Re: Configuring Client SSH Access Problem In-Reply-To: <97725cf0912082316x15a5bc6cpf79dfd04db0c6f56@mail.gmail.com> References: <97725cf0912072035i3669280ewbbce05c9c2a5158f@mail.gmail.com> <97725cf0912082316x15a5bc6cpf79dfd04db0c6f56@mail.gmail.com> Message-ID: <6835906b0912090430j5b21ffc4l2819f65f7324683b@mail.gmail.com> Generally, I've found that this is caused by incorrect DNS records. Make sure that your A and PTR records are correct for this host. One other thing, you should be able to run ipa-getkeytab directly on the client. Hope this helps, Dan Scott http://danieljamesscott.org On Wed, Dec 9, 2009 at 02:16, Michael Kang wrote: > Does anyone know what's wrong? > > On Tue, Dec 8, 2009 at 12:35 PM, Michael Kang wrote: >> >> Dear all, >> >> I had setup a FreeIPA server and a FreeIPA client. After using the?ktutil >> command to import the keytab, using the following command on another machine >> to test the configuration. This still need passwd. >> >> IPA Server: >>> >>> kinit admin >>> ipa-addservice host/ipaclient.example.com >>> ipa-getkeytab -s ipaserver.example.com -p host/ipaclient.example.com -k >>> /tmp/krb5.keytab >>> scp /tmp/krb5.keytab root at ipaclient.example.com:/tmp/krb5.keytab >> >> IPA client: >>> >>> # ktutil >>> ktutil: read_kt /tmp/krb5.keytab >>> ktutil: write_kt /etc/krb5/krb5.keytab >>> ktutil: q >> >> ssh admin at ipaserver.example.com (This don't need passwd.) >> >> PC or Mac: >> ssh admin at ipaclient.example.com (This still need passwd.) >> >> What should I do? >> >> Best Regards, >> Michael Kang >> -- >> Michael Kang?????? >> There is a giant asleep within every man. When the giant awakens,miracles >> happen. >> >> Personal blog: http://ufusion.org - United Fusion > > > > -- > Michael Kang?????? > There is a giant asleep within every man. When the giant awakens,miracles > happen. > > Personal blog: http://ufusion.org - United Fusion > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From wxiluo at gmail.com Thu Dec 10 03:26:57 2009 From: wxiluo at gmail.com (Michael Kang) Date: Thu, 10 Dec 2009 11:26:57 +0800 Subject: [Freeipa-users] Re: Configuring Client SSH Access Problem In-Reply-To: <6835906b0912090430j5b21ffc4l2819f65f7324683b@mail.gmail.com> References: <97725cf0912072035i3669280ewbbce05c9c2a5158f@mail.gmail.com> <97725cf0912082316x15a5bc6cpf79dfd04db0c6f56@mail.gmail.com> <6835906b0912090430j5b21ffc4l2819f65f7324683b@mail.gmail.com> Message-ID: <97725cf0912091926g3884e9acw21109e18aff1b527@mail.gmail.com> Dear all, There are three virtual machines: Name: ipa.aragon.local Address: 192.168.8.88 Name: client.aragon.local Address: 192.168.3.33 Name: node.aragon.local Address: 192.168.4.44 DNS is working well(Both A and PTR records) On Wed, Dec 9, 2009 at 8:30 PM, Dan Scott wrote: > Generally, I've found that this is caused by incorrect DNS records. > Make sure that your A and PTR records are correct for this host. > > One other thing, you should be able to run ipa-getkeytab directly on the > client. > > Hope this helps, > > Dan Scott > http://danieljamesscott.org > > On Wed, Dec 9, 2009 at 02:16, Michael Kang wrote: > > Does anyone know what's wrong? > > > > On Tue, Dec 8, 2009 at 12:35 PM, Michael Kang wrote: > >> > >> Dear all, > >> > >> I had setup a FreeIPA server and a FreeIPA client. After using > the ktutil > >> command to import the keytab, using the following command on another > machine > >> to test the configuration. This still need passwd. > >> > >> IPA Server: > >>> > >>> kinit admin > >>> ipa-addservice host/ipaclient.example.com > >>> ipa-getkeytab -s ipaserver.example.com -p host/ipaclient.example.com-k > >>> /tmp/krb5.keytab > >>> scp /tmp/krb5.keytab root at ipaclient.example.com:/tmp/krb5.keytab > >> > >> IPA client: > >>> > >>> # ktutil > >>> ktutil: read_kt /tmp/krb5.keytab > >>> ktutil: write_kt /etc/krb5/krb5.keytab > >>> ktutil: q > >> > >> ssh admin at ipaserver.example.com (This don't need passwd.) > >> > >> PC or Mac: > >> ssh admin at ipaclient.example.com (This still need passwd.) > >> > >> What should I do? > >> > >> Best Regards, > >> Michael Kang > >> -- > >> Michael Kang?????? > >> There is a giant asleep within every man. When the giant > awakens,miracles > >> happen. > >> > >> Personal blog: http://ufusion.org - United Fusion > > > > > > > > -- > > Michael Kang?????? > > There is a giant asleep within every man. When the giant awakens,miracles > > happen. > > > > Personal blog: http://ufusion.org - United Fusion > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- Michael Kang?????? There is a giant asleep within every man. When the giant awakens,miracles happen. Personal blog: http://ufusion.org - United Fusion -------------- next part -------------- An HTML attachment was scrubbed... URL: From wxiluo at gmail.com Thu Dec 10 03:39:02 2009 From: wxiluo at gmail.com (Michael Kang) Date: Thu, 10 Dec 2009 11:39:02 +0800 Subject: [Freeipa-users] Re: Configuring Client SSH Access Problem In-Reply-To: <1260365129.24247.107.camel@willson.li.ssimo.org> References: <97725cf0912072035i3669280ewbbce05c9c2a5158f@mail.gmail.com> <97725cf0912082316x15a5bc6cpf79dfd04db0c6f56@mail.gmail.com> <1260365129.24247.107.camel@willson.li.ssimo.org> Message-ID: <97725cf0912091939n5c87893dt1f6117fe21014013@mail.gmail.com> output of ssh -v ipaserver.example.com: debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/identity debug1: Trying private key: /root/.ssh/id_rsa debug1: Trying private key: /root/.ssh/id_dsa debug1: Next authentication method: password admin at ipa.aragon.local's password: It seems that authentications jump into gssapi-with-mic, but get nothing. On Wed, Dec 9, 2009 at 9:25 PM, Simo Sorce wrote: > On Wed, 2009-12-09 at 15:16 +0800, Michael Kang wrote: > > Does anyone know what's wrong? > > > > On Tue, Dec 8, 2009 at 12:35 PM, Michael Kang > > wrote: > > Dear all, > > > > I had setup a FreeIPA server and a FreeIPA client. After using > > the ktutil command to import the keytab, using the following > > command on another machine to test the configuration. This > > still need passwd. > > > > IPA Server: > > kinit admin > > ipa-addservice host/ipaclient.example.com > > ipa-getkeytab -s ipaserver.example.com -p > > host/ipaclient.example.com -k /tmp/krb5.keytab > > scp /tmp/krb5.keytab > > root at ipaclient.example.com:/tmp/krb5.keytab > > > > IPA client: > > # ktutil > > ktutil: read_kt /tmp/krb5.keytab > > ktutil: write_kt /etc/krb5/krb5.keytab > > ktutil: q > > ssh admin at ipaserver.example.com (This don't need passwd.) > > > > > > PC or Mac: > > ssh admin at ipaclient.example.com (This still need passwd.) > > So you did successfully kinit on the PC and on the Mac ? > You can get more info on what is going on by using ssh -vvv > > Simo. > > > -- > Simo Sorce * Red Hat, Inc * New York > > -- Michael Kang?????? There is a giant asleep within every man. When the giant awakens,miracles happen. Personal blog: http://ufusion.org - United Fusion -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrobertm8 at yahoo.com Thu Dec 10 06:25:40 2009 From: jrobertm8 at yahoo.com (John Robert Mendoza) Date: Thu, 10 Dec 2009 14:25:40 +0800 (SGT) Subject: [Freeipa-users] freeipa replication Message-ID: <418948.29655.qm@web76315.mail.sg1.yahoo.com> Hi Rob, Just want to know if there is an issue with the replication mechanism of FreeIPA. I have installed my own self-signed certificate for use with IPA and I can't get my replica installation going.? I also tried replicating using the default certificate included but I can't push through.? TIA. John Robert Mendoza -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Dec 10 14:22:51 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Dec 2009 09:22:51 -0500 Subject: [Freeipa-users] freeipa replication In-Reply-To: <418948.29655.qm@web76315.mail.sg1.yahoo.com> References: <418948.29655.qm@web76315.mail.sg1.yahoo.com> Message-ID: <4B21043B.5040702@redhat.com> John Robert Mendoza wrote: > Hi Rob, > > Just want to know if there is an issue with the replication mechanism of > FreeIPA. > > I have installed my own self-signed certificate for use with IPA and I > can't get my replica installation going. I also tried replicating using > the default certificate included but I can't push through. > > TIA. > > John Robert Mendoza I'm not aware of any problems. What version are you using and what distribution? Are you getting any error messages? rob From jrobertm8 at yahoo.com Fri Dec 11 07:35:15 2009 From: jrobertm8 at yahoo.com (John Robert Mendoza) Date: Fri, 11 Dec 2009 15:35:15 +0800 (SGT) Subject: [Freeipa-users] freeipa replication In-Reply-To: <4B21043B.5040702@redhat.com> Message-ID: <307143.99436.qm@web76301.mail.sg1.yahoo.com> Rob, I'm using freeipa 1.2.2 on a fedora 11 machine. I have successfully configured it for authentication for our services but the lack of replication makes it vulnerable for unavailability and downtime.? It's complaining about the replica server not being able to contact the ldap server. This can be reproduced by: 1. Clean install fedora 11 2. Install the ipa packages 3. Clean install fedora 11 on a "replica" server 4. Install the ipa packages 5. ipa-replica-prepare on the freeipa server 6. ipa-replica-install on the replica note: both machines have DNS records. TIA John Robert Mendoza --- On Thu, 12/10/09, Rob Crittenden wrote: From: Rob Crittenden Subject: Re: [Freeipa-users] freeipa replication To: "John Robert Mendoza" Cc: "freeipa-users" Date: Thursday, 10 December, 2009, 10:22 PM John Robert Mendoza wrote: > Hi Rob, > > Just want to know if there is an issue with the replication mechanism of FreeIPA. > > I have installed my own self-signed certificate for use with IPA and I can't get my replica installation going.? I also tried replicating using the default certificate included but I can't push through. > TIA. > > John Robert Mendoza I'm not aware of any problems. What version are you using and what distribution? Are you getting any error messages? rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From vic_1980 at bk.ru Fri Dec 11 14:06:51 2009 From: vic_1980 at bk.ru (=?koi8-r?Q?=F7=C9=CB=D4=CF=D2_?= =?koi8-r?Q?=F3=C5=D2=C7=C5=C5=D7=C9=DE?=) Date: Fri, 11 Dec 2009 17:06:51 +0300 Subject: [Freeipa-users] freeIPA replication Message-ID: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> Hello! I'am using freeIPA on fedora 9 - Master server, on replica fedora 11. after ipa-replica-install on fedora 11 I'm try to start dirsrv and see next message: KBTM-SPB-RU...[11/Dec/2009:16:30:56 +0300] dse - The entry cn=schema in file /etc/dirsrv/slapd-KBTM-SPB-RU/schema/99user.ldif is invalid, error code 21 (Invalid syntax) - object class nsAIMpresence: Unknown allowed attribute type "nsaimstatusgraphic" [11/Dec/2009:16:30:56 +0300] dse - Please edit the file to correct the reported problems and then restart the server. Thanks From rmeggins at redhat.com Fri Dec 11 15:23:48 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 11 Dec 2009 08:23:48 -0700 Subject: [Freeipa-users] freeIPA replication In-Reply-To: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> References: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> Message-ID: <4B226404.2090108@redhat.com> ?????? ????????? wrote: > Hello! > > I'am using freeIPA on fedora 9 - Master server, on replica fedora 11. > > after ipa-replica-install on fedora 11 I'm try to start dirsrv and see > next message: > > KBTM-SPB-RU...[11/Dec/2009:16:30:56 +0300] dse - The entry cn=schema in > file /etc/dirsrv/slapd-KBTM-SPB-RU/schema/99user.ldif is invalid, error > code 21 (Invalid syntax) - object class nsAIMpresence: Unknown allowed > attribute type "nsaimstatusgraphic" > [11/Dec/2009:16:30:56 +0300] dse - Please edit the file to correct the > reported problems and then restart the server. > what version of 389-ds-base? rpm -qi 389-ds-base > Thanks > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From vic_1980 at bk.ru Fri Dec 11 16:07:26 2009 From: vic_1980 at bk.ru (=?koi8-r?Q?=F7=C9=CB=D4=CF=D2_?= =?koi8-r?Q?=F3=C5=D2=C7=C5=C5=D7=C9=DE?=) Date: Fri, 11 Dec 2009 19:07:26 +0300 Subject: [Freeipa-users] freeIPA replication In-Reply-To: <4B226404.2090108@redhat.com> References: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> <4B226404.2090108@redhat.com> Message-ID: <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> On fedora 11: Name : 389-ds-base Relocations: (not relocatable) Version : 1.2.2 Vendor: Fedora Project Release : 1.fc11 Build Date: Wed 26 Aug 2009 12:07:44 AM MSD Install Date: Fri 11 Dec 2009 10:46:32 AM MSK Build Host: x86-1.fedora.phx.redhat.com Group : System Environment/Daemons Source RPM: 389-ds-base-1.2.2-1.fc11.src.rpm Size : 5080205 License: GPLv2 with exceptions Signature : RSA/SHA1, Wed 26 Aug 2009 04:34:33 PM MSD, Key ID 1dc5c758d22e77f2 Packager : Fedora Project URL : http://port389.org/ Summary : 389 Directory Server (base) ? ???, 11/12/2009 ? 08:23 -0700, Rich Megginson ?????: > ?????? ????????? wrote: > > Hello! > > > > I'am using freeIPA on fedora 9 - Master server, on replica fedora 11. > > > > after ipa-replica-install on fedora 11 I'm try to start dirsrv and see > > next message: > > > > KBTM-SPB-RU...[11/Dec/2009:16:30:56 +0300] dse - The entry cn=schema in > > file /etc/dirsrv/slapd-KBTM-SPB-RU/schema/99user.ldif is invalid, error > > code 21 (Invalid syntax) - object class nsAIMpresence: Unknown allowed > > attribute type "nsaimstatusgraphic" > > [11/Dec/2009:16:30:56 +0300] dse - Please edit the file to correct the > > reported problems and then restart the server. > > > what version of 389-ds-base? rpm -qi 389-ds-base > > Thanks > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > From rmeggins at redhat.com Fri Dec 11 17:55:49 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 11 Dec 2009 10:55:49 -0700 Subject: [Freeipa-users] freeIPA replication In-Reply-To: <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> References: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> <4B226404.2090108@redhat.com> <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> Message-ID: <4B2287A5.30106@redhat.com> ?????? ????????? wrote: > On fedora 11: > > Name : 389-ds-base Relocations: (not > relocatable) > Version : 1.2.2 Vendor: Fedora Project > Release : 1.fc11 Build Date: Wed 26 Aug 2009 > 12:07:44 AM MSD > Install Date: Fri 11 Dec 2009 10:46:32 AM MSK Build Host: > x86-1.fedora.phx.redhat.com > Group : System Environment/Daemons Source RPM: > 389-ds-base-1.2.2-1.fc11.src.rpm > Size : 5080205 License: GPLv2 with > exceptions > Signature : RSA/SHA1, Wed 26 Aug 2009 04:34:33 PM MSD, Key ID > 1dc5c758d22e77f2 > Packager : Fedora Project > URL : http://port389.org/ > Summary : 389 Directory Server (base) > Was this an upgrade from an earlier installation? > ? ???, 11/12/2009 ? 08:23 -0700, Rich Megginson ?????: > >> ?????? ????????? wrote: >> >>> Hello! >>> >>> I'am using freeIPA on fedora 9 - Master server, on replica fedora 11. >>> >>> after ipa-replica-install on fedora 11 I'm try to start dirsrv and see >>> next message: >>> >>> KBTM-SPB-RU...[11/Dec/2009:16:30:56 +0300] dse - The entry cn=schema in >>> file /etc/dirsrv/slapd-KBTM-SPB-RU/schema/99user.ldif is invalid, error >>> code 21 (Invalid syntax) - object class nsAIMpresence: Unknown allowed >>> attribute type "nsaimstatusgraphic" >>> [11/Dec/2009:16:30:56 +0300] dse - Please edit the file to correct the >>> reported problems and then restart the server. >>> >>> >> what version of 389-ds-base? rpm -qi 389-ds-base >> >>> Thanks >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From rcritten at redhat.com Fri Dec 11 18:50:44 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Dec 2009 13:50:44 -0500 Subject: [Freeipa-users] freeipa replication In-Reply-To: <307143.99436.qm@web76301.mail.sg1.yahoo.com> References: <307143.99436.qm@web76301.mail.sg1.yahoo.com> Message-ID: <4B229484.10904@redhat.com> John Robert Mendoza wrote: > Rob, > > I'm using freeipa 1.2.2 on a fedora 11 machine. I have successfully > configured it for authentication for our services but the lack of > replication makes it vulnerable for unavailability and downtime. > > It's complaining about the replica server not being able to contact the > ldap server. > > This can be reproduced by: > > 1. Clean install fedora 11 > 2. Install the ipa packages > 3. Clean install fedora 11 on a "replica" server > 4. Install the ipa packages > 5. ipa-replica-prepare on the freeipa server > 6. ipa-replica-install on the replica > > note: both machines have DNS records. > > TIA > Ok, strange. On the replica server can you do something like: % ldapsearch -x -h ipa.example.com -p 389 -b "dc=example,dc=com" uid=admin That will confirm that the ports are available. Can you provide the ipareplica-install.log? rob From rcritten at redhat.com Fri Dec 11 18:55:33 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Dec 2009 13:55:33 -0500 Subject: [Freeipa-users] freeIPA replication In-Reply-To: <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> References: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> <4B226404.2090108@redhat.com> <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> Message-ID: <4B2295A5.1020809@redhat.com> ?????? ????????? wrote: > On fedora 11: > > Name : 389-ds-base Relocations: (not > relocatable) > Version : 1.2.2 Vendor: Fedora Project > Release : 1.fc11 Build Date: Wed 26 Aug 2009 > 12:07:44 AM MSD > Install Date: Fri 11 Dec 2009 10:46:32 AM MSK Build Host: > x86-1.fedora.phx.redhat.com > Group : System Environment/Daemons Source RPM: > 389-ds-base-1.2.2-1.fc11.src.rpm > Size : 5080205 License: GPLv2 with > exceptions > Signature : RSA/SHA1, Wed 26 Aug 2009 04:34:33 PM MSD, Key ID > 1dc5c758d22e77f2 > Packager : Fedora Project > URL : http://port389.org/ > Summary : 389 Directory Server (base) > IIRC in 389-ds 1.2.2 some schema was dropped/modified. If you try to replicate between < 1.2.2 and >= 1.2.2 you can get this error because the schema isn't defined on one side. I'm not sure the best way to work around this. Options include: - sync up the 389-ds versions between your servers. This would likely require building your own set of rpms on one or the other. - add the missing schema to the F-11 server in /etc/dirsrv/schema. This has the downside that you'll probably end up broken in other very odd some time way into the future. - modify 99user.ldif on the replicated system and remove the offending attributes. At the point in the replica installation where this fails the installer is almost done. The only missing steps are the DNS configuration and configuring the client. There may be other options, and again I'm not sure which is the best at this point. Rich, what do you think? rob From rmeggins at redhat.com Fri Dec 11 19:33:28 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 11 Dec 2009 12:33:28 -0700 Subject: [Freeipa-users] freeIPA replication In-Reply-To: <4B2295A5.1020809@redhat.com> References: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> <4B226404.2090108@redhat.com> <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> <4B2295A5.1020809@redhat.com> Message-ID: <4B229E88.4000801@redhat.com> Rob Crittenden wrote: > ?????? ????????? wrote: >> On fedora 11: >> >> Name : 389-ds-base Relocations: (not >> relocatable) >> Version : 1.2.2 Vendor: Fedora Project >> Release : 1.fc11 Build Date: Wed 26 Aug 2009 >> 12:07:44 AM MSD >> Install Date: Fri 11 Dec 2009 10:46:32 AM MSK Build Host: >> x86-1.fedora.phx.redhat.com >> Group : System Environment/Daemons Source RPM: >> 389-ds-base-1.2.2-1.fc11.src.rpm >> Size : 5080205 License: GPLv2 with >> exceptions >> Signature : RSA/SHA1, Wed 26 Aug 2009 04:34:33 PM MSD, Key ID >> 1dc5c758d22e77f2 >> Packager : Fedora Project >> URL : http://port389.org/ >> Summary : 389 Directory Server (base) >> > > IIRC in 389-ds 1.2.2 some schema was dropped/modified. If you try to > replicate between < 1.2.2 and >= 1.2.2 you can get this error because > the schema isn't defined on one side. > > I'm not sure the best way to work around this. Options include: > > - sync up the 389-ds versions between your servers. This would likely > require building your own set of rpms on one or the other. > - add the missing schema to the F-11 server in /etc/dirsrv/schema. > This has the downside that you'll probably end up broken in other very > odd some time way into the future. > - modify 99user.ldif on the replicated system and remove the offending > attributes. At the point in the replica installation where this fails > the installer is almost done. The only missing steps are the DNS > configuration and configuring the client. > > There may be other options, and again I'm not sure which is the best > at this point. Rich, what do you think? With 389-ds-base 1.2.3 and later (1.2.5.rc2 is currently available from the testing repos) 99user.ldif is fixed to remove the offending schema upon upgrade (yum or rpm), or by doing setup-ds.pl -u. > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From james.roman at ssaihq.com Fri Dec 11 20:05:21 2009 From: james.roman at ssaihq.com (James Roman) Date: Fri, 11 Dec 2009 15:05:21 -0500 Subject: [Freeipa-users] freeIPA replication In-Reply-To: <4B229E88.4000801@redhat.com> References: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> <4B226404.2090108@redhat.com> <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> <4B2295A5.1020809@redhat.com> <4B229E88.4000801@redhat.com> Message-ID: <4B22A601.6050400@ssaihq.com> If I remember correctly, I had to comment out the following entries in the /etc/dirsrv/slapd-XXXX/schema/99user.ldif file: # objectClasses: ( 2.16.840.1.113730.3.2.300 NAME 'nsAIMpresence' DESC 'Netscape defined objectclass' SUP top AUXILIARY MAY (nsaimid $ nsaimstatusgraphic $ nsaimstatustext ) X-ORIGIN ( 'Netscape Directory Server' 'user defined' ) ) # objectClasses: ( 2.16.840.1.113730.3.2.301 NAME 'nsICQpresence' DESC 'Netscape defined objectclass' SUP top AUXILIARY MAY ( nsicqid $ nsicqstatusgraphic $ nsICQStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user defined' ) ) # objectClasses: ( 2.16.840.1.113730.3.2.302 NAME 'nsYIMpresence' DESC 'Netscape defined objectclass' SUP top AUXILIARY MAY ( nsyimid $ nsyimstatusgraphic $ nsYIMStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user defined' ) ) # objectClasses: ( 2.16.840.1.113730.3.2.303 NAME 'nsMSNpresence' DESC 'Netscape defined objectclass' SUP top AUXILIARY MAY nsmsnid X-ORIGIN ( 'Netscape Dir ectory Server' 'user defined' ) ) Rich Megginson wrote: > Rob Crittenden wrote: >> ?????? ????????? wrote: >>> On fedora 11: >>> >>> Name : 389-ds-base Relocations: (not >>> relocatable) >>> Version : 1.2.2 Vendor: Fedora Project >>> Release : 1.fc11 Build Date: Wed 26 Aug 2009 >>> 12:07:44 AM MSD >>> Install Date: Fri 11 Dec 2009 10:46:32 AM MSK Build Host: >>> x86-1.fedora.phx.redhat.com >>> Group : System Environment/Daemons Source RPM: >>> 389-ds-base-1.2.2-1.fc11.src.rpm >>> Size : 5080205 License: GPLv2 with >>> exceptions >>> Signature : RSA/SHA1, Wed 26 Aug 2009 04:34:33 PM MSD, Key ID >>> 1dc5c758d22e77f2 >>> Packager : Fedora Project >>> URL : http://port389.org/ >>> Summary : 389 Directory Server (base) >>> >> >> IIRC in 389-ds 1.2.2 some schema was dropped/modified. If you try to >> replicate between < 1.2.2 and >= 1.2.2 you can get this error because >> the schema isn't defined on one side. >> >> I'm not sure the best way to work around this. Options include: >> >> - sync up the 389-ds versions between your servers. This would likely >> require building your own set of rpms on one or the other. >> - add the missing schema to the F-11 server in /etc/dirsrv/schema. >> This has the downside that you'll probably end up broken in other >> very odd some time way into the future. >> - modify 99user.ldif on the replicated system and remove the >> offending attributes. At the point in the replica installation where >> this fails the installer is almost done. The only missing steps are >> the DNS configuration and configuring the client. >> >> There may be other options, and again I'm not sure which is the best >> at this point. Rich, what do you think? > With 389-ds-base 1.2.3 and later (1.2.5.rc2 is currently available > from the testing repos) 99user.ldif is fixed to remove the offending > schema upon upgrade (yum or rpm), or by doing setup-ds.pl -u. >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rmeggins at redhat.com Fri Dec 11 20:07:45 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 11 Dec 2009 13:07:45 -0700 Subject: [Freeipa-users] freeIPA replication In-Reply-To: <4B22A601.6050400@ssaihq.com> References: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> <4B226404.2090108@redhat.com> <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> <4B2295A5.1020809@redhat.com> <4B229E88.4000801@redhat.com> <4B22A601.6050400@ssaihq.com> Message-ID: <4B22A691.504@redhat.com> James Roman wrote: > If I remember correctly, I had to comment out the following entries in > the /etc/dirsrv/slapd-XXXX/schema/99user.ldif file: > > # objectClasses: ( 2.16.840.1.113730.3.2.300 NAME 'nsAIMpresence' DESC > 'Netscape > defined objectclass' SUP top AUXILIARY MAY (nsaimid $ > nsaimstatusgraphic $ > nsaimstatustext ) X-ORIGIN ( 'Netscape Directory Server' 'user > defined' ) ) > # objectClasses: ( 2.16.840.1.113730.3.2.301 NAME 'nsICQpresence' DESC > 'Netscape > defined objectclass' SUP top AUXILIARY MAY ( nsicqid $ > nsicqstatusgraphic $ > nsICQStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user > defined' ) ) > # objectClasses: ( 2.16.840.1.113730.3.2.302 NAME 'nsYIMpresence' DESC > 'Netscape > defined objectclass' SUP top AUXILIARY MAY ( nsyimid $ > nsyimstatusgraphic $ > nsYIMStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user > defined' ) ) > # objectClasses: ( 2.16.840.1.113730.3.2.303 NAME 'nsMSNpresence' DESC > 'Netscape > defined objectclass' SUP top AUXILIARY MAY nsmsnid X-ORIGIN ( > 'Netscape Dir > ectory Server' 'user defined' ) ) > That should work. The problem is that these schema should never have been in 99user.ldif in the first place. The code has been fixed so that standard schema such as these will not be copied to 99user.ldif, and setup-ds.pl -u in 389-ds-base 1.2.3 and later will clean up 99user.ldif of these and other bogus schema. > > > Rich Megginson wrote: >> Rob Crittenden wrote: >>> ?????? ????????? wrote: >>>> On fedora 11: >>>> >>>> Name : 389-ds-base Relocations: (not >>>> relocatable) >>>> Version : 1.2.2 Vendor: Fedora Project >>>> Release : 1.fc11 Build Date: Wed 26 Aug >>>> 2009 >>>> 12:07:44 AM MSD >>>> Install Date: Fri 11 Dec 2009 10:46:32 AM MSK Build Host: >>>> x86-1.fedora.phx.redhat.com >>>> Group : System Environment/Daemons Source RPM: >>>> 389-ds-base-1.2.2-1.fc11.src.rpm >>>> Size : 5080205 License: GPLv2 with >>>> exceptions >>>> Signature : RSA/SHA1, Wed 26 Aug 2009 04:34:33 PM MSD, Key ID >>>> 1dc5c758d22e77f2 >>>> Packager : Fedora Project >>>> URL : http://port389.org/ >>>> Summary : 389 Directory Server (base) >>>> >>> >>> IIRC in 389-ds 1.2.2 some schema was dropped/modified. If you try to >>> replicate between < 1.2.2 and >= 1.2.2 you can get this error >>> because the schema isn't defined on one side. >>> >>> I'm not sure the best way to work around this. Options include: >>> >>> - sync up the 389-ds versions between your servers. This would >>> likely require building your own set of rpms on one or the other. >>> - add the missing schema to the F-11 server in /etc/dirsrv/schema. >>> This has the downside that you'll probably end up broken in other >>> very odd some time way into the future. >>> - modify 99user.ldif on the replicated system and remove the >>> offending attributes. At the point in the replica installation where >>> this fails the installer is almost done. The only missing steps are >>> the DNS configuration and configuring the client. >>> >>> There may be other options, and again I'm not sure which is the best >>> at this point. Rich, what do you think? >> With 389-ds-base 1.2.3 and later (1.2.5.rc2 is currently available >> from the testing repos) 99user.ldif is fixed to remove the offending >> schema upon upgrade (yum or rpm), or by doing setup-ds.pl -u. >>> >>> rob >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > From vic_1980 at bk.ru Sat Dec 12 11:46:31 2009 From: vic_1980 at bk.ru (=?koi8-r?Q?=F7=C9=CB=D4=CF=D2_?= =?koi8-r?Q?=F3=C5=D2=C7=C5=C5=D7=C9=DE?=) Date: Sat, 12 Dec 2009 14:46:31 +0300 Subject: [Freeipa-users] freeIPA replication In-Reply-To: <4B22A691.504@redhat.com> References: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> <4B226404.2090108@redhat.com> <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> <4B2295A5.1020809@redhat.com> <4B229E88.4000801@redhat.com> <4B22A601.6050400@ssaihq.com> <4B22A691.504@redhat.com> Message-ID: <1260618391.2533.210.camel@n51vf.kbtm-spb.ru> I can understand, I have to update oldest version of freeIPA, but I can't do that, before I'm have tested reserve server because now master-server have records about 200 users are stored and problems as a result of updatings are inadmissible. If i'm understand wright, I have to comment some lines and repeat procedure replication? ? ???, 11/12/2009 ? 13:07 -0700, Rich Megginson ?????: > James Roman wrote: > > If I remember correctly, I had to comment out the following entries in > > the /etc/dirsrv/slapd-XXXX/schema/99user.ldif file: > > > > # objectClasses: ( 2.16.840.1.113730.3.2.300 NAME 'nsAIMpresence' DESC > > 'Netscape > > defined objectclass' SUP top AUXILIARY MAY (nsaimid $ > > nsaimstatusgraphic $ > > nsaimstatustext ) X-ORIGIN ( 'Netscape Directory Server' 'user > > defined' ) ) > > # objectClasses: ( 2.16.840.1.113730.3.2.301 NAME 'nsICQpresence' DESC > > 'Netscape > > defined objectclass' SUP top AUXILIARY MAY ( nsicqid $ > > nsicqstatusgraphic $ > > nsICQStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user > > defined' ) ) > > # objectClasses: ( 2.16.840.1.113730.3.2.302 NAME 'nsYIMpresence' DESC > > 'Netscape > > defined objectclass' SUP top AUXILIARY MAY ( nsyimid $ > > nsyimstatusgraphic $ > > nsYIMStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user > > defined' ) ) > > # objectClasses: ( 2.16.840.1.113730.3.2.303 NAME 'nsMSNpresence' DESC > > 'Netscape > > defined objectclass' SUP top AUXILIARY MAY nsmsnid X-ORIGIN ( > > 'Netscape Dir > > ectory Server' 'user defined' ) ) > > > That should work. The problem is that these schema should never have > been in 99user.ldif in the first place. The code has been fixed so that > standard schema such as these will not be copied to 99user.ldif, and > setup-ds.pl -u in 389-ds-base 1.2.3 and later will clean up 99user.ldif > of these and other bogus schema. > > > > > > Rich Megginson wrote: > >> Rob Crittenden wrote: > >>> ?????? ????????? wrote: > >>>> On fedora 11: > >>>> > >>>> Name : 389-ds-base Relocations: (not > >>>> relocatable) > >>>> Version : 1.2.2 Vendor: Fedora Project > >>>> Release : 1.fc11 Build Date: Wed 26 Aug > >>>> 2009 > >>>> 12:07:44 AM MSD > >>>> Install Date: Fri 11 Dec 2009 10:46:32 AM MSK Build Host: > >>>> x86-1.fedora.phx.redhat.com > >>>> Group : System Environment/Daemons Source RPM: > >>>> 389-ds-base-1.2.2-1.fc11.src.rpm > >>>> Size : 5080205 License: GPLv2 with > >>>> exceptions > >>>> Signature : RSA/SHA1, Wed 26 Aug 2009 04:34:33 PM MSD, Key ID > >>>> 1dc5c758d22e77f2 > >>>> Packager : Fedora Project > >>>> URL : http://port389.org/ > >>>> Summary : 389 Directory Server (base) > >>>> > >>> > >>> IIRC in 389-ds 1.2.2 some schema was dropped/modified. If you try to > >>> replicate between < 1.2.2 and >= 1.2.2 you can get this error > >>> because the schema isn't defined on one side. > >>> > >>> I'm not sure the best way to work around this. Options include: > >>> > >>> - sync up the 389-ds versions between your servers. This would > >>> likely require building your own set of rpms on one or the other. > >>> - add the missing schema to the F-11 server in /etc/dirsrv/schema. > >>> This has the downside that you'll probably end up broken in other > >>> very odd some time way into the future. > >>> - modify 99user.ldif on the replicated system and remove the > >>> offending attributes. At the point in the replica installation where > >>> this fails the installer is almost done. The only missing steps are > >>> the DNS configuration and configuring the client. > >>> > >>> There may be other options, and again I'm not sure which is the best > >>> at this point. Rich, what do you think? > >> With 389-ds-base 1.2.3 and later (1.2.5.rc2 is currently available > >> from the testing repos) 99user.ldif is fixed to remove the offending > >> schema upon upgrade (yum or rpm), or by doing setup-ds.pl -u. > >>> > >>> rob > >>> From papichulo98jose at yahoo.com Sat Dec 12 05:50:03 2009 From: papichulo98jose at yahoo.com (jose mora) Date: Fri, 11 Dec 2009 21:50:03 -0800 (PST) Subject: [Freeipa-users] deploying FreeIPA Message-ID: <121398.73611.qm@web112520.mail.gq1.yahoo.com> hello how is everyone doing? I do have a request, can you help me Deploying FreeIPA? I would apreciate any kind of help thank you for your time Jose Mora -------------- next part -------------- An HTML attachment was scrubbed... URL: From vic_1980 at bk.ru Mon Dec 14 08:25:13 2009 From: vic_1980 at bk.ru (=?koi8-r?Q?=F7=C9=CB=D4=CF=D2_?= =?koi8-r?Q?=F3=C5=D2=C7=C5=C5=D7=C9=DE?=) Date: Mon, 14 Dec 2009 11:25:13 +0300 Subject: [Freeipa-users] freeIPA replication In-Reply-To: <4B22A691.504@redhat.com> References: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> <4B226404.2090108@redhat.com> <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> <4B2295A5.1020809@redhat.com> <4B229E88.4000801@redhat.com> <4B22A601.6050400@ssaihq.com> <4B22A691.504@redhat.com> Message-ID: <1260779113.2655.11.camel@n51vf.kbtm-spb.ru> Hi! Thanks! It works!, but In master-server I'm see users in groups, but in replica I'm see only group, without users. If search users - i'm can find it. And one more: If I write users (Firsname and/ore lastname)in cyrillic symbols (russian language), save this user and try find it - I'm see "500 - internal server error. An unexpected error occured." Prompt please - as with it it is possible to consult how Thanks ? ???, 11/12/2009 ? 13:07 -0700, Rich Megginson ?????: > James Roman wrote: > > If I remember correctly, I had to comment out the following entries in > > the /etc/dirsrv/slapd-XXXX/schema/99user.ldif file: > > > > # objectClasses: ( 2.16.840.1.113730.3.2.300 NAME 'nsAIMpresence' DESC > > 'Netscape > > defined objectclass' SUP top AUXILIARY MAY (nsaimid $ > > nsaimstatusgraphic $ > > nsaimstatustext ) X-ORIGIN ( 'Netscape Directory Server' 'user > > defined' ) ) > > # objectClasses: ( 2.16.840.1.113730.3.2.301 NAME 'nsICQpresence' DESC > > 'Netscape > > defined objectclass' SUP top AUXILIARY MAY ( nsicqid $ > > nsicqstatusgraphic $ > > nsICQStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user > > defined' ) ) > > # objectClasses: ( 2.16.840.1.113730.3.2.302 NAME 'nsYIMpresence' DESC > > 'Netscape > > defined objectclass' SUP top AUXILIARY MAY ( nsyimid $ > > nsyimstatusgraphic $ > > nsYIMStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user > > defined' ) ) > > # objectClasses: ( 2.16.840.1.113730.3.2.303 NAME 'nsMSNpresence' DESC > > 'Netscape > > defined objectclass' SUP top AUXILIARY MAY nsmsnid X-ORIGIN ( > > 'Netscape Dir > > ectory Server' 'user defined' ) ) > > > That should work. The problem is that these schema should never have > been in 99user.ldif in the first place. The code has been fixed so that > standard schema such as these will not be copied to 99user.ldif, and > setup-ds.pl -u in 389-ds-base 1.2.3 and later will clean up 99user.ldif > of these and other bogus schema. > > > > > > Rich Megginson wrote: > >> Rob Crittenden wrote: > >>> ?????? ????????? wrote: > >>>> On fedora 11: > >>>> > >>>> Name : 389-ds-base Relocations: (not > >>>> relocatable) > >>>> Version : 1.2.2 Vendor: Fedora Project > >>>> Release : 1.fc11 Build Date: Wed 26 Aug > >>>> 2009 > >>>> 12:07:44 AM MSD > >>>> Install Date: Fri 11 Dec 2009 10:46:32 AM MSK Build Host: > >>>> x86-1.fedora.phx.redhat.com > >>>> Group : System Environment/Daemons Source RPM: > >>>> 389-ds-base-1.2.2-1.fc11.src.rpm > >>>> Size : 5080205 License: GPLv2 with > >>>> exceptions > >>>> Signature : RSA/SHA1, Wed 26 Aug 2009 04:34:33 PM MSD, Key ID > >>>> 1dc5c758d22e77f2 > >>>> Packager : Fedora Project > >>>> URL : http://port389.org/ > >>>> Summary : 389 Directory Server (base) > >>>> > >>> > >>> IIRC in 389-ds 1.2.2 some schema was dropped/modified. If you try to > >>> replicate between < 1.2.2 and >= 1.2.2 you can get this error > >>> because the schema isn't defined on one side. > >>> > >>> I'm not sure the best way to work around this. Options include: > >>> > >>> - sync up the 389-ds versions between your servers. This would > >>> likely require building your own set of rpms on one or the other. > >>> - add the missing schema to the F-11 server in /etc/dirsrv/schema. > >>> This has the downside that you'll probably end up broken in other > >>> very odd some time way into the future. > >>> - modify 99user.ldif on the replicated system and remove the > >>> offending attributes. At the point in the replica installation where > >>> this fails the installer is almost done. The only missing steps are > >>> the DNS configuration and configuring the client. > >>> > >>> There may be other options, and again I'm not sure which is the best > >>> at this point. Rich, what do you think? > >> With 389-ds-base 1.2.3 and later (1.2.5.rc2 is currently available > >> from the testing repos) 99user.ldif is fixed to remove the offending > >> schema upon upgrade (yum or rpm), or by doing setup-ds.pl -u. > >>> > >>> rob > >>> > >>> _______________________________________________ > >>> 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 > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From rcritten at redhat.com Mon Dec 14 16:06:56 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Dec 2009 11:06:56 -0500 Subject: [Freeipa-users] freeIPA replication In-Reply-To: <1260779113.2655.11.camel@n51vf.kbtm-spb.ru> References: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> <4B226404.2090108@redhat.com> <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> <4B2295A5.1020809@redhat.com> <4B229E88.4000801@redhat.com> <4B22A601.6050400@ssaihq.com> <4B22A691.504@redhat.com> <1260779113.2655.11.camel@n51vf.kbtm-spb.ru> Message-ID: <4B2662A0.6010902@redhat.com> ?????? ????????? wrote: > Hi! > > Thanks! It works!, but > In master-server I'm see users in groups, but in replica I'm see only > group, without users. If search users - i'm can find it. And one more: Strange, that shouldn't happen. I'd search for them directly in LDAP to ensure it isn't a problem with the IPA management framework: % ldapsearch -x -b "cn=users,cn=accounts,dc=example,dc=com" "(objectclass=posixuser") uid > If I write users (Firsname and/ore lastname)in cyrillic symbols (russian > language), save this user and try find it - I'm see "500 - internal > server error. An unexpected error occured." > Prompt please - as with it it is possible to consult how This is a known problem (https://bugzilla.redhat.com/show_bug.cgi?id=490285). IPA v1 only supports the ASCII character set currently. rob > > Thanks > > ? ???, 11/12/2009 ? 13:07 -0700, Rich Megginson ?????: >> James Roman wrote: >>> If I remember correctly, I had to comment out the following entries in >>> the /etc/dirsrv/slapd-XXXX/schema/99user.ldif file: >>> >>> # objectClasses: ( 2.16.840.1.113730.3.2.300 NAME 'nsAIMpresence' DESC >>> 'Netscape >>> defined objectclass' SUP top AUXILIARY MAY (nsaimid $ >>> nsaimstatusgraphic $ >>> nsaimstatustext ) X-ORIGIN ( 'Netscape Directory Server' 'user >>> defined' ) ) >>> # objectClasses: ( 2.16.840.1.113730.3.2.301 NAME 'nsICQpresence' DESC >>> 'Netscape >>> defined objectclass' SUP top AUXILIARY MAY ( nsicqid $ >>> nsicqstatusgraphic $ >>> nsICQStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user >>> defined' ) ) >>> # objectClasses: ( 2.16.840.1.113730.3.2.302 NAME 'nsYIMpresence' DESC >>> 'Netscape >>> defined objectclass' SUP top AUXILIARY MAY ( nsyimid $ >>> nsyimstatusgraphic $ >>> nsYIMStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user >>> defined' ) ) >>> # objectClasses: ( 2.16.840.1.113730.3.2.303 NAME 'nsMSNpresence' DESC >>> 'Netscape >>> defined objectclass' SUP top AUXILIARY MAY nsmsnid X-ORIGIN ( >>> 'Netscape Dir >>> ectory Server' 'user defined' ) ) >>> >> That should work. The problem is that these schema should never have >> been in 99user.ldif in the first place. The code has been fixed so that >> standard schema such as these will not be copied to 99user.ldif, and >> setup-ds.pl -u in 389-ds-base 1.2.3 and later will clean up 99user.ldif >> of these and other bogus schema. >>> >>> Rich Megginson wrote: >>>> Rob Crittenden wrote: >>>>> ?????? ????????? wrote: >>>>>> On fedora 11: >>>>>> >>>>>> Name : 389-ds-base Relocations: (not >>>>>> relocatable) >>>>>> Version : 1.2.2 Vendor: Fedora Project >>>>>> Release : 1.fc11 Build Date: Wed 26 Aug >>>>>> 2009 >>>>>> 12:07:44 AM MSD >>>>>> Install Date: Fri 11 Dec 2009 10:46:32 AM MSK Build Host: >>>>>> x86-1.fedora.phx.redhat.com >>>>>> Group : System Environment/Daemons Source RPM: >>>>>> 389-ds-base-1.2.2-1.fc11.src.rpm >>>>>> Size : 5080205 License: GPLv2 with >>>>>> exceptions >>>>>> Signature : RSA/SHA1, Wed 26 Aug 2009 04:34:33 PM MSD, Key ID >>>>>> 1dc5c758d22e77f2 >>>>>> Packager : Fedora Project >>>>>> URL : http://port389.org/ >>>>>> Summary : 389 Directory Server (base) >>>>>> >>>>> IIRC in 389-ds 1.2.2 some schema was dropped/modified. If you try to >>>>> replicate between < 1.2.2 and >= 1.2.2 you can get this error >>>>> because the schema isn't defined on one side. >>>>> >>>>> I'm not sure the best way to work around this. Options include: >>>>> >>>>> - sync up the 389-ds versions between your servers. This would >>>>> likely require building your own set of rpms on one or the other. >>>>> - add the missing schema to the F-11 server in /etc/dirsrv/schema. >>>>> This has the downside that you'll probably end up broken in other >>>>> very odd some time way into the future. >>>>> - modify 99user.ldif on the replicated system and remove the >>>>> offending attributes. At the point in the replica installation where >>>>> this fails the installer is almost done. The only missing steps are >>>>> the DNS configuration and configuring the client. >>>>> >>>>> There may be other options, and again I'm not sure which is the best >>>>> at this point. Rich, what do you think? >>>> With 389-ds-base 1.2.3 and later (1.2.5.rc2 is currently available >>>> from the testing repos) 99user.ldif is fixed to remove the offending >>>> schema upon upgrade (yum or rpm), or by doing setup-ds.pl -u. >>>>> rob >>>>> >>>>> _______________________________________________ >>>>> 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 >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From jdennis at redhat.com Mon Dec 14 16:14:58 2009 From: jdennis at redhat.com (John Dennis) Date: Mon, 14 Dec 2009 11:14:58 -0500 Subject: [Freeipa-users] deploying FreeIPA In-Reply-To: <121398.73611.qm@web112520.mail.gq1.yahoo.com> References: <121398.73611.qm@web112520.mail.gq1.yahoo.com> Message-ID: <4B266482.7010401@redhat.com> On 12/12/2009 12:50 AM, jose mora wrote: > hello > how is everyone doing? > I do have a request, can you help me Deploying FreeIPA? > I would apreciate any kind of help > thank you for your time > Jose Mora We would like to help you but first you need to tell us what you need help with. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From james.roman at ssaihq.com Mon Dec 14 18:57:08 2009 From: james.roman at ssaihq.com (James Roman) Date: Mon, 14 Dec 2009 13:57:08 -0500 Subject: [Freeipa-users] freeIPA replication In-Reply-To: <4B2662A0.6010902@redhat.com> References: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> <4B226404.2090108@redhat.com> <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> <4B2295A5.1020809@redhat.com> <4B229E88.4000801@redhat.com> <4B22A601.6050400@ssaihq.com> <4B22A691.504@redhat.com> <1260779113.2655.11.camel@n51vf.kbtm-spb.ru> <4B2662A0.6010902@redhat.com> Message-ID: <4B268A84.70803@ssaihq.com> Rob Crittenden wrote: > ?????? ????????? wrote: >> Hi! >> Thanks! It works!, but >> In master-server I'm see users in groups, but in replica I'm see only >> group, without users. If search users - i'm can find it. And one more: > > Strange, that shouldn't happen. I'd search for them directly in LDAP > to ensure it isn't a problem with the IPA management framework: Are you sure your describing this correctly. When I built my replica, initially, I could see that groups were synchronized (I could search for groups and I could see the members), but the memberof attributes of individual user entries was not available in the replica server. These are not synchronized by default, you must enable the plug-in to generate the entries. # > ldapmodify -x -W -D "cn=Directory Manager" dn: cn=MemberOf Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on I've also seen the memberof entries disappear after performing an "ipa-replica-manage init replicaserver". This was much harder to address. I performed a lookup of the ipausers group members, stripped the entries down to just the uid and then ran then through a script that removed each entry and re-added them to the ipausers group, which forced the plug-in to recreate all memberof entries on all accounts. (Thank god I didn't have to do that on all the groups.) There are two member related plugins now a freeipa one and a 389 plugin. Not sure if they are stepping on each other or not. From rcritten at redhat.com Mon Dec 14 20:20:58 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Dec 2009 15:20:58 -0500 Subject: [Freeipa-users] freeIPA replication In-Reply-To: <4B268A84.70803@ssaihq.com> References: <1260540411.2619.31.camel@n51vf.kbtm-spb.ru> <4B226404.2090108@redhat.com> <1260547646.2619.51.camel@n51vf.kbtm-spb.ru> <4B2295A5.1020809@redhat.com> <4B229E88.4000801@redhat.com> <4B22A601.6050400@ssaihq.com> <4B22A691.504@redhat.com> <1260779113.2655.11.camel@n51vf.kbtm-spb.ru> <4B2662A0.6010902@redhat.com> <4B268A84.70803@ssaihq.com> Message-ID: <4B269E2A.4040605@redhat.com> James Roman wrote: > Rob Crittenden wrote: >> ?????? ????????? wrote: >>> Hi! >>> Thanks! It works!, but >>> In master-server I'm see users in groups, but in replica I'm see only >>> group, without users. If search users - i'm can find it. And one more: >> >> Strange, that shouldn't happen. I'd search for them directly in LDAP >> to ensure it isn't a problem with the IPA management framework: > Are you sure your describing this correctly. When I built my replica, > initially, I could see that groups were synchronized (I could search for > groups and I could see the members), but the memberof attributes of > individual user entries was not available in the replica server. These > are not synchronized by default, you must enable the plug-in to generate > the entries. Yes, I think I misread his statement. I read it as "I have groups but no users" not "I have groups that contain no users". > # > ldapmodify -x -W -D "cn=Directory Manager" > dn: cn=MemberOf Plugin,cn=plugins,cn=config > changetype: modify > replace: nsslapd-pluginEnabled > nsslapd-pluginEnabled: on > > I've also seen the memberof entries disappear after performing an > "ipa-replica-manage init replicaserver". This was much harder to > address. I performed a lookup of the ipausers group members, stripped > the entries down to just the uid and then ran then through a script that > removed each entry and re-added them to the ipausers group, which forced > the plug-in to recreate all memberof entries on all accounts. (Thank god > I didn't have to do that on all the groups.) > > There are two member related plugins now a freeipa one and a 389 plugin. > Not sure if they are stepping on each other or not. Right, the plugin was developed in IPA and moved into DS. In the next version of IPA we are dropping our plugin in favor of the DS version. You really don't want both enabled at once, who knows what problems that could cause. memberOf isn't a replicated attribute. It is built separately on each IPA server. You can force the attribute to be rebuilt by creating a DS task and using ldapmodify to apply it. Something like: # cp /usr/share/ipa/memberof-task.ldif /tmp/memberof-task.ldif [edit /tmp/memberof-task.ldif anre placed $TIME with some unique number and $SUFFIX with dc=example,ed=com as appropriate] # ldapmodify -x -D "cn=directory manager" -W < /tmp/memberof-task.ldif You'll be prompted for your DM password. This should rebuild all the local memberOf entries. rob From jrobertm8 at yahoo.com Tue Dec 15 09:55:08 2009 From: jrobertm8 at yahoo.com (John Robert Mendoza) Date: Tue, 15 Dec 2009 17:55:08 +0800 (SGT) Subject: [Freeipa-users] freeipa replication In-Reply-To: <4B229484.10904@redhat.com> Message-ID: <703002.87003.qm@web76315.mail.sg1.yahoo.com> Hi Rob, Just to let you know, I tried to again reproduce the installation. I did a clean install of Fedora 11 on a machine and updated it using yum. Then I tried to install FreeIPA on it. But strangely I had a harder time doing it.? It again outputs an error complaing about not being able to contact itself. here is the ipaserver-install log 2009-12-15 20:19:51,187 DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2009-12-15 20:19:51,196 CRITICAL Could not connect to the Directory Server on id.example.net 2009-12-15 20:19:51,204 DEBUG {'desc': "Can't contact LDAP server"} ? File "/usr/sbin/ipa-server-install", line 609, in ??? sys.exit(main()) ? File "/usr/sbin/ipa-server-install", line 509, in main ??? krb.create_instance(ds_user, realm_name, host_name, domain_name, dm_password, master_password) ? File "/usr/lib/python2.6/site-packages/ipaserver/krbinstance.py", line 135, in create_instance ??? self.__common_setup(ds_user, realm_name, host_name, domain_name, admin_password) ? File "/usr/lib/python2.6/site-packages/ipaserver/krbinstance.py", line 119, in __common_setup ??? raise e TIA. John Robert Mendoza --- On Sat, 12/12/09, Rob Crittenden wrote: From: Rob Crittenden Subject: Re: [Freeipa-users] freeipa replication To: "John Robert Mendoza" Cc: freeipa-users at redhat.com Date: Saturday, 12 December, 2009, 2:50 AM John Robert Mendoza wrote: > Rob, > > I'm using freeipa 1.2.2 on a fedora 11 machine. I have successfully configured it for authentication for our services but the lack of replication makes it vulnerable for unavailability and downtime. > It's complaining about the replica server not being able to contact the ldap server. > > This can be reproduced by: > > 1. Clean install fedora 11 > 2. Install the ipa packages > 3. Clean install fedora 11 on a "replica" server > 4. Install the ipa packages > 5. ipa-replica-prepare on the freeipa server > 6. ipa-replica-install on the replica > > note: both machines have DNS records. > > TIA > Ok, strange. On the replica server can you do something like: % ldapsearch -x -h ipa.example.com -p 389 -b "dc=example,dc=com" uid=admin That will confirm that the ports are available. Can you provide the ipareplica-install.log? rob Get connected with chat on network profile, blog, or any personal website! Yahoo! allows you to IM with Pingbox. Check it out! http://ph.messenger.yahoo.com/pingbox -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrobertm8 at yahoo.com Tue Dec 15 10:13:17 2009 From: jrobertm8 at yahoo.com (John Robert Mendoza) Date: Tue, 15 Dec 2009 18:13:17 +0800 (SGT) Subject: [Freeipa-users] freeipa replication Message-ID: <637089.67139.qm@web76301.mail.sg1.yahoo.com> I did this to install the master server. Before even making a replica. John Robert Mendoza --- On Tue, 12/15/09, John Robert Mendoza wrote: From: John Robert Mendoza Subject: Re: [Freeipa-users] freeipa replication To: "Rob Crittenden" Cc: freeipa-users at redhat.com Date: Tuesday, 15 December, 2009, 5:55 PM Hi Rob, Just to let you know, I tried to again reproduce the installation. I did a clean install of Fedora 11 on a machine and updated it using yum. Then I tried to install FreeIPA on it. But strangely I had a harder time doing it.? It again outputs an error complaing about not being able to contact itself. here is the ipaserver-install log 2009-12-15 20:19:51,187 DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2009-12-15 20:19:51,196 CRITICAL Could not connect to the Directory Server on id.example.net 2009-12-15 20:19:51,204 DEBUG {'desc': "Can't contact LDAP server"} ? File "/usr/sbin/ipa-server-install", line 609, in ??? sys.exit(main()) ? File "/usr/sbin/ipa-server-install", line 509, in main ??? krb.create_instance(ds_user, realm_name, host_name, domain_name, dm_password, master_password) ? File "/usr/lib/python2.6/site-packages/ipaserver/krbinstance.py", line 135, in create_instance ??? self.__common_setup(ds_user, realm_name, host_name, domain_name, admin_password) ? File "/usr/lib/python2.6/site-packages/ipaserver/krbinstance.py", line 119, in __common_setup ??? raise e TIA. John Robert Mendoza --- On Sat, 12/12/09, Rob Crittenden wrote: From: Rob Crittenden Subject: Re: [Freeipa-users] freeipa replication To: "John Robert Mendoza" Cc: freeipa-users at redhat.com Date: Saturday, 12 December, 2009, 2:50 AM John Robert Mendoza wrote: > Rob, > > I'm using freeipa 1.2.2 on a fedora 11 machine. I have successfully configured it for authentication for our services but the lack of replication makes it vulnerable for unavailability and downtime. > It's complaining about the replica server not being able to contact the ldap server. > > This can be reproduced by: > > 1. Clean install fedora 11 > 2. Install the ipa packages > 3. Clean install fedora 11 on a "replica" server > 4. Install the ipa packages > 5. ipa-replica-prepare on the freeipa server > 6. ipa-replica-install on the replica > > note: both machines have DNS records. > > TIA > Ok, strange. On the replica server can you do something like: % ldapsearch -x -h ipa.example.com -p 389 -b "dc=example,dc=com" uid=admin That will confirm that the ports are available. Can you provide the ipareplica-install.log? rob Surf faster. Internet Explorer 8 optmized for Yahoo! auto launches 2 of your favorite pages everytime you open your browser.Get IE8 here! (It's free) "Try the new FASTER Yahoo! Mail. Experience it today at http://ph.mail.yahoo.com" -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Dec 15 17:22:58 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Dec 2009 12:22:58 -0500 Subject: [Freeipa-users] freeIPA wiki status Message-ID: <4B27C5F2.4040501@redhat.com> The machine hosting the freeIPA wiki was moved to a new datacenter this weekend. The move was successful and the machine is up and operating, the problem is that DNS hasn't been updated to reflect the new IP address. We are working on resolving this but at this time have no ETA on when that will be. We apologize for any inconvenience. rob From danieljamesscott at gmail.com Fri Dec 18 17:31:44 2009 From: danieljamesscott at gmail.com (Dan Scott) Date: Fri, 18 Dec 2009 12:31:44 -0500 Subject: [Freeipa-users] Cross realm authentication Message-ID: <6835906b0912180931w176a1467habc3850d1bc1ec00@mail.gmail.com> Hi, Is there any documentation for adding cross realm authentication with FreeIPA? I have two FreeIPA realms: A.EXAMPLE.COM C.B.EXAMPLE.COM Following the Fedora krb5-server documentation: http://docs.fedoraproject.org/security-guide/f11/en-US/sect-Security_Guide-Kerberos-Setting_Up_Cross_Realm_Authentication.html I have added these principals to both FreeIPA servers: krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM (I see the warning in the FreeIPA documentation about avoiding the use of kadmin and kadmin.local - I can remove these principals if necessary). There are master and replicated FreeIPA servers in both realms and they have the required ports open at the firewalls (both directions) http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Preparing_for_an_IPA_Installation-Required_Ports.html So clients in A.EXAMPLE.COM should be able to authenticate to C.B.EXAMPLE.COM, but not the other way around (This is how I would like it setup). However, this does not appear to work. I assume that I need to add some entries to the LDAP server as well? Does anyone know if this is true and if so, how I should go about it? Thanks, Dan Scott http://danieljamesscott.org From dpal at redhat.com Fri Dec 18 17:45:47 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 18 Dec 2009 12:45:47 -0500 Subject: [Freeipa-users] Cross realm authentication In-Reply-To: <6835906b0912180931w176a1467habc3850d1bc1ec00@mail.gmail.com> References: <6835906b0912180931w176a1467habc3850d1bc1ec00@mail.gmail.com> Message-ID: <4B2BBFCB.80807@redhat.com> Dan Scott wrote: > Hi, > > Is there any documentation for adding cross realm authentication with FreeIPA? > > I have two FreeIPA realms: > > A.EXAMPLE.COM > C.B.EXAMPLE.COM > > Following the Fedora krb5-server documentation: > > http://docs.fedoraproject.org/security-guide/f11/en-US/sect-Security_Guide-Kerberos-Setting_Up_Cross_Realm_Authentication.html > > I have added these principals to both FreeIPA servers: > > krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM > > (I see the warning in the FreeIPA documentation about avoiding the use > of kadmin and kadmin.local - I can remove these principals if > necessary). > > There are master and replicated FreeIPA servers in both realms and > they have the required ports open at the firewalls (both directions) > > http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Preparing_for_an_IPA_Installation-Required_Ports.html > > So clients in A.EXAMPLE.COM should be able to authenticate to > C.B.EXAMPLE.COM, but not the other way around (This is how I would > like it setup). > > However, this does not appear to work. I assume that I need to add > some entries to the LDAP server as well? Does anyone know if this is > true and if so, how I should go about it? > > The cross realm configuration has not been tried in IPA v1.x. We also do not plan to try it for IPA v2 we are wrapping up soon. Cross realm will be our primary focus for IPA v3. We will be working on it next year. However, may be a cross realm configuration is possible and other team members have ideas of how to make it work. > Thanks, > > Dan Scott > http://danieljamesscott.org > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From nalin at redhat.com Fri Dec 18 18:40:08 2009 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 18 Dec 2009 13:40:08 -0500 Subject: [Freeipa-users] Cross realm authentication In-Reply-To: <6835906b0912180931w176a1467habc3850d1bc1ec00@mail.gmail.com> References: <6835906b0912180931w176a1467habc3850d1bc1ec00@mail.gmail.com> Message-ID: <20091218184008.GA6516@redhat.com> On Fri, Dec 18, 2009 at 12:31:44PM -0500, Dan Scott wrote: > I have added these principals to both FreeIPA servers: > > krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM > > (I see the warning in the FreeIPA documentation about avoiding the use > of kadmin and kadmin.local - I can remove these principals if > necessary). > > There are master and replicated FreeIPA servers in both realms and > they have the required ports open at the firewalls (both directions) > > http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Preparing_for_an_IPA_Installation-Required_Ports.html > > So clients in A.EXAMPLE.COM should be able to authenticate to > C.B.EXAMPLE.COM, but not the other way around (This is how I would > like it setup). > > However, this does not appear to work. I assume that I need to add > some entries to the LDAP server as well? Does anyone know if this is > true and if so, how I should go about it? If you added entries using kadmin, and kadmin can read them back, then the KDC should be able to read them, which means you should be fine. Just don't expect to be able to do much more with those entries. :) To troubleshoot this, we can walk through the steps that the client software usually does behind the scenes. First, make sure you can get the first cross-realm credential from the local KDC, after getting creds for a client of the A.EXAMPLE.COM realm: kinit admin at A.EXAMPLE.COM kvno krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM (The 'kvno' tool tells you the version number associated with the key, but in order to do that, it has to fetch credentials from the KDC, which is all we're really after here.) If you can get a cross-realm ticket, then you know that the first realm's KDC is set up correctly. Assuming the two realms have the same keys for the cross-realm service, you should then be able to use that ticket to get tickets for a service in the foreign realm, from the foreign realm's KDC: kvno host/foreign_kdc_hostname at C.B.EXAMPLE.COM Here, I'm assuming you can fill in the name of a service principal in the second realm if you don't have a "host" entry for the foreign realm's KDC. If this succeeds, then cross-realm authentication is correctly set up as far as the KDCs are concerned. If the first step fails, check that your clients "know" that the cross-realm credentials can be obtained directly from the local realm's KDC, and that there aren't any intermediate realms that it needs to go through. If they don't, you're probably seeing failed requests for credentials for "krbtgt/EXAMPLE.COM" in A.EXAMPLE.COM's KDC log (/var/log/krb5kdc.log). To fix that, you'll need to add some configuration to the client system /etc/krb5.conf files. The configuration snippet for the client system's krb5.conf will probably look like this: [capaths] A.EXAMPLE.COM = { C.B.EXAMPLE.COM = . } If the second step fails, then my first guess would be that the keys that the two realms have for the cross-realm principal are somehow different. In that case, resetting both by changing their passwords (it can be a randomly-generated password, but it should be the same in both realms) should be the simplest fix. HTH, Nalin From ssorce at redhat.com Fri Dec 18 19:30:01 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 18 Dec 2009 14:30:01 -0500 Subject: [Freeipa-users] Cross realm authentication In-Reply-To: <6835906b0912180931w176a1467habc3850d1bc1ec00@mail.gmail.com> References: <6835906b0912180931w176a1467habc3850d1bc1ec00@mail.gmail.com> Message-ID: <20091218143001.0853d355@willson.li.ssimo.org> On Fri, 18 Dec 2009 12:31:44 -0500 Dan Scott wrote: > So clients in A.EXAMPLE.COM should be able to authenticate to > C.B.EXAMPLE.COM, but not the other way around (This is how I would > like it setup). > > However, this does not appear to work. I assume that I need to add > some entries to the LDAP server as well? Does anyone know if this is > true and if so, how I should go about it? There are 2 things to consider when cross realm trust are involved. 1. certainly a correct setup so that clients can successfully perform authentication. See Nalin remarks on that. 2. The second is that in order to login on a system you need, not only a successful authentication but an actual user (with uid,gid,home,shell info) the system can associate to your successful authentication. Unless you are interested only in something like http auth which can work w/o real system users. This second part requires a way to provide the other realm users to your system. At the moment we do not have any automated mechanism in FreeIPA itself or in the client to provide that. We will work on these features next year. Simo. -- Simo Sorce * Red Hat, Inc * New York From danieljamesscott at gmail.com Fri Dec 18 20:13:22 2009 From: danieljamesscott at gmail.com (Dan Scott) Date: Fri, 18 Dec 2009 15:13:22 -0500 Subject: [Freeipa-users] Cross realm authentication In-Reply-To: <20091218184008.GA6516@redhat.com> References: <6835906b0912180931w176a1467habc3850d1bc1ec00@mail.gmail.com> <20091218184008.GA6516@redhat.com> Message-ID: <6835906b0912181213j488dae8cped72d1b5cd5573cd@mail.gmail.com> Hi, On Fri, Dec 18, 2009 at 13:40, Nalin Dahyabhai wrote: > On Fri, Dec 18, 2009 at 12:31:44PM -0500, Dan Scott wrote: >> I have added these principals to both FreeIPA servers: >> >> krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM >> >> (I see the warning in the FreeIPA documentation about avoiding the use >> of kadmin and kadmin.local - I can remove these principals if >> necessary). >> >> There are master and replicated FreeIPA servers in both realms and >> they have the required ports open at the firewalls (both directions) >> >> http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Preparing_for_an_IPA_Installation-Required_Ports.html >> >> So clients in A.EXAMPLE.COM should be able to authenticate to >> C.B.EXAMPLE.COM, but not the other way around (This is how I would >> like it setup). >> >> However, this does not appear to work. I assume that I need to add >> some entries to the LDAP server as well? Does anyone know if this is >> true and if so, how I should go about it? > > If you added entries using kadmin, and kadmin can read them back, then > the KDC should be able to read them, which means you should be fine. > Just don't expect to be able to do much more with those entries. :) > > To troubleshoot this, we can walk through the steps that the client > software usually does behind the scenes. ?First, make sure you can get > the first cross-realm credential from the local KDC, after getting creds > for a client of the A.EXAMPLE.COM realm: > ?kinit admin at A.EXAMPLE.COM > ?kvno krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM > > (The 'kvno' tool tells you the version number associated with the key, > but in order to do that, it has to fetch credentials from the KDC, which > is all we're really after here.) ?If you can get a cross-realm ticket, > then you know that the first realm's KDC is set up correctly. ?Assuming > the two realms have the same keys for the cross-realm service, you > should then be able to use that ticket to get tickets for a service in > the foreign realm, from the foreign realm's KDC: > ?kvno host/foreign_kdc_hostname at C.B.EXAMPLE.COM > > Here, I'm assuming you can fill in the name of a service principal in > the second realm if you don't have a "host" entry for the foreign > realm's KDC. ?If this succeeds, then cross-realm authentication is > correctly set up as far as the KDCs are concerned. > > If the first step fails, check that your clients "know" that the > cross-realm credentials can be obtained directly from the local realm's > KDC, and that there aren't any intermediate realms that it needs to go > through. ?If they don't, you're probably seeing failed requests for > credentials for "krbtgt/EXAMPLE.COM" in A.EXAMPLE.COM's KDC log > (/var/log/krb5kdc.log). > > To fix that, you'll need to add some configuration to the client system > /etc/krb5.conf files. ?The configuration snippet for the client system's > krb5.conf will probably look like this: > > ?[capaths] > ? ?A.EXAMPLE.COM = { > ? ? ?C.B.EXAMPLE.COM = . > ? ?} > > If the second step fails, then my first guess would be that the keys > that the two realms have for the cross-realm principal are somehow > different. ?In that case, resetting both by changing their passwords (it > can be a randomly-generated password, but it should be the same in both > realms) should be the simplest fix. Thanks for that information - it clarified a few things for me. Here's my output: $ kinit Password for guser2 at EXAMPLE.COM: $ kvno krbtgt/A.EXAMPLE.COM at A.EXAMPLE.COM krbtgt/A.EXAMPLE.COM at A.EXAMPLE.COM: kvno = 1 $ kvno krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM: kvno = 1 $ kvno host/server.c.b.example.com at C.B.EXAMPLE.COM host/server.c.b.example.com at C.B.EXAMPLE.COM: kvno = 3 $ klist Ticket cache: FILE:/tmp/krb5cc_1147_tvDVq8 Default principal: guser2 at A.EXAMPLE.COM Valid starting Expires Service principal 12/18/09 14:48:28 12/19/09 14:48:23 krbtgt/A.EXAMPLE.COM at EXAMPLE.COM 12/18/09 14:48:33 12/19/09 14:48:23 krbtgt/C.B.EXAMPLE.COM at A.EXAMPLE.COM 12/18/09 14:48:35 12/19/09 14:48:23 host/server.a.example.com at C.B.EXAMPLE.COM So all appears to be working correctly, right? This worked the same, with and without the [capaths] entry which is a little strange. Having said that, my DNS configuration and the KDCs for both realms are accessible from my client - I can do: kinit user_in_a_example at A.EXAMPLE.COM and kinit user_in_c_b_example at C.B.EXAMPLE.COM and both will obtain a valid ticket. I've just read Simo Sorce's comments about system users and I think that this may be causing some of my problems. If I read this correctly, I cannot just ssh from one machine to another in a different realm using a user in the first realm? Is this related to the LDAP configuration/entries? I would like to use this with http authentication. i.e. I would like to permit users in A.EXAMPLE.COM to authenticate (and authorize, if possible) with a website which is controlled by C.B.EXAMPLE.COM. When cross-realm authentication is discussed, does that mean only authentication? Or does it include authorization as well? Thanks for all your help, Dan From chorn at fluxcoil.net Sat Dec 19 11:57:08 2009 From: chorn at fluxcoil.net (Christian Horn) Date: Sat, 19 Dec 2009 12:57:08 +0100 Subject: [Freeipa-users] Cross realm authentication In-Reply-To: <6835906b0912181213j488dae8cped72d1b5cd5573cd@mail.gmail.com> References: <6835906b0912180931w176a1467habc3850d1bc1ec00@mail.gmail.com> <20091218184008.GA6516@redhat.com> <6835906b0912181213j488dae8cped72d1b5cd5573cd@mail.gmail.com> Message-ID: <20091219115707.GA27418@fluxcoil.net> On Fri, Dec 18, 2009 at 03:13:22PM -0500, Dan Scott wrote: > > I've just read Simo Sorce's comments about system users and I think > that this may be causing some of my problems. If I read this > correctly, I cannot just ssh from one machine to another in a > different realm using a user in the first realm? You can, but since kerberos is only handling authentication you additionally need to provide uids/gids etc on the other box, the user account data. > Is this related to > the LDAP configuration/entries? ldap-directory is one way to host it, a quick fix for debugging is just 'useradd'ing the user on the destination server. For authorization that data is then used. > When cross-realm authentication is discussed, does that mean only > authentication? Or does it include authorization as well? In kerberos-terms its purely for authentication. Christian From jrobertm8 at yahoo.com Tue Dec 29 09:24:05 2009 From: jrobertm8 at yahoo.com (John Robert Mendoza) Date: Tue, 29 Dec 2009 17:24:05 +0800 (SGT) Subject: [Freeipa-users] freeipa replication In-Reply-To: <637089.67139.qm@web76301.mail.sg1.yahoo.com> Message-ID: <108883.57229.qm@web76311.mail.sg1.yahoo.com> Finally I made it work! I had to manually install the CA certificate and the server certificate to the database. As for the replica machine, all I had to do was to add the main IPA machine and the replica machines entry to the /etc/hosts file. Thanks to all! John Robert Mendoza --- On Tue, 12/15/09, John Robert Mendoza wrote: From: John Robert Mendoza Subject: Re: [Freeipa-users] freeipa replication To: "Rob Crittenden" Cc: freeipa-users at redhat.com Date: Tuesday, 15 December, 2009, 6:13 PM I did this to install the master server. Before even making a replica. John Robert Mendoza --- On Tue, 12/15/09, John Robert Mendoza wrote: From: John Robert Mendoza Subject: Re: [Freeipa-users] freeipa replication To: "Rob Crittenden" Cc: freeipa-users at redhat.com Date: Tuesday, 15 December, 2009, 5:55 PM Hi Rob, Just to let you know, I tried to again reproduce the installation. I did a clean install of Fedora 11 on a machine and updated it using yum. Then I tried to install FreeIPA on it. But strangely I had a harder time doing it.? It again outputs an error complaing about not being able to contact itself. here is the ipaserver-install log 2009-12-15 20:19:51,187 DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2009-12-15 20:19:51,196 CRITICAL Could not connect to the Directory Server on id.example.net 2009-12-15 20:19:51,204 DEBUG {'desc': "Can't contact LDAP server"} ? File "/usr/sbin/ipa-server-install", line 609, in ??? sys.exit(main()) ? File "/usr/sbin/ipa-server-install", line 509, in main ??? krb.create_instance(ds_user, realm_name, host_name, domain_name, dm_password, master_password) ? File "/usr/lib/python2.6/site-packages/ipaserver/krbinstance.py", line 135, in create_instance ??? self.__common_setup(ds_user, realm_name, host_name, domain_name, admin_password) ? File "/usr/lib/python2.6/site-packages/ipaserver/krbinstance.py", line 119, in __common_setup ??? raise e TIA. John Robert Mendoza --- On Sat, 12/12/09, Rob Crittenden wrote: From: Rob Crittenden Subject: Re: [Freeipa-users] freeipa replication To: "John Robert Mendoza" Cc: freeipa-users at redhat.com Date: Saturday, 12 December, 2009, 2:50 AM John Robert Mendoza wrote: > Rob, > > I'm using freeipa 1.2.2 on a fedora 11 machine. I have successfully configured it for authentication for our services but the lack of replication makes it vulnerable for unavailability and downtime. > It's complaining about the replica server not being able to contact the ldap server. > > This can be reproduced by: > > 1. Clean install fedora 11 > 2. Install the ipa packages > 3. Clean install fedora 11 on a "replica" server > 4. Install the ipa packages > 5. ipa-replica-prepare on the freeipa server > 6. ipa-replica-install on the replica > > note: both machines have DNS records. > > TIA > Ok, strange. On the replica server can you do something like: % ldapsearch -x -h ipa.example.com -p 389 -b "dc=example,dc=com" uid=admin That will confirm that the ports are available. Can you provide the ipareplica-install.log? rob Surf faster. Internet Explorer 8 optmized for Yahoo! auto launches 2 of your favorite pages everytime you open your browser.Get IE8 here! (It's free) New Email addresses available on Yahoo! Get the Email name you've always wanted on the new @ymail and @rocketmail. Hurry before someone else does! -----Inline Attachment Follows----- _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: