From simo at redhat.com Mon Jan 2 15:00:02 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Jan 2012 10:00:02 -0500 Subject: [Freeipa-users] Large slow down when using IPA In-Reply-To: <4EFEE573.5020503@gmail.com> References: <4EFE6921.8060900@gmail.com> <16D2D5DF-82DA-43B5-B2B2-609C35BBFE41@citrixonline.com> <4EFEE573.5020503@gmail.com> Message-ID: <1325516402.30661.9.camel@willson.li.ssimo.org> On Sat, 2011-12-31 at 01:35 -0900, Erinn Looney-Triggs wrote: > On 12/30/2011 07:19 PM, JR Aquino wrote: > > > > On Dec 30, 2011, at 5:45 PM, Erinn Looney-Triggs wrote: > > > >> I have been slowly rolling out FreeIPA to my systems, trying to track > >> differences/changes. One of the most noticeable has been a large slow > >> down in file access times. > >> > >> Let me explain as best as I can. I use AIDE to track the file system > >> (think tripwire) and it runs checks once a day. During these checks it > >> is scanning (almost) the entire file system and comparing it to a stored > >> database. On a moderately powered system with ~151k files, an AIDE run > >> will usually take ~30 minutes. After the system becomes an IPA client > >> the same run will generally take ~90-120 minutes. Un-install the > >> ipa-client, back to ~30 minutes for an AIDE run. > >> > >> Now clearly a lot of lookups are being done for user names and group > >> names, and this will have a performance hit that is dependant on the > >> network. However, the odd thing is that even when running on the IPA > >> server itself the slowdown is still the same. > >> > >> Not sure if this is an IPA problem, an SSSD problem, a bit of both, or > >> neither, perhaps it is just the way it is, but a slowdown of 3-4x seems > >> a bit much to me. Clearly the results are not scientific, however, they > >> have been generally reproducible since I started rolling IPA out. > >> > >> As a side note this slowdown has also broken bacula backups, as the > >> bacula client is scanning the filesystem for change (using accurate > >> backups) the director times out. > >> > >> Any thoughts, or opinions? Workarounds etc? I have checked to make sure > >> that SSSD caching is enabled, and functional. > >> > >> Thanks, > >> > >> -Erinn > > > > I am assuming that these are all running as local users. > > > > From the sssd.conf man page in the nss section: > > > > filter_users, filter_groups (string) > > Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the > > particular domain. > > > > Default: root > > > > > > Try adding this to your sssd.conf: > > > > [nss] > > filter_groups = root,bacula,aide,otherdaemonuser <-as needed > > filter_users = root,bacula,aide,otherdaemonuser <- as needed > > > > Let me know if that solves your issue. > > > > Thanks for pointing that out, completely missed that option! Wouldn't it > be sweet to have an option that say looked at /etc/login.defs and just > didn't lookup anything under MIN_UID, on the assumption that those are > system accounts? Certainly would stop a lot of lookups I imagine. We already have range options (min_id/max_id), but unfortunately that doesn't help when an application asks for information by name. You either permanently blacklist such name or you have to do the lookup and then find out it either a) does not exist, or b) it has to be filtered out. > Of course you would have to leave it as an option and probably default > it to off given the odd things people do with their systems. Indeed sssd used to enforce a min id range of 1000 and we turned it off in the default configuration due to issues with weird configurations. Can you try using both min_id and filter_users and see if it makes any difference in your case ? Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Mon Jan 2 16:29:24 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 2 Jan 2012 17:29:24 +0100 Subject: [Freeipa-users] Large slow down when using IPA In-Reply-To: <1325516402.30661.9.camel@willson.li.ssimo.org> References: <4EFE6921.8060900@gmail.com> <16D2D5DF-82DA-43B5-B2B2-609C35BBFE41@citrixonline.com> <4EFEE573.5020503@gmail.com> <1325516402.30661.9.camel@willson.li.ssimo.org> Message-ID: <20120102162924.GE3516@zeppelin.brq.redhat.com> On Mon, Jan 02, 2012 at 10:00:02AM -0500, Simo Sorce wrote: > On Sat, 2011-12-31 at 01:35 -0900, Erinn Looney-Triggs wrote: > > On 12/30/2011 07:19 PM, JR Aquino wrote: > > > > > > On Dec 30, 2011, at 5:45 PM, Erinn Looney-Triggs wrote: > > > > > >> I have been slowly rolling out FreeIPA to my systems, trying to track > > >> differences/changes. One of the most noticeable has been a large slow > > >> down in file access times. > > >> > > >> Let me explain as best as I can. I use AIDE to track the file system > > >> (think tripwire) and it runs checks once a day. During these checks it > > >> is scanning (almost) the entire file system and comparing it to a stored > > >> database. On a moderately powered system with ~151k files, an AIDE run > > >> will usually take ~30 minutes. After the system becomes an IPA client > > >> the same run will generally take ~90-120 minutes. Un-install the > > >> ipa-client, back to ~30 minutes for an AIDE run. > > >> > > >> Now clearly a lot of lookups are being done for user names and group > > >> names, and this will have a performance hit that is dependant on the > > >> network. However, the odd thing is that even when running on the IPA > > >> server itself the slowdown is still the same. > > >> > > >> Not sure if this is an IPA problem, an SSSD problem, a bit of both, or > > >> neither, perhaps it is just the way it is, but a slowdown of 3-4x seems > > >> a bit much to me. Clearly the results are not scientific, however, they > > >> have been generally reproducible since I started rolling IPA out. > > >> > > >> As a side note this slowdown has also broken bacula backups, as the > > >> bacula client is scanning the filesystem for change (using accurate > > >> backups) the director times out. > > >> > > >> Any thoughts, or opinions? Workarounds etc? I have checked to make sure > > >> that SSSD caching is enabled, and functional. > > >> > > >> Thanks, > > >> > > >> -Erinn > > > > > > I am assuming that these are all running as local users. > > > > > > From the sssd.conf man page in the nss section: > > > > > > filter_users, filter_groups (string) > > > Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the > > > particular domain. > > > > > > Default: root > > > > > > > > > Try adding this to your sssd.conf: > > > > > > [nss] > > > filter_groups = root,bacula,aide,otherdaemonuser <-as needed > > > filter_users = root,bacula,aide,otherdaemonuser <- as needed > > > > > > Let me know if that solves your issue. > > > > > > > Thanks for pointing that out, completely missed that option! Wouldn't it > > be sweet to have an option that say looked at /etc/login.defs and just > > didn't lookup anything under MIN_UID, on the assumption that those are > > system accounts? Certainly would stop a lot of lookups I imagine. > > We already have range options (min_id/max_id), but unfortunately that > doesn't help when an application asks for information by name. > You either permanently blacklist such name or you have to do the lookup > and then find out it either a) does not exist, or b) it has to be > filtered out. > > > Of course you would have to leave it as an option and probably default > > it to off given the odd things people do with their systems. > > Indeed sssd used to enforce a min id range of 1000 and we turned it off > in the default configuration due to issues with weird configurations. > > Can you try using both min_id and filter_users and see if it makes any > difference in your case ? > > Simo. > Even when performing getpwuid() calls, SSSD first looks up the user information, reads the UID LDAP attribute and then checks the UID value from LDAP against min_id/max_id values. I guess we could open a RFE to filter id values at the time getpwuid/getgrgid is called. From simo at redhat.com Mon Jan 2 17:53:29 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Jan 2012 12:53:29 -0500 Subject: [Freeipa-users] Large slow down when using IPA In-Reply-To: <20120102162924.GE3516@zeppelin.brq.redhat.com> References: <4EFE6921.8060900@gmail.com> <16D2D5DF-82DA-43B5-B2B2-609C35BBFE41@citrixonline.com> <4EFEE573.5020503@gmail.com> <1325516402.30661.9.camel@willson.li.ssimo.org> <20120102162924.GE3516@zeppelin.brq.redhat.com> Message-ID: <1325526809.30661.13.camel@willson.li.ssimo.org> On Mon, 2012-01-02 at 17:29 +0100, Jakub Hrozek wrote: > On Mon, Jan 02, 2012 at 10:00:02AM -0500, Simo Sorce wrote: > > On Sat, 2011-12-31 at 01:35 -0900, Erinn Looney-Triggs wrote: > > > On 12/30/2011 07:19 PM, JR Aquino wrote: > > > > > > > > On Dec 30, 2011, at 5:45 PM, Erinn Looney-Triggs wrote: > > > > > > > >> I have been slowly rolling out FreeIPA to my systems, trying to track > > > >> differences/changes. One of the most noticeable has been a large slow > > > >> down in file access times. > > > >> > > > >> Let me explain as best as I can. I use AIDE to track the file system > > > >> (think tripwire) and it runs checks once a day. During these checks it > > > >> is scanning (almost) the entire file system and comparing it to a stored > > > >> database. On a moderately powered system with ~151k files, an AIDE run > > > >> will usually take ~30 minutes. After the system becomes an IPA client > > > >> the same run will generally take ~90-120 minutes. Un-install the > > > >> ipa-client, back to ~30 minutes for an AIDE run. > > > >> > > > >> Now clearly a lot of lookups are being done for user names and group > > > >> names, and this will have a performance hit that is dependant on the > > > >> network. However, the odd thing is that even when running on the IPA > > > >> server itself the slowdown is still the same. > > > >> > > > >> Not sure if this is an IPA problem, an SSSD problem, a bit of both, or > > > >> neither, perhaps it is just the way it is, but a slowdown of 3-4x seems > > > >> a bit much to me. Clearly the results are not scientific, however, they > > > >> have been generally reproducible since I started rolling IPA out. > > > >> > > > >> As a side note this slowdown has also broken bacula backups, as the > > > >> bacula client is scanning the filesystem for change (using accurate > > > >> backups) the director times out. > > > >> > > > >> Any thoughts, or opinions? Workarounds etc? I have checked to make sure > > > >> that SSSD caching is enabled, and functional. > > > >> > > > >> Thanks, > > > >> > > > >> -Erinn > > > > > > > > I am assuming that these are all running as local users. > > > > > > > > From the sssd.conf man page in the nss section: > > > > > > > > filter_users, filter_groups (string) > > > > Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the > > > > particular domain. > > > > > > > > Default: root > > > > > > > > > > > > Try adding this to your sssd.conf: > > > > > > > > [nss] > > > > filter_groups = root,bacula,aide,otherdaemonuser <-as needed > > > > filter_users = root,bacula,aide,otherdaemonuser <- as needed > > > > > > > > Let me know if that solves your issue. > > > > > > > > > > Thanks for pointing that out, completely missed that option! Wouldn't it > > > be sweet to have an option that say looked at /etc/login.defs and just > > > didn't lookup anything under MIN_UID, on the assumption that those are > > > system accounts? Certainly would stop a lot of lookups I imagine. > > > > We already have range options (min_id/max_id), but unfortunately that > > doesn't help when an application asks for information by name. > > You either permanently blacklist such name or you have to do the lookup > > and then find out it either a) does not exist, or b) it has to be > > filtered out. > > > > > Of course you would have to leave it as an option and probably default > > > it to off given the odd things people do with their systems. > > > > Indeed sssd used to enforce a min id range of 1000 and we turned it off > > in the default configuration due to issues with weird configurations. > > > > Can you try using both min_id and filter_users and see if it makes any > > difference in your case ? > > > > Simo. > > > > Even when performing getpwuid() calls, SSSD first looks up the user > information, reads the UID LDAP attribute and then checks the UID value > from LDAP against min_id/max_id values. Not according to my reading of the sources, if you look into nss_cmd_getpwuid_search() you'll see that we proceed only if we first pass the min_id/max_id range check, otherwise we return ENOENT. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Mon Jan 2 20:40:12 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 2 Jan 2012 21:40:12 +0100 Subject: [Freeipa-users] Large slow down when using IPA In-Reply-To: <1325526809.30661.13.camel@willson.li.ssimo.org> References: <4EFE6921.8060900@gmail.com> <16D2D5DF-82DA-43B5-B2B2-609C35BBFE41@citrixonline.com> <4EFEE573.5020503@gmail.com> <1325516402.30661.9.camel@willson.li.ssimo.org> <20120102162924.GE3516@zeppelin.brq.redhat.com> <1325526809.30661.13.camel@willson.li.ssimo.org> Message-ID: <20120102204012.GA26585@hendrix.redhat.com> On Mon, Jan 02, 2012 at 12:53:29PM -0500, Simo Sorce wrote: > On Mon, 2012-01-02 at 17:29 +0100, Jakub Hrozek wrote: > > On Mon, Jan 02, 2012 at 10:00:02AM -0500, Simo Sorce wrote: > > > On Sat, 2011-12-31 at 01:35 -0900, Erinn Looney-Triggs wrote: > > > > On 12/30/2011 07:19 PM, JR Aquino wrote: > > > > > > > > > > On Dec 30, 2011, at 5:45 PM, Erinn Looney-Triggs wrote: > > > > > > > > > >> I have been slowly rolling out FreeIPA to my systems, trying to track > > > > >> differences/changes. One of the most noticeable has been a large slow > > > > >> down in file access times. > > > > >> > > > > >> Let me explain as best as I can. I use AIDE to track the file system > > > > >> (think tripwire) and it runs checks once a day. During these checks it > > > > >> is scanning (almost) the entire file system and comparing it to a stored > > > > >> database. On a moderately powered system with ~151k files, an AIDE run > > > > >> will usually take ~30 minutes. After the system becomes an IPA client > > > > >> the same run will generally take ~90-120 minutes. Un-install the > > > > >> ipa-client, back to ~30 minutes for an AIDE run. > > > > >> > > > > >> Now clearly a lot of lookups are being done for user names and group > > > > >> names, and this will have a performance hit that is dependant on the > > > > >> network. However, the odd thing is that even when running on the IPA > > > > >> server itself the slowdown is still the same. > > > > >> > > > > >> Not sure if this is an IPA problem, an SSSD problem, a bit of both, or > > > > >> neither, perhaps it is just the way it is, but a slowdown of 3-4x seems > > > > >> a bit much to me. Clearly the results are not scientific, however, they > > > > >> have been generally reproducible since I started rolling IPA out. > > > > >> > > > > >> As a side note this slowdown has also broken bacula backups, as the > > > > >> bacula client is scanning the filesystem for change (using accurate > > > > >> backups) the director times out. > > > > >> > > > > >> Any thoughts, or opinions? Workarounds etc? I have checked to make sure > > > > >> that SSSD caching is enabled, and functional. > > > > >> > > > > >> Thanks, > > > > >> > > > > >> -Erinn > > > > > > > > > > I am assuming that these are all running as local users. > > > > > > > > > > From the sssd.conf man page in the nss section: > > > > > > > > > > filter_users, filter_groups (string) > > > > > Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the > > > > > particular domain. > > > > > > > > > > Default: root > > > > > > > > > > > > > > > Try adding this to your sssd.conf: > > > > > > > > > > [nss] > > > > > filter_groups = root,bacula,aide,otherdaemonuser <-as needed > > > > > filter_users = root,bacula,aide,otherdaemonuser <- as needed > > > > > > > > > > Let me know if that solves your issue. > > > > > > > > > > > > > Thanks for pointing that out, completely missed that option! Wouldn't it > > > > be sweet to have an option that say looked at /etc/login.defs and just > > > > didn't lookup anything under MIN_UID, on the assumption that those are > > > > system accounts? Certainly would stop a lot of lookups I imagine. > > > > > > We already have range options (min_id/max_id), but unfortunately that > > > doesn't help when an application asks for information by name. > > > You either permanently blacklist such name or you have to do the lookup > > > and then find out it either a) does not exist, or b) it has to be > > > filtered out. > > > > > > > Of course you would have to leave it as an option and probably default > > > > it to off given the odd things people do with their systems. > > > > > > Indeed sssd used to enforce a min id range of 1000 and we turned it off > > > in the default configuration due to issues with weird configurations. > > > > > > Can you try using both min_id and filter_users and see if it makes any > > > difference in your case ? > > > > > > Simo. > > > > > > > Even when performing getpwuid() calls, SSSD first looks up the user > > information, reads the UID LDAP attribute and then checks the UID value > > from LDAP against min_id/max_id values. > > Not according to my reading of the sources, if you look into > nss_cmd_getpwuid_search() you'll see that we proceed only if we first > pass the min_id/max_id range check, otherwise we return ENOENT. > > Simo. Sorry, you're right and I need to warm up my brain a little more after the Christmas break. Thanks! From erinn.looneytriggs at gmail.com Mon Jan 2 20:54:45 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 02 Jan 2012 11:54:45 -0900 Subject: [Freeipa-users] Large slow down when using IPA In-Reply-To: <20120102204012.GA26585@hendrix.redhat.com> References: <4EFE6921.8060900@gmail.com> <16D2D5DF-82DA-43B5-B2B2-609C35BBFE41@citrixonline.com> <4EFEE573.5020503@gmail.com> <1325516402.30661.9.camel@willson.li.ssimo.org> <20120102162924.GE3516@zeppelin.brq.redhat.com> <1325526809.30661.13.camel@willson.li.ssimo.org> <20120102204012.GA26585@hendrix.redhat.com> Message-ID: <4F021995.7020604@gmail.com> On 01/02/2012 11:40 AM, Jakub Hrozek wrote: > On Mon, Jan 02, 2012 at 12:53:29PM -0500, Simo Sorce wrote: >> On Mon, 2012-01-02 at 17:29 +0100, Jakub Hrozek wrote: >>> On Mon, Jan 02, 2012 at 10:00:02AM -0500, Simo Sorce wrote: >>>> On Sat, 2011-12-31 at 01:35 -0900, Erinn Looney-Triggs wrote: >>>>> On 12/30/2011 07:19 PM, JR Aquino wrote: >>>>>> >>>>>> On Dec 30, 2011, at 5:45 PM, Erinn Looney-Triggs wrote: >>>>>> >>>>>>> I have been slowly rolling out FreeIPA to my systems, trying to track >>>>>>> differences/changes. One of the most noticeable has been a large slow >>>>>>> down in file access times. >>>>>>> >>>>>>> Let me explain as best as I can. I use AIDE to track the file system >>>>>>> (think tripwire) and it runs checks once a day. During these checks it >>>>>>> is scanning (almost) the entire file system and comparing it to a stored >>>>>>> database. On a moderately powered system with ~151k files, an AIDE run >>>>>>> will usually take ~30 minutes. After the system becomes an IPA client >>>>>>> the same run will generally take ~90-120 minutes. Un-install the >>>>>>> ipa-client, back to ~30 minutes for an AIDE run. >>>>>>> >>>>>>> Now clearly a lot of lookups are being done for user names and group >>>>>>> names, and this will have a performance hit that is dependant on the >>>>>>> network. However, the odd thing is that even when running on the IPA >>>>>>> server itself the slowdown is still the same. >>>>>>> >>>>>>> Not sure if this is an IPA problem, an SSSD problem, a bit of both, or >>>>>>> neither, perhaps it is just the way it is, but a slowdown of 3-4x seems >>>>>>> a bit much to me. Clearly the results are not scientific, however, they >>>>>>> have been generally reproducible since I started rolling IPA out. >>>>>>> >>>>>>> As a side note this slowdown has also broken bacula backups, as the >>>>>>> bacula client is scanning the filesystem for change (using accurate >>>>>>> backups) the director times out. >>>>>>> >>>>>>> Any thoughts, or opinions? Workarounds etc? I have checked to make sure >>>>>>> that SSSD caching is enabled, and functional. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Erinn >>>>>> >>>>>> I am assuming that these are all running as local users. >>>>>> >>>>>> From the sssd.conf man page in the nss section: >>>>>> >>>>>> filter_users, filter_groups (string) >>>>>> Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the >>>>>> particular domain. >>>>>> >>>>>> Default: root >>>>>> >>>>>> >>>>>> Try adding this to your sssd.conf: >>>>>> >>>>>> [nss] >>>>>> filter_groups = root,bacula,aide,otherdaemonuser <-as needed >>>>>> filter_users = root,bacula,aide,otherdaemonuser <- as needed >>>>>> >>>>>> Let me know if that solves your issue. >>>>>> >>>>> >>>>> Thanks for pointing that out, completely missed that option! Wouldn't it >>>>> be sweet to have an option that say looked at /etc/login.defs and just >>>>> didn't lookup anything under MIN_UID, on the assumption that those are >>>>> system accounts? Certainly would stop a lot of lookups I imagine. >>>> >>>> We already have range options (min_id/max_id), but unfortunately that >>>> doesn't help when an application asks for information by name. >>>> You either permanently blacklist such name or you have to do the lookup >>>> and then find out it either a) does not exist, or b) it has to be >>>> filtered out. >>>> >>>>> Of course you would have to leave it as an option and probably default >>>>> it to off given the odd things people do with their systems. >>>> >>>> Indeed sssd used to enforce a min id range of 1000 and we turned it off >>>> in the default configuration due to issues with weird configurations. >>>> >>>> Can you try using both min_id and filter_users and see if it makes any >>>> difference in your case ? >>>> >>>> Simo. >>>> >>> >>> Even when performing getpwuid() calls, SSSD first looks up the user >>> information, reads the UID LDAP attribute and then checks the UID value >>> from LDAP against min_id/max_id values. >> >> Not according to my reading of the sources, if you look into >> nss_cmd_getpwuid_search() you'll see that we proceed only if we first >> pass the min_id/max_id range check, otherwise we return ENOENT. >> >> Simo. > > Sorry, you're right and I need to warm up my brain a little more after > the Christmas break. > > Thanks! I am going through some testing now to try and get you folks something more definitive. However, from an early test adding users/groups to filter_* seemed to reduce the performance hit slightly, but it did not take it anywhere near the levels it was at before sssd was in place. Like I said I will continue to test and get you folks some more definitive results, probably later today. Thanks for all the info and feedback. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From simo at redhat.com Mon Jan 2 22:47:39 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Jan 2012 17:47:39 -0500 Subject: [Freeipa-users] Large slow down when using IPA In-Reply-To: <4F021995.7020604@gmail.com> References: <4EFE6921.8060900@gmail.com> <16D2D5DF-82DA-43B5-B2B2-609C35BBFE41@citrixonline.com> <4EFEE573.5020503@gmail.com> <1325516402.30661.9.camel@willson.li.ssimo.org> <20120102162924.GE3516@zeppelin.brq.redhat.com> <1325526809.30661.13.camel@willson.li.ssimo.org> <20120102204012.GA26585@hendrix.redhat.com> <4F021995.7020604@gmail.com> Message-ID: <1325544459.30661.14.camel@willson.li.ssimo.org> On Mon, 2012-01-02 at 11:54 -0900, Erinn Looney-Triggs wrote: > On 01/02/2012 11:40 AM, Jakub Hrozek wrote: > > On Mon, Jan 02, 2012 at 12:53:29PM -0500, Simo Sorce wrote: > >> On Mon, 2012-01-02 at 17:29 +0100, Jakub Hrozek wrote: > >>> On Mon, Jan 02, 2012 at 10:00:02AM -0500, Simo Sorce wrote: > >>>> On Sat, 2011-12-31 at 01:35 -0900, Erinn Looney-Triggs wrote: > >>>>> On 12/30/2011 07:19 PM, JR Aquino wrote: > >>>>>> > >>>>>> On Dec 30, 2011, at 5:45 PM, Erinn Looney-Triggs wrote: > >>>>>> > >>>>>>> I have been slowly rolling out FreeIPA to my systems, trying to track > >>>>>>> differences/changes. One of the most noticeable has been a large slow > >>>>>>> down in file access times. > >>>>>>> > >>>>>>> Let me explain as best as I can. I use AIDE to track the file system > >>>>>>> (think tripwire) and it runs checks once a day. During these checks it > >>>>>>> is scanning (almost) the entire file system and comparing it to a stored > >>>>>>> database. On a moderately powered system with ~151k files, an AIDE run > >>>>>>> will usually take ~30 minutes. After the system becomes an IPA client > >>>>>>> the same run will generally take ~90-120 minutes. Un-install the > >>>>>>> ipa-client, back to ~30 minutes for an AIDE run. > >>>>>>> > >>>>>>> Now clearly a lot of lookups are being done for user names and group > >>>>>>> names, and this will have a performance hit that is dependant on the > >>>>>>> network. However, the odd thing is that even when running on the IPA > >>>>>>> server itself the slowdown is still the same. > >>>>>>> > >>>>>>> Not sure if this is an IPA problem, an SSSD problem, a bit of both, or > >>>>>>> neither, perhaps it is just the way it is, but a slowdown of 3-4x seems > >>>>>>> a bit much to me. Clearly the results are not scientific, however, they > >>>>>>> have been generally reproducible since I started rolling IPA out. > >>>>>>> > >>>>>>> As a side note this slowdown has also broken bacula backups, as the > >>>>>>> bacula client is scanning the filesystem for change (using accurate > >>>>>>> backups) the director times out. > >>>>>>> > >>>>>>> Any thoughts, or opinions? Workarounds etc? I have checked to make sure > >>>>>>> that SSSD caching is enabled, and functional. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> -Erinn > >>>>>> > >>>>>> I am assuming that these are all running as local users. > >>>>>> > >>>>>> From the sssd.conf man page in the nss section: > >>>>>> > >>>>>> filter_users, filter_groups (string) > >>>>>> Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the > >>>>>> particular domain. > >>>>>> > >>>>>> Default: root > >>>>>> > >>>>>> > >>>>>> Try adding this to your sssd.conf: > >>>>>> > >>>>>> [nss] > >>>>>> filter_groups = root,bacula,aide,otherdaemonuser <-as needed > >>>>>> filter_users = root,bacula,aide,otherdaemonuser <- as needed > >>>>>> > >>>>>> Let me know if that solves your issue. > >>>>>> > >>>>> > >>>>> Thanks for pointing that out, completely missed that option! Wouldn't it > >>>>> be sweet to have an option that say looked at /etc/login.defs and just > >>>>> didn't lookup anything under MIN_UID, on the assumption that those are > >>>>> system accounts? Certainly would stop a lot of lookups I imagine. > >>>> > >>>> We already have range options (min_id/max_id), but unfortunately that > >>>> doesn't help when an application asks for information by name. > >>>> You either permanently blacklist such name or you have to do the lookup > >>>> and then find out it either a) does not exist, or b) it has to be > >>>> filtered out. > >>>> > >>>>> Of course you would have to leave it as an option and probably default > >>>>> it to off given the odd things people do with their systems. > >>>> > >>>> Indeed sssd used to enforce a min id range of 1000 and we turned it off > >>>> in the default configuration due to issues with weird configurations. > >>>> > >>>> Can you try using both min_id and filter_users and see if it makes any > >>>> difference in your case ? > >>>> > >>>> Simo. > >>>> > >>> > >>> Even when performing getpwuid() calls, SSSD first looks up the user > >>> information, reads the UID LDAP attribute and then checks the UID value > >>> from LDAP against min_id/max_id values. > >> > >> Not according to my reading of the sources, if you look into > >> nss_cmd_getpwuid_search() you'll see that we proceed only if we first > >> pass the min_id/max_id range check, otherwise we return ENOENT. > >> > >> Simo. > > > > Sorry, you're right and I need to warm up my brain a little more after > > the Christmas break. > > > > Thanks! > > I am going through some testing now to try and get you folks something > more definitive. However, from an early test adding users/groups to > filter_* seemed to reduce the performance hit slightly, but it did not > take it anywhere near the levels it was at before sssd was in place. > > Like I said I will continue to test and get you folks some more > definitive results, probably later today. Thanks for all the info and > feedback. Hi Erinn, can you please tell what's the baseline you are comparing against ? Is it nss_ldap ? With or without nscd ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Jan 2 23:35:46 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Jan 2012 18:35:46 -0500 Subject: [Freeipa-users] MD5 passwords in NIS In-Reply-To: References: <1325128702.2664.11.camel@willson.li.ssimo.org> Message-ID: <1325547346.30661.18.camel@willson.li.ssimo.org> On Thu, 2011-12-29 at 13:13 -0500, Boris Epstein wrote: > > > On Wed, Dec 28, 2011 at 10:18 PM, Simo Sorce wrote: > On Wed, 2011-12-28 at 11:11 -0500, Boris Epstein wrote: > > Hello listmates, > > > > > > Apparently, in order to authenticate a Mac OS X Lion client > to NIS one > > needs passwords encrypted in MD5 hash shown in the passwd > and > > passwd.byname maps. FreeIPA at this point only shows a "*". > Is there a > > way to change that? > > > No, we decided that one of the rules with FreeIPA was to never > expose > hashes to clients. Same reason why we do not export a shadow > map for > example. > > With Mac OS X you should be better off using just LDAP auth. > > > > > Simo, thanks! > > > Is there a decent manual on how to link up Mac OS X (specifically, > V10.7, "Lion") to a FreeIPA server as an LDAP client? I tried that - > and just seem to be getting nowhere as the Mac wouldn't even give me > an error message (or perhaps it is my fault for not knowing where to > look but I am just lost there). > Unfortunately I am not very well versed in Mac-ism, but we have an old page in our docs, and although it states it is valid only for freeipa v1 I see that it has links to some configuration guide for ldap: http://www.freeipa.org/page/ConfiguringMACOSXTigerClient This other page seem to apply only to 10.4 instead: http://www.freeipa.org/page/ConfiguringMacintoshClients HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From erinn.looneytriggs at gmail.com Tue Jan 3 00:47:16 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 02 Jan 2012 15:47:16 -0900 Subject: [Freeipa-users] Large lastlog from large UIDs Message-ID: <4F025014.1010709@gmail.com> While digging through and trying to investigate a file system slowdown that may or may not be IPA related, I noticed an odd thing on my RHEL 5 and 6 based systems, the lastlog file was bloody huge: -rw-r--r-- 1 root root 469419202628 Jan 3 00:20 /var/log/lastlog Or for those of us who don't count that high . -rw-r--r-- 1 root root 438G Jan 3 00:20 /var/log/lastlog Now really it isn't that big: erinn at uat ~ $ du -sh /var/log/lastlog 64K /var/log/lastlog However, and I am no expert here, some backup programs will choke hard on this file, because it appears all that empty space will actually get nulled out, or at least this is happening to me with Bacula 5.0.2 on RHEL 5. More investigation into this part is necessary though... Now at a guess, this is probably related to this blog post: http://linuxshellaccount.blogspot.com/2007/11/trimming-space-in-var-problem-with.html That article was written for Solaris but it sure seems to be applicable to Linux as well. Though the multiples aren't the same. Frustratingly, this does not seem to be the case with all of my systems, only some of them. I have multiple RHEL 5 and 6 instances exhibiting this issue, and one RHEL 5 system that is not. This is probably a result of IPA choosing ludicrously high UIDs to avoid collisions (which is fine, no bashing here). Can anyone else confirm? Lend more insight? -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From erinn.looneytriggs at gmail.com Tue Jan 3 00:52:13 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 02 Jan 2012 15:52:13 -0900 Subject: [Freeipa-users] Large slow down when using IPA In-Reply-To: <1325544459.30661.14.camel@willson.li.ssimo.org> References: <4EFE6921.8060900@gmail.com> <16D2D5DF-82DA-43B5-B2B2-609C35BBFE41@citrixonline.com> <4EFEE573.5020503@gmail.com> <1325516402.30661.9.camel@willson.li.ssimo.org> <20120102162924.GE3516@zeppelin.brq.redhat.com> <1325526809.30661.13.camel@willson.li.ssimo.org> <20120102204012.GA26585@hendrix.redhat.com> <4F021995.7020604@gmail.com> <1325544459.30661.14.camel@willson.li.ssimo.org> Message-ID: <4F02513D.7020902@gmail.com> On 01/02/2012 01:47 PM, Simo Sorce wrote: > On Mon, 2012-01-02 at 11:54 -0900, Erinn Looney-Triggs wrote: >> On 01/02/2012 11:40 AM, Jakub Hrozek wrote: >>> On Mon, Jan 02, 2012 at 12:53:29PM -0500, Simo Sorce wrote: >>>> On Mon, 2012-01-02 at 17:29 +0100, Jakub Hrozek wrote: >>>>> On Mon, Jan 02, 2012 at 10:00:02AM -0500, Simo Sorce wrote: >>>>>> On Sat, 2011-12-31 at 01:35 -0900, Erinn Looney-Triggs wrote: >>>>>>> On 12/30/2011 07:19 PM, JR Aquino wrote: >>>>>>>> >>>>>>>> On Dec 30, 2011, at 5:45 PM, Erinn Looney-Triggs wrote: >>>>>>>> >>>>>>>>> I have been slowly rolling out FreeIPA to my systems, trying to track >>>>>>>>> differences/changes. One of the most noticeable has been a large slow >>>>>>>>> down in file access times. >>>>>>>>> >>>>>>>>> Let me explain as best as I can. I use AIDE to track the file system >>>>>>>>> (think tripwire) and it runs checks once a day. During these checks it >>>>>>>>> is scanning (almost) the entire file system and comparing it to a stored >>>>>>>>> database. On a moderately powered system with ~151k files, an AIDE run >>>>>>>>> will usually take ~30 minutes. After the system becomes an IPA client >>>>>>>>> the same run will generally take ~90-120 minutes. Un-install the >>>>>>>>> ipa-client, back to ~30 minutes for an AIDE run. >>>>>>>>> >>>>>>>>> Now clearly a lot of lookups are being done for user names and group >>>>>>>>> names, and this will have a performance hit that is dependant on the >>>>>>>>> network. However, the odd thing is that even when running on the IPA >>>>>>>>> server itself the slowdown is still the same. >>>>>>>>> >>>>>>>>> Not sure if this is an IPA problem, an SSSD problem, a bit of both, or >>>>>>>>> neither, perhaps it is just the way it is, but a slowdown of 3-4x seems >>>>>>>>> a bit much to me. Clearly the results are not scientific, however, they >>>>>>>>> have been generally reproducible since I started rolling IPA out. >>>>>>>>> >>>>>>>>> As a side note this slowdown has also broken bacula backups, as the >>>>>>>>> bacula client is scanning the filesystem for change (using accurate >>>>>>>>> backups) the director times out. >>>>>>>>> >>>>>>>>> Any thoughts, or opinions? Workarounds etc? I have checked to make sure >>>>>>>>> that SSSD caching is enabled, and functional. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Erinn >>>>>>>> >>>>>>>> I am assuming that these are all running as local users. >>>>>>>> >>>>>>>> From the sssd.conf man page in the nss section: >>>>>>>> >>>>>>>> filter_users, filter_groups (string) >>>>>>>> Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the >>>>>>>> particular domain. >>>>>>>> >>>>>>>> Default: root >>>>>>>> >>>>>>>> >>>>>>>> Try adding this to your sssd.conf: >>>>>>>> >>>>>>>> [nss] >>>>>>>> filter_groups = root,bacula,aide,otherdaemonuser <-as needed >>>>>>>> filter_users = root,bacula,aide,otherdaemonuser <- as needed >>>>>>>> >>>>>>>> Let me know if that solves your issue. >>>>>>>> >>>>>>> >>>>>>> Thanks for pointing that out, completely missed that option! Wouldn't it >>>>>>> be sweet to have an option that say looked at /etc/login.defs and just >>>>>>> didn't lookup anything under MIN_UID, on the assumption that those are >>>>>>> system accounts? Certainly would stop a lot of lookups I imagine. >>>>>> >>>>>> We already have range options (min_id/max_id), but unfortunately that >>>>>> doesn't help when an application asks for information by name. >>>>>> You either permanently blacklist such name or you have to do the lookup >>>>>> and then find out it either a) does not exist, or b) it has to be >>>>>> filtered out. >>>>>> >>>>>>> Of course you would have to leave it as an option and probably default >>>>>>> it to off given the odd things people do with their systems. >>>>>> >>>>>> Indeed sssd used to enforce a min id range of 1000 and we turned it off >>>>>> in the default configuration due to issues with weird configurations. >>>>>> >>>>>> Can you try using both min_id and filter_users and see if it makes any >>>>>> difference in your case ? >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> Even when performing getpwuid() calls, SSSD first looks up the user >>>>> information, reads the UID LDAP attribute and then checks the UID value >>>>> from LDAP against min_id/max_id values. >>>> >>>> Not according to my reading of the sources, if you look into >>>> nss_cmd_getpwuid_search() you'll see that we proceed only if we first >>>> pass the min_id/max_id range check, otherwise we return ENOENT. >>>> >>>> Simo. >>> >>> Sorry, you're right and I need to warm up my brain a little more after >>> the Christmas break. >>> >>> Thanks! >> >> I am going through some testing now to try and get you folks something >> more definitive. However, from an early test adding users/groups to >> filter_* seemed to reduce the performance hit slightly, but it did not >> take it anywhere near the levels it was at before sssd was in place. >> >> Like I said I will continue to test and get you folks some more >> definitive results, probably later today. Thanks for all the info and >> feedback. > > Hi Erinn, > can you please tell what's the baseline you are comparing against ? > > Is it nss_ldap ? With or without nscd ? > > Simo. > Here is what I am comparing, and hoping not to make myself look like an idiot in the process :). ipa-client system without excludes configured in sssd. ipa-client system with excludes for users and groups < id 500 configured in sssd. Finally a non ipa-client system, as in local only. These tests are all being done on the same system. All I have at this point is the fact that I started rolling out IPA (and thus sssd) to clients and AIDE checks bombed in terms of the amount of time they took. That and accurate bacula backups failed because it was taking too long to compare the local files to the db. Now it could be unrelated, but I hope not (in the not looking like an idiot category). Now of course network traffic and lag times are involved here, but the one key point that made me take notice here is that the times for an AIDE check also bombed (at about the same ratio) on the IPA servers themselves, thus pointing me to the idea that perhaps this wasn't all network related. Feel free to let me know if there is something smarter that can be done here, or if you believe I am just barking up the wrong tree. It would be interesting to test against nns_ldap etc. to see if things are about the same. I can also test clients on the same network segment as the ipa server (right now they are showing similar slowdowns as more physically remote systems). On the other hand the whole sssd link may be moot with the weird lastlog thing I just found (see other message), if AIDE and bacula are trying to process a 438GB file that could certainly slow them down. Nevertheless, this is what I am doing. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From simo at redhat.com Tue Jan 3 04:43:14 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Jan 2012 23:43:14 -0500 Subject: [Freeipa-users] Large slow down when using IPA In-Reply-To: <4F02513D.7020902@gmail.com> References: <4EFE6921.8060900@gmail.com> <16D2D5DF-82DA-43B5-B2B2-609C35BBFE41@citrixonline.com> <4EFEE573.5020503@gmail.com> <1325516402.30661.9.camel@willson.li.ssimo.org> <20120102162924.GE3516@zeppelin.brq.redhat.com> <1325526809.30661.13.camel@willson.li.ssimo.org> <20120102204012.GA26585@hendrix.redhat.com> <4F021995.7020604@gmail.com> <1325544459.30661.14.camel@willson.li.ssimo.org> <4F02513D.7020902@gmail.com> Message-ID: <1325565794.30661.31.camel@willson.li.ssimo.org> On Mon, 2012-01-02 at 15:52 -0900, Erinn Looney-Triggs wrote: > On 01/02/2012 01:47 PM, Simo Sorce wrote: > > > Hi Erinn, > > can you please tell what's the baseline you are comparing against ? > > > > Is it nss_ldap ? With or without nscd ? > > > > Simo. > > > > > Here is what I am comparing, and hoping not to make myself look like an > idiot in the process :). First of all, thanks for the full explanation, it makes the situation much more clear. > ipa-client system without excludes configured in sssd. > ipa-client system with excludes for users and groups < id 500 configured > in sssd. > Finally a non ipa-client system, as in local only. > > These tests are all being done on the same system. All I have at this > point is the fact that I started rolling out IPA (and thus sssd) to > clients and AIDE checks bombed in terms of the amount of time they took. > That and accurate bacula backups failed because it was taking too long > to compare the local files to the db. Now it could be unrelated, but I > hope not (in the not looking like an idiot category). > > Now of course network traffic and lag times are involved here, but the > one key point that made me take notice here is that the times for an > AIDE check also bombed (at about the same ratio) on the IPA servers > themselves, thus pointing me to the idea that perhaps this wasn't all > network related. Indeed it is not all network related, sssd caches a lot of information so that most lookups should be 'local'. Now here comes the gotcha in comparing against local files access. The way sssd currently works each request goes through a pipe to the sssd_nss process, while with local files glibc just reads entries off the /etc/passwd file. I wouldn't find it surprising that comparing sssd to local files you can get a 3x perf hit on user lookups. But I wouldn't expect a 3x nor a 2x slowdown on any program that doesn't just do user lookups. Some programs that heavily do user lokups may see a small degradation but it shouldn't be as evident as what you report, just a few percents at most. This is a know performance issue that we are going to solve with a local fast shared memory cache, I planned to add this feature for a few years now and I should be able to do it quite soon, but it is not there yet. If you had compared it to nss_ldap (without nscd) and got wildly different results then I'd be surprised :) > Feel free to let me know if there is something smarter that can be done > here, or if you believe I am just barking up the wrong tree. It would be > interesting to test against nns_ldap etc. to see if things are about the > same. I can also test clients on the same network segment as the ipa > server (right now they are showing similar slowdowns as more physically > remote systems). The ipa server just uses sssd against the ldap server, although the communication to the ldap server does not involve the network you still have the perf hit of the sssd elaboration if you compare it against local files. I would expect an ipa server to be faster on the first user lookup, but not faster than any other client on following lookups as they are cached in sssd. > On the other hand the whole sssd link may be moot with the weird lastlog > thing I just found (see other message), if AIDE and bacula are trying to > process a 438GB file that could certainly slow them down. Nevertheless, > this is what I am doing. Yeah eliminating this file and then comparing results again would be a very good idea. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Jan 3 04:59:50 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Jan 2012 23:59:50 -0500 Subject: [Freeipa-users] Large lastlog from large UIDs In-Reply-To: <4F025014.1010709@gmail.com> References: <4F025014.1010709@gmail.com> Message-ID: <1325566790.30661.46.camel@willson.li.ssimo.org> On Mon, 2012-01-02 at 15:47 -0900, Erinn Looney-Triggs wrote: > While digging through and trying to investigate a file system slowdown > that may or may not be IPA related, I noticed an odd thing on my RHEL 5 > and 6 based systems, the lastlog file was bloody huge: > > -rw-r--r-- 1 root root 469419202628 Jan 3 00:20 /var/log/lastlog > > Or for those of us who don't count that high . > > -rw-r--r-- 1 root root 438G Jan 3 00:20 /var/log/lastlog > > Now really it isn't that big: > > erinn at uat ~ $ du -sh /var/log/lastlog > 64K /var/log/lastlog > > However, and I am no expert here, some backup programs will choke hard > on this file, because it appears all that empty space will actually get > nulled out, or at least this is happening to me with Bacula 5.0.2 on > RHEL 5. More investigation into this part is necessary though... > > Now at a guess, this is probably related to this blog post: > http://linuxshellaccount.blogspot.com/2007/11/trimming-space-in-var-problem-with.html > > That article was written for Solaris but it sure seems to be applicable > to Linux as well. Though the multiples aren't the same. > > Frustratingly, this does not seem to be the case with all of my systems, > only some of them. I have multiple RHEL 5 and 6 instances exhibiting > this issue, and one RHEL 5 system that is not. > > This is probably a result of IPA choosing ludicrously high UIDs to avoid > collisions (which is fine, no bashing here). > > Can anyone else confirm? Lend more insight? I can confirm. apparently lastlog programmers decided that using sparse files to implement a hash table where the key is the uid number was a good idea ... Can you please file a bug against RHEL and CC me ? I am not sure what we do for RHEL5/RHEL6 as I don't know if the lastlof file format changes is considered an aBI change but we can certainly prevent this from happening in Fedora and RHEL7. I think, meanwhile you may want to exclude lastlog from backups or bzip2 it before backing it up. Thanks for reporting this. Simo. -- Simo Sorce * Red Hat, Inc * New York From erinn.looneytriggs at gmail.com Tue Jan 3 06:04:06 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 02 Jan 2012 21:04:06 -0900 Subject: [Freeipa-users] Large lastlog from large UIDs In-Reply-To: <1325566790.30661.46.camel@willson.li.ssimo.org> References: <4F025014.1010709@gmail.com> <1325566790.30661.46.camel@willson.li.ssimo.org> Message-ID: <4F029A56.8060403@gmail.com> On 01/02/2012 07:59 PM, Simo Sorce wrote: > On Mon, 2012-01-02 at 15:47 -0900, Erinn Looney-Triggs wrote: >> While digging through and trying to investigate a file system slowdown >> that may or may not be IPA related, I noticed an odd thing on my RHEL 5 >> and 6 based systems, the lastlog file was bloody huge: >> >> -rw-r--r-- 1 root root 469419202628 Jan 3 00:20 /var/log/lastlog >> >> Or for those of us who don't count that high . >> >> -rw-r--r-- 1 root root 438G Jan 3 00:20 /var/log/lastlog >> >> Now really it isn't that big: >> >> erinn at uat ~ $ du -sh /var/log/lastlog >> 64K /var/log/lastlog >> >> However, and I am no expert here, some backup programs will choke hard >> on this file, because it appears all that empty space will actually get >> nulled out, or at least this is happening to me with Bacula 5.0.2 on >> RHEL 5. More investigation into this part is necessary though... >> >> Now at a guess, this is probably related to this blog post: >> http://linuxshellaccount.blogspot.com/2007/11/trimming-space-in-var-problem-with.html >> >> That article was written for Solaris but it sure seems to be applicable >> to Linux as well. Though the multiples aren't the same. >> >> Frustratingly, this does not seem to be the case with all of my systems, >> only some of them. I have multiple RHEL 5 and 6 instances exhibiting >> this issue, and one RHEL 5 system that is not. >> >> This is probably a result of IPA choosing ludicrously high UIDs to avoid >> collisions (which is fine, no bashing here). >> >> Can anyone else confirm? Lend more insight? > > I can confirm. > apparently lastlog programmers decided that using sparse files to > implement a hash table where the key is the uid number was a good > idea ... > > Can you please file a bug against RHEL and CC me ? > > I am not sure what we do for RHEL5/RHEL6 as I don't know if the lastlof > file format changes is considered an aBI change but we can certainly > prevent this from happening in Fedora and RHEL7. > > I think, meanwhile you may want to exclude lastlog from backups or bzip2 > it before backing it up. > > Thanks for reporting this. > Simo. > Done, thanks for confirming. https://bugzilla.redhat.com/show_bug.cgi?id=771286 -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From erinn.looneytriggs at gmail.com Tue Jan 3 06:48:31 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 02 Jan 2012 21:48:31 -0900 Subject: [Freeipa-users] Large slow down when using IPA In-Reply-To: <1325565794.30661.31.camel@willson.li.ssimo.org> References: <4EFE6921.8060900@gmail.com> <16D2D5DF-82DA-43B5-B2B2-609C35BBFE41@citrixonline.com> <4EFEE573.5020503@gmail.com> <1325516402.30661.9.camel@willson.li.ssimo.org> <20120102162924.GE3516@zeppelin.brq.redhat.com> <1325526809.30661.13.camel@willson.li.ssimo.org> <20120102204012.GA26585@hendrix.redhat.com> <4F021995.7020604@gmail.com> <1325544459.30661.14.camel@willson.li.ssimo.org> <4F02513D.7020902@gmail.com> <1325565794.30661.31.camel@willson.li.ssimo.org> Message-ID: <4F02A4BF.4030306@gmail.com> On 01/02/2012 07:43 PM, Simo Sorce wrote: > On Mon, 2012-01-02 at 15:52 -0900, Erinn Looney-Triggs wrote: >> On 01/02/2012 01:47 PM, Simo Sorce wrote: >> >>> Hi Erinn, >>> can you please tell what's the baseline you are comparing against ? >>> >>> Is it nss_ldap ? With or without nscd ? >>> >>> Simo. >>> >> >> >> Here is what I am comparing, and hoping not to make myself look like an >> idiot in the process :). > > First of all, thanks for the full explanation, it makes the situation > much more clear. > >> ipa-client system without excludes configured in sssd. >> ipa-client system with excludes for users and groups < id 500 configured >> in sssd. >> Finally a non ipa-client system, as in local only. >> >> These tests are all being done on the same system. All I have at this >> point is the fact that I started rolling out IPA (and thus sssd) to >> clients and AIDE checks bombed in terms of the amount of time they took. >> That and accurate bacula backups failed because it was taking too long >> to compare the local files to the db. Now it could be unrelated, but I >> hope not (in the not looking like an idiot category). >> >> Now of course network traffic and lag times are involved here, but the >> one key point that made me take notice here is that the times for an >> AIDE check also bombed (at about the same ratio) on the IPA servers >> themselves, thus pointing me to the idea that perhaps this wasn't all >> network related. > > Indeed it is not all network related, sssd caches a lot of information > so that most lookups should be 'local'. > > Now here comes the gotcha in comparing against local files access. > The way sssd currently works each request goes through a pipe to the > sssd_nss process, while with local files glibc just reads entries off > the /etc/passwd file. > > I wouldn't find it surprising that comparing sssd to local files you can > get a 3x perf hit on user lookups. > But I wouldn't expect a 3x nor a 2x slowdown on any program that doesn't > just do user lookups. Some programs that heavily do user lokups may see > a small degradation but it shouldn't be as evident as what you report, > just a few percents at most. > > This is a know performance issue that we are going to solve with a local > fast shared memory cache, I planned to add this feature for a few years > now and I should be able to do it quite soon, but it is not there yet. > > If you had compared it to nss_ldap (without nscd) and got wildly > different results then I'd be surprised :) > >> Feel free to let me know if there is something smarter that can be done >> here, or if you believe I am just barking up the wrong tree. It would be >> interesting to test against nns_ldap etc. to see if things are about the >> same. I can also test clients on the same network segment as the ipa >> server (right now they are showing similar slowdowns as more physically >> remote systems). > > The ipa server just uses sssd against the ldap server, although the > communication to the ldap server does not involve the network you still > have the perf hit of the sssd elaboration if you compare it against > local files. I would expect an ipa server to be faster on the first user > lookup, but not faster than any other client on following lookups as > they are cached in sssd. > >> On the other hand the whole sssd link may be moot with the weird lastlog >> thing I just found (see other message), if AIDE and bacula are trying to >> process a 438GB file that could certainly slow them down. Nevertheless, >> this is what I am doing. > > Yeah eliminating this file and then comparing results again would be a > very good idea. > > HTH, > Simo. > Simo, Thanks for the information, it looks like the real culprit in all of this was the lastlog file, after excluding it from checks I am now back to just about normal for aide runs. Course aide probably should be smarter about sparse files but who knows. Thanks again for the information, and time. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From kollathodi at yahoo.com Tue Jan 3 07:52:42 2012 From: kollathodi at yahoo.com (nasir nasir) Date: Mon, 2 Jan 2012 23:52:42 -0800 (PST) Subject: [Freeipa-users] Expired SSL certificate issue with IPA Message-ID: <1325577162.75360.YahooMailClassic@web161303.mail.bf1.yahoo.com> Hi, I am facing a serious issue with my production IPA server. When I try to access IPA web interface using Firefox, it hangs and doesn't allow me to get in. It seems to be due to expired SSL certificate as seen in the apache log file, [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: 'Server-Cert' [Tue Jan 03 10:34:08 2012] [error] SSL Library Error: -8181 Certificate has expired [Tue Jan 03 10:34:08 2012] [error] Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the server can start until the problem can be resolved. [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: 'Server-Cert' Also, when I try to use the command line (ipa user-mod or user-show commands) it too just hangs and doesn't give any output or allow me for any input. I can see the following in krb5kdc.log , Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): preauth (timestamp) verify failure: Decrypt integrity check failedJan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.1.10: PREAUTH_FAILED: host/xxxxx.xxxxx.com at XXXXXX.COM for krbtgt/XXXXXX.COM at XXXXXX.COM, Decrypt integrity check failedJan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2429](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: host/xxxx.xxxxx.com at XXXXX.COM for krbtgt/XXXXXX.COM at XXXXXX.COM, Additional pre-authentication required The output of "certutil -L -d /etc/httpd/alias -n Server-Cert" confirms that certificate is expired as given below. Certificate: Data: Version: 3 (0x2) Serial Number: 10 (0xa) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=Certificate Authority,O=XXXXXX.COM" Validity: Not Before: Sun Jun 19 11:27:20 2011 Not After : Fri Dec 16 11:27:20 2011 Relevant info OS: RHEL 6.1 Output of rpm -qa | grep ipa ipa-client-2.0.0-23.el6.i686 ipa-pki-ca-theme-9.0.3-6.el6.noarch ipa-pki-common-theme-9.0.3-6.el6.noarch device-mapper-multipath-libs-0.4.9-41.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch ipa-python-2.0.0-23.el6.i686 ipa-server-selinux-2.0.0-23.el6.i686 ipa-server-2.0.0-23.el6.i686 device-mapper-multipath-0.4.9-41.el6.i686 ipa-admintools-2.0.0-23.el6.i686 I went through the documentations to check how to renew the expired certs but it seems to be confusing and different across versions. Could someone please help me out by suggesting which is the best way to achieve this ? Any help would be greatly appreciated as I am unable to perform any task on the IPA server now because of this. Regards, Nidal -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Jan 3 15:41:59 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 03 Jan 2012 08:41:59 -0700 Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <1325577162.75360.YahooMailClassic@web161303.mail.bf1.yahoo.com> References: <1325577162.75360.YahooMailClassic@web161303.mail.bf1.yahoo.com> Message-ID: <4F0321C7.4040907@redhat.com> On 01/03/2012 12:52 AM, nasir nasir wrote: > Hi, > > I am facing a serious issue with my production IPA server. When I try > to access IPA web interface using Firefox, it hangs and doesn't allow > me to get in. It seems to be due to expired SSL certificate as seen in > the apache log file, > > > [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: 'Server-Cert' > [Tue Jan 03 10:34:08 2012] [error] SSL Library Error: -8181 > Certificate has expired > [Tue Jan 03 10:34:08 2012] [error] Unable to verify certificate > 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the > server can start until the problem can be resolved. > [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: 'Server-Cert' > > > Also, when I try to use the command line (ipa user-mod or user-show > commands) it too just hangs and doesn't give any output or allow me > for any input. I can see the following in krb5kdc.log , > > Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): preauth > (timestamp) verify failure: Decrypt integrity check failed > Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): AS_REQ (4 > etypes {18 17 16 23}) 192.168.1.10: PREAUTH_FAILED: > host/xxxxx.xxxxx.com at XXXXXX.COM for krbtgt/XXXXXX.COM at XXXXXX.COM, > Decrypt integrity check failed > Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2429](info): AS_REQ (4 > etypes {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: > host/xxxx.xxxxx.com at XXXXX.COM for krbtgt/XXXXXX.COM at XXXXXX.COM, > Additional pre-authentication required > > > The output of "certutil -L -d /etc/httpd/alias -n Server-Cert" > confirms that certificate is expired as given below. > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 10 (0xa) > Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: "CN=Certificate Authority,O=XXXXXX.COM" > Validity: > Not Before: Sun Jun 19 11:27:20 2011 > Not After : Fri Dec 16 11:27:20 2011 > > > Relevant info > > OS: RHEL 6.1 > > > Output of rpm -qa | grep ipa > > ipa-client-2.0.0-23.el6.i686 > ipa-pki-ca-theme-9.0.3-6.el6.noarch > ipa-pki-common-theme-9.0.3-6.el6.noarch > device-mapper-multipath-libs-0.4.9-41.el6.i686 > python-iniparse-0.3.1-2.1.el6.noarch > ipa-python-2.0.0-23.el6.i686 > ipa-server-selinux-2.0.0-23.el6.i686 > ipa-server-2.0.0-23.el6.i686 > device-mapper-multipath-0.4.9-41.el6.i686 > ipa-admintools-2.0.0-23.el6.i686 > > > I went through the documentations to check how to renew the expired > certs but it seems to be confusing and different across versions. > Could someone please help me out by suggesting which is the best way > to achieve this ? Any help would be greatly appreciated as I am unable > to perform any task on the IPA server now because of this. > I suggest following the mod_nss suggestion to allow it to start and use the expired cert while you attempt to figure this out. > > Regards, > Nidal > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From kollathodi at yahoo.com Tue Jan 3 16:37:11 2012 From: kollathodi at yahoo.com (nasir nasir) Date: Tue, 3 Jan 2012 08:37:11 -0800 (PST) Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <4F0321C7.4040907@redhat.com> Message-ID: <1325608631.28969.YahooMailClassic@web161305.mail.bf1.yahoo.com> --- On Tue, 1/3/12, Rich Megginson wrote: From: Rich Megginson Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: "nasir nasir" Cc: freeipa-users at redhat.com, fasilkaks at gmail.com Date: Tuesday, January 3, 2012, 7:41 AM On 01/03/2012 12:52 AM, nasir nasir wrote: Hi, I am facing a serious issue with my production IPA server. When I try to access IPA web interface using Firefox, it hangs and doesn't allow me to get in. It seems to be due to expired SSL certificate as seen in the apache log file, [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: 'Server-Cert' [Tue Jan 03 10:34:08 2012] [error] SSL Library Error: -8181 Certificate has expired [Tue Jan 03 10:34:08 2012] [error] Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the server can start until the problem can be resolved. [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: 'Server-Cert' Also, when I try to use the command line (ipa user-mod or user-show commands) it too just hangs and doesn't give any output or allow me for any input. I can see the following in krb5kdc.log , Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): preauth (timestamp) verify failure: Decrypt integrity check failed Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.1.10: PREAUTH_FAILED: host/xxxxx.xxxxx.com at XXXXXX.COM for krbtgt/XXXXXX.COM at XXXXXX.COM, Decrypt integrity check failed Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2429](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: host/xxxx.xxxxx.com at XXXXX.COM for krbtgt/XXXXXX.COM at XXXXXX.COM, Additional pre-authentication required The output of "certutil -L -d /etc/httpd/alias -n Server-Cert" confirms that certificate is expired as given below. Certificate: Data: Version: 3 (0x2) Serial Number: 10 (0xa) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=Certificate Authority,O=XXXXXX.COM" Validity: Not Before: Sun Jun 19 11:27:20 2011 Not After : Fri Dec 16 11:27:20 2011 Relevant info OS: RHEL 6.1 Output of rpm -qa | grep ipa ipa-client-2.0.0-23.el6.i686 ipa-pki-ca-theme-9.0.3-6.el6.noarch ipa-pki-common-theme-9.0.3-6.el6.noarch device-mapper-multipath-libs-0.4.9-41.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch ipa-python-2.0.0-23.el6.i686 ipa-server-selinux-2.0.0-23.el6.i686 ipa-server-2.0.0-23.el6.i686 device-mapper-multipath-0.4.9-41.el6.i686 ipa-admintools-2.0.0-23.el6.i686 I went through the documentations to check how to renew the expired certs but it seems to be confusing and different across versions. Could someone please help me out by suggesting which is the best way to achieve this ? Any help would be greatly appreciated as I am unable to perform any task on the IPA server now because of this. I suggest following the mod_nss suggestion to allow it to start and use the expired cert while you attempt to figure this out. Thanks indeed for the suggestion. I will consider this. But can anyone point me the steps to renew certificate from the expired one ? Thankds and regards,Nidal -------------- next part -------------- An HTML attachment was scrubbed... URL: From JR.Aquino at citrix.com Tue Jan 3 17:32:12 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Tue, 3 Jan 2012 17:32:12 +0000 Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <1325608631.28969.YahooMailClassic@web161305.mail.bf1.yahoo.com> References: <1325608631.28969.YahooMailClassic@web161305.mail.bf1.yahoo.com> Message-ID: <071A9FE6-264A-449D-BE6F-7E985443A23D@citrixonline.com> On Jan 3, 2012, at 8:37 AM, nasir nasir wrote: > > > --- On Tue, 1/3/12, Rich Megginson wrote: > > From: Rich Megginson > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > To: "nasir nasir" > Cc: freeipa-users at redhat.com, fasilkaks at gmail.com > Date: Tuesday, January 3, 2012, 7:41 AM > > On 01/03/2012 12:52 AM, nasir nasir wrote: >> Hi, >> >> I am facing a serious issue with my production IPA server. When I try to access IPA web interface using Firefox, it hangs and doesn't allow me to get in. It seems to be due to expired SSL certificate as seen in the apache log file, >> >> >> [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: 'Server-Cert' >> [Tue Jan 03 10:34:08 2012] [error] SSL Library Error: -8181 Certificate has expired >> [Tue Jan 03 10:34:08 2012] [error] Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the server can start until the problem can be resolved. >> [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: 'Server-Cert' >> >> >> Also, when I try to use the command line (ipa user-mod or user-show commands) it too just hangs and doesn't give any output or allow me for any input. I can see the following in krb5kdc.log , >> >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): preauth (timestamp) verify failure: Decrypt integrity check failed >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.1.10: PREAUTH_FAILED: host/xxxxx.xxxxx.com at XXXXXX.COM for krbtgt/XXXXXX.COM at XXXXXX.COM, Decrypt integrity check failed >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2429](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: host/xxxx.xxxxx.com at XXXXX.COM for krbtgt/XXXXXX.COM at XXXXXX.COM, Additional pre-authentication required >> >> >> The output of "certutil -L -d /etc/httpd/alias -n Server-Cert" confirms that certificate is expired as given below. >> >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 10 (0xa) >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Issuer: "CN=Certificate Authority,O=XXXXXX.COM" >> Validity: >> Not Before: Sun Jun 19 11:27:20 2011 >> Not After : Fri Dec 16 11:27:20 2011 >> >> >> Relevant info >> >> OS: RHEL 6.1 >> >> >> Output of rpm -qa | grep ipa >> >> ipa-client-2.0.0-23.el6.i686 >> ipa-pki-ca-theme-9.0.3-6.el6.noarch >> ipa-pki-common-theme-9.0.3-6.el6.noarch >> device-mapper-multipath-libs-0.4.9-41.el6.i686 >> python-iniparse-0.3.1-2.1.el6.noarch >> ipa-python-2.0.0-23.el6.i686 >> ipa-server-selinux-2.0.0-23.el6.i686 >> ipa-server-2.0.0-23.el6.i686 >> device-mapper-multipath-0.4.9-41.el6.i686 >> ipa-admintools-2.0.0-23.el6.i686 >> >> >> I went through the documentations to check how to renew the expired certs but it seems to be confusing and different across versions. Could someone please help me out by suggesting which is the best way to achieve this ? Any help would be greatly appreciated as I am unable to perform any task on the IPA server now because of this. > I suggest following the mod_nss suggestion to allow it to start and use the expired cert while you attempt to figure this out. > > Thanks indeed for the suggestion. I will consider this. But can anyone point me the steps to renew certificate from the expired one ? > > Thankds and regards, > Nidal wasn't certmonger supposed to be designed to automatically handle this situation? > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Tue Jan 3 22:23:10 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 03 Jan 2012 17:23:10 -0500 Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <1325608631.28969.YahooMailClassic@web161305.mail.bf1.yahoo.com> References: <1325608631.28969.YahooMailClassic@web161305.mail.bf1.yahoo.com> Message-ID: <4F037FCE.4@redhat.com> nasir nasir wrote: > > > --- On *Tue, 1/3/12, Rich Megginson //*wrote: > > > From: Rich Megginson > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > To: "nasir nasir" > Cc: freeipa-users at redhat.com, fasilkaks at gmail.com > Date: Tuesday, January 3, 2012, 7:41 AM > > On 01/03/2012 12:52 AM, nasir nasir wrote: >> Hi, >> >> I am facing a serious issue with my production IPA server. When I >> try to access IPA web interface using Firefox, it hangs and >> doesn't allow me to get in. It seems to be due to expired SSL >> certificate as seen in the apache log file, >> >> >> [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: >> 'Server-Cert' >> [Tue Jan 03 10:34:08 2012] [error] SSL Library Error: -8181 >> Certificate has expired >> [Tue Jan 03 10:34:08 2012] [error] Unable to verify certificate >> 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the >> server can start until the problem can be resolved. >> [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: >> 'Server-Cert' >> >> >> Also, when I try to use the command line (ipa user-mod or >> user-show commands) it too just hangs and doesn't give any output >> or allow me for any input. I can see the following in krb5kdc.log , >> >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): preauth >> (timestamp) verify failure: Decrypt integrity check failed >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): AS_REQ (4 >> etypes {18 17 16 23}) 192.168.1.10: PREAUTH_FAILED: >> host/xxxxx.xxxxx.com at XXXXXX.COM >> for >> krbtgt/XXXXXX.COM at XXXXXX.COM >> , Decrypt integrity >> check failed >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2429](info): AS_REQ (4 >> etypes {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: >> host/xxxx.xxxxx.com at XXXXX.COM >> for >> krbtgt/XXXXXX.COM at XXXXXX.COM >> , Additional >> pre-authentication required >> >> >> The output of "certutil -L -d /etc/httpd/alias -n Server-Cert" >> confirms that certificate is expired as given below. >> >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 10 (0xa) >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Issuer: "CN=Certificate Authority,O=XXXXXX.COM" >> Validity: >> Not Before: Sun Jun 19 11:27:20 2011 >> Not After : Fri Dec 16 11:27:20 2011 >> >> >> Relevant info >> >> OS: RHEL 6.1 >> >> >> Output of rpm -qa | grep ipa >> >> ipa-client-2.0.0-23.el6.i686 >> ipa-pki-ca-theme-9.0.3-6.el6.noarch >> ipa-pki-common-theme-9.0.3-6.el6.noarch >> device-mapper-multipath-libs-0.4.9-41.el6.i686 >> python-iniparse-0.3.1-2.1.el6.noarch >> ipa-python-2.0.0-23.el6.i686 >> ipa-server-selinux-2.0.0-23.el6.i686 >> ipa-server-2.0.0-23.el6.i686 >> device-mapper-multipath-0.4.9-41.el6.i686 >> ipa-admintools-2.0.0-23.el6.i686 >> >> >> I went through the documentations to check how to renew the >> expired certs but it seems to be confusing and different across >> versions. Could someone please help me out by suggesting which is >> the best way to achieve this ? Any help would be greatly >> appreciated as I am unable to perform any task on the IPA server >> now because of this. >> > I suggest following the mod_nss suggestion to allow it to start and > use the expired cert while you attempt to figure this out. > > Thanks indeed for the suggestion. I will consider this. But can > anyone point me the steps to renew certificate from the expired one ? > > Thankds and regards, > Nidal Lets start with figuring out why certmonger didn't do this for you: Can you run as root: ipa-getcert list You should have something like: Request ID '20111215203350': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=EXAMPLE.COM Certificate Authority subject: CN=rawhide.example.com,O=EXAMPLE.COM expires: 2021-12-15 20:33:50 UTC track: yes auto-renew: yes If you don't have something like this then perhaps the easiest way to get it renewed is to tell certmonger to track it. First, look at your current database, it should look something like: # certutil -L -d /etc/httpd/alias Server-Cert u,u,u EXAMPLE.COM IPA CA CTu,u,Cu Signing-Cert u,u,u Now track it # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert Use ipa-getcert list to track the status of the renewal. Once it has been completed you can reset the EnforceValidCerts option and restart Apache. If certmonger is already tracking the cert and the renewal has failed then please provide the ipa-getcert list output. rob From niemueller at kbsg.rwth-aachen.de Tue Jan 3 22:33:44 2012 From: niemueller at kbsg.rwth-aachen.de (Tim Niemueller) Date: Tue, 03 Jan 2012 23:33:44 +0100 Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <071A9FE6-264A-449D-BE6F-7E985443A23D@citrixonline.com> References: <1325608631.28969.YahooMailClassic@web161305.mail.bf1.yahoo.com> <071A9FE6-264A-449D-BE6F-7E985443A23D@citrixonline.com> Message-ID: <4F038248.4060003@kbsg.rwth-aachen.de> On 03.01.2012 18:32, JR Aquino wrote: > > wasn't certmonger supposed to be designed to automatically handle > this situation? > I ran into the same problem a while ago. Seems that there was a faulty version at some point which prevented automated updates. It took me some time to fix it and roughly required setting a date back in the past when the certificates were still valid and then renewing the certificates manually. I think "ipa cert-request" was involved and I remember that at some point I needed to restart certmonger and then it immediately worked, but before the restart I had lots of failed tries. Hope that helps somehow, Tim -- KBSG - Knowledge-Based Systems Group AllemaniACs RoboCup Team ======================================================================== http://robocup.rwth-aachen.de RWTH Aachen University http://kbsg.rwth-aachen.de Ahornstrasse 55 http://www.fawkesrobotics.org D-52056 Aachen From kollathodi at yahoo.com Wed Jan 4 09:20:37 2012 From: kollathodi at yahoo.com (nasir nasir) Date: Wed, 4 Jan 2012 01:20:37 -0800 (PST) Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <4F037FCE.4@redhat.com> Message-ID: <1325668837.96182.YahooMailClassic@web161305.mail.bf1.yahoo.com> Thanks for all the replies. Rob,Please find the output of your guidelines. # ipa-getcert list Number of certificates and requests being tracked: 3. Request ID '20110619112648':? ? ? ? status: MONITORING? ? ? ? ca-error: Error setting up ccache for local "host" service using default keytab.? ? ? ? stuck: no? ? ? ? key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-COM//pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=xxxxx.COM? ? ? ? subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM? ? ? ? expires: 20111216112647? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yesRequest ID '20110619112705':? ? ? ? status: MONITORING? ? ? ? ca-error: Error setting up ccache for local "host" service using default keytab.? ? ? ? stuck: no? ? ? ? key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=xxxxx.COM? ? ? ? subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM? ? ? ? expires: 20111216112704? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yesRequest ID '20110619112721':? ? ? ? status: MONITORING? ? ? ? ca-error: Error setting up ccache for local "host" service using default keytab.? ? ? ? stuck: no? ? ? ? key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=xxxxx.COM? ? ? ? subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM? ? ? ? expires: 20111216112720 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??? ? ? eku: id-kp-serverAuth ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??? ? ? track: yes ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ? auto-renew: yes ? ? ? ? ? # certutil -L -d /etc/httpd/alias Certificate Nickname ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Trust Attributes ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SSL,S/MIME,JAR/XPIServer-Cert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u,u,uHUGAYET.COM IPA CA ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,C,CipaCert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u,u,uSigning-Cert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u,u,u Now track it # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-CertRequest "20110619112721" modified. #ipa-getcert listNumber of certificates and requests being tracked: 3.Request ID '20110619112648':? ? ? ? status: MONITORING? ? ? ? ca-error: Error setting up ccache for local "host" service using default keytab.? ? ? ? stuck: no? ? ? ? key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-COM//pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=xxxxx.COM? ? ? ? subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM? ? ? ? expires: 20111216112647? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yesRequest ID '20110619112705':? ? ? ? status: MONITORING? ? ? ? ca-error: Error setting up ccache for local "host" service using default keytab.? ? ? ? stuck: no? ? ? ? key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=xxxxx.COM? ? ? ? subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM? ? ? ? expires: 20111216112704? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yesRequest ID '20110619112721':? ? ? ? status: MONITORING? ? ? ? ca-error: Error setting up ccache for local "host" service using default keytab.? ? ? ? stuck: no? ? ? ? key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=xxxxx.COM? ? ? ? subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM? ? ? ? expires: 20111216112720? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yes The issue is still there as you can see the expiry dates are not getting modified. Nidal. --- On Tue, 1/3/12, Rob Crittenden wrote: From: Rob Crittenden Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: "nasir nasir" Cc: "Rich Megginson" , freeipa-users at redhat.com, fasilkaks at gmail.com Date: Tuesday, January 3, 2012, 2:23 PM nasir nasir wrote: > > > --- On *Tue, 1/3/12, Rich Megginson //*wrote: > > >? ???From: Rich Megginson >? ???Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ???To: "nasir nasir" >? ???Cc: freeipa-users at redhat.com, fasilkaks at gmail.com >? ???Date: Tuesday, January 3, 2012, 7:41 AM > >? ???On 01/03/2012 12:52 AM, nasir nasir wrote: >>? ???Hi, >> >>? ???I am facing a serious issue with my production IPA server. When I >>? ???try to access IPA web interface using Firefox, it hangs and >>? ???doesn't allow me to get in. It seems to be due to expired SSL >>? ???certificate as seen in the apache log file, >> >> >>? ???[Tue Jan 03 10:34:08 2012] [error] Certificate not verified: >>? ???'Server-Cert' >>? ???[Tue Jan 03 10:34:08 2012] [error] SSL Library Error: -8181 >>? ???Certificate has expired >>? ???[Tue Jan 03 10:34:08 2012] [error] Unable to verify certificate >>? ???'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the >>? ???server can start until the problem can be resolved. >>? ???[Tue Jan 03 10:34:08 2012] [error] Certificate not verified: >>? ???'Server-Cert' >> >> >>? ???Also, when I try to use the command line (ipa user-mod or >>? ???user-show commands) it too just hangs and doesn't give any output >>? ???or allow me for any input. I can see the following in krb5kdc.log , >> >>? ???Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): preauth >>? ???(timestamp) verify failure: Decrypt integrity check failed >>? ???Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): AS_REQ (4 >>? ???etypes {18 17 16 23}) 192.168.1.10: PREAUTH_FAILED: >>? ???host/xxxxx.xxxxx.com at XXXXXX.COM >>? ??? for >>? ???krbtgt/XXXXXX.COM at XXXXXX.COM >>? ???, Decrypt integrity >>? ???check failed >>? ???Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2429](info): AS_REQ (4 >>? ???etypes {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: >>? ???host/xxxx.xxxxx.com at XXXXX.COM >>? ??? for >>? ???krbtgt/XXXXXX.COM at XXXXXX.COM >>? ???, Additional >>? ???pre-authentication required >> >> >>? ???The output of "certutil -L -d /etc/httpd/alias -n Server-Cert" >>? ???confirms that certificate is expired as given below. >> >>? ???Certificate: >>? ???Data: >>? ???Version: 3 (0x2) >>? ???Serial Number: 10 (0xa) >>? ???Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>? ???Issuer: "CN=Certificate Authority,O=XXXXXX.COM" >>? ???Validity: >>? ???Not Before: Sun Jun 19 11:27:20 2011 >>? ???Not After : Fri Dec 16 11:27:20 2011 >> >> >>? ???Relevant info >> >>? ???OS: RHEL 6.1 >> >> >>? ???Output of rpm -qa | grep ipa >> >>? ???ipa-client-2.0.0-23.el6.i686 >>? ???ipa-pki-ca-theme-9.0.3-6.el6.noarch >>? ???ipa-pki-common-theme-9.0.3-6.el6.noarch >>? ???device-mapper-multipath-libs-0.4.9-41.el6.i686 >>? ???python-iniparse-0.3.1-2.1.el6.noarch >>? ???ipa-python-2.0.0-23.el6.i686 >>? ???ipa-server-selinux-2.0.0-23.el6.i686 >>? ???ipa-server-2.0.0-23.el6.i686 >>? ???device-mapper-multipath-0.4.9-41.el6.i686 >>? ???ipa-admintools-2.0.0-23.el6.i686 >> >> >>? ???I went through the documentations to check how to renew the >>? ???expired certs but it seems to be confusing and different across >>? ???versions. Could someone please help me out by suggesting which is >>? ???the best way to achieve this ? Any help would be greatly >>? ???appreciated as I am unable to perform any task on the IPA server >>? ???now because of this. >> >? ???I suggest following the mod_nss suggestion to allow it to start and >? ???use the expired cert while you attempt to figure this out. > >? ???Thanks indeed for the suggestion. I will consider this. But can >? ???anyone point me the steps to renew certificate from the expired one ? > >? ???Thankds and regards, >? ???Nidal Lets start with figuring out why certmonger didn't do this for you: Can you run as root: ipa-getcert list You should have something like: Request ID '20111215203350': ? ? ? ???status: MONITORING ? ? ? ???stuck: no ? ? ? ???key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' ? ? ? ???certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' ? ? ? ???CA: IPA ? ? ? ???issuer: CN=EXAMPLE.COM Certificate Authority ? ? ? ???subject: CN=rawhide.example.com,O=EXAMPLE.COM ? ? ? ???expires: 2021-12-15 20:33:50 UTC ? ? ? ???track: yes ? ? ? ???auto-renew: yes If you don't have something like this then perhaps the easiest way to get it renewed is to tell certmonger to track it. First, look at your current database, it should look something like: # certutil -L -d /etc/httpd/alias Server-Cert? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u,u,u EXAMPLE.COM IPA CA? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???CTu,u,Cu Signing-Cert? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???u,u,u Now track it # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert Use ipa-getcert list to track the status of the renewal. Once it has been completed you can reset the EnforceValidCerts option and restart Apache. If certmonger is already tracking the cert and the renewal has failed then please provide the ipa-getcert list output. rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa at noboost.org Wed Jan 4 10:38:50 2012 From: freeipa at noboost.org (Craig T) Date: Wed, 4 Jan 2012 21:38:50 +1100 Subject: [Freeipa-users] Host Based Access Control and Solaris? Message-ID: <20120104103850.GA28144@noboost.org> Hi, Server: RHEL6.2 Spec: ipa-server-2.1.3-9 1) After reading the IPA documentation, it seems that HBAC is only available to SSSD clients. This would suggest that I'm not going to be able to configure it for Solaris hosts? "Using host-based access control requires SSSD to be installed and configured on the IPA client machine." 2) Does this mean that I won't be able to control "who" can log onto our solaris servers? Perhaps I'll have to configure a custom /etc/hosts.deny entry? cya Craig From sigbjorn at nixtra.com Wed Jan 4 10:59:39 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 4 Jan 2012 11:59:39 +0100 (CET) Subject: [Freeipa-users] Host Based Access Control and Solaris? In-Reply-To: <20120104103850.GA28144@noboost.org> References: <20120104103850.GA28144@noboost.org> Message-ID: <19128.213.225.75.97.1325674779.squirrel@www.nixtra.com> Hi, You can create netgroups for your Solaris machines. (Example: "ng_ssh_solaris"). Use these netgroups when creating your /etc/hosts.allow and /etc/hosts.deny files on Solaris. For your Linux machines, create HBAC groups. (Example: "hbac_ssh_linux"), and apply a HBAC profile to this HBAC group. Create an user group (Example: "ssh_access"). Add this user group to both the HBAC group and the netgroup you just created. You can now control access to services on both Linux and Solaris simply by adding and removing users to a single user group, without using SSSD on Solaris. SSSD would still be nice to see by default in Solaris, but I don't think that will happen in the near future. Please also have a look at the following bugzilla report for a bug, and a workaround for it, in the netgroup compat plugin. https://bugzilla.redhat.com/show_bug.cgi?id=767372 Regards, Siggi On Wed, January 4, 2012 11:38, Craig T wrote: > Hi, > > > Server: RHEL6.2 > Spec: ipa-server-2.1.3-9 > > > 1) After reading the IPA documentation, it seems that HBAC is only available to SSSD clients. > This would suggest that I'm not going to be able to configure it for Solaris hosts? > "Using host-based access control requires SSSD to be installed and configured on the IPA client > machine." > > 2) Does this mean that I won't be able to control "who" can log onto our solaris servers? Perhaps > I'll have to configure a custom /etc/hosts.deny entry? > > > cya > > Craig > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > From JR.Aquino at citrix.com Wed Jan 4 14:29:54 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Wed, 4 Jan 2012 14:29:54 +0000 Subject: [Freeipa-users] Host Based Access Control and Solaris? In-Reply-To: <20120104103850.GA28144@noboost.org> References: <20120104103850.GA28144@noboost.org> Message-ID: <1D8AA5D4-4AE6-4855-9A6A-5EB1B4360844@citrix.com> On Jan 4, 2012, at 2:39 AM, "Craig T" wrote: > Hi, > > Server: RHEL6.2 > Spec: ipa-server-2.1.3-9 > > 1) After reading the IPA documentation, it seems that HBAC is only available to SSSD clients. This would suggest that I'm not going to be able to configure it for Solaris hosts? > "Using host-based access control requires SSSD to be installed and configured on the IPA client > machine." I have written a custom python Pam module that fully supports HBAC in Linux, however, it utilizes http://ace-host.stuart.id.au/russell/files/pam_python/. Which is currently not OpenPAM compatible. I've been seeking help to find someone to port it to OpenPAM since that is what the BSD's, Solaris, and MacOSX use, but I haven't had any luck so far. > > 2) Does this mean that I won't be able to control "who" can log onto our solaris servers? Perhaps I'll have to configure a custom /etc/hosts.deny entry? > > cya > > Craig > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Wed Jan 4 18:17:53 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Jan 2012 13:17:53 -0500 Subject: [Freeipa-users] Hot Backup Solution for IPA 2.x? In-Reply-To: <20111228010119.GA32480@noboost.org> References: <20111228010119.GA32480@noboost.org> Message-ID: <4F0497D1.8090305@redhat.com> On 12/27/2011 08:01 PM, Craig T wrote: > Hi, > > Is there a hot backup technique for IPA? From my reading the best solution is to setup a replication server then shut the replication server down and do a backup? > > cya > > Craig > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > There is no good IPA specific backup technique. You can use full system backup methodology in combination with the replication. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Jan 4 18:24:00 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Jan 2012 13:24:00 -0500 Subject: [Freeipa-users] Hot Backup Solution for IPA 2.x? In-Reply-To: <4EFB532F.8030902@gmail.com> References: <20111228010119.GA32480@noboost.org> <4EFB532F.8030902@gmail.com> Message-ID: <4F049940.7000807@redhat.com> On 12/28/2011 12:34 PM, Erinn Looney-Triggs wrote: > On 12/27/2011 04:01 PM, Craig T wrote: >> Hi, >> >> Is there a hot backup technique for IPA? From my reading the best solution is to setup a replication server then shut the replication server down and do a backup? >> >> cya >> >> Craig >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > Yeah this seems to be a bit of a problem. I am currently working through > the same thing and all I can find is advice like, "back everything up", > because there are files used by IPA all over the place. That seems a bit > ridiculous to me, so I am trying to piece together what it really does, > and what files are really needed. > > One part I have found so far is the hot backups for the directory > servers (note the plural, PKI has its own instance). You need to use the > db2bak.pl (not the db2bak script which requires dirsrv to be stopped) > script to do a hot backup of the directory server. The general idea can > be found in these docs here: > > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Backing_Up_and_Restoring_Data.html > > > Under section 4.3.1.2. Unfortunately, those docs are wrong about how to > run the db2bak.pl script, so to figure that out you have to read here: > > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Perl_Scripts.html#Perl_Scripts-db2bak.pl_Create_backup_of_database > > > So far that is all I have, just remember to back up both your domain > instance of the LDAP db, as well as the PKI instance. You can then > easily copy those backup files, using your backup tool of choice. As > well as taking a copy of /etc/dirsrv/ and all it contains. > > -Erinn > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users There are other things like certificates in the NSS database or Kerberso keys in the keytab that you also need to be worried about. There is more than just saving DS instances. You also need to save configuration files. The point is that there is a lot of development doing on and a lot of the parts of the system are touched. We are not ready to create a list of the things IPA touched to get it safely backed up. This is why we recommend other techniques at the moment. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Jan 4 18:24:31 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jan 2012 13:24:31 -0500 Subject: [Freeipa-users] Hot Backup Solution for IPA 2.x? In-Reply-To: <4EFB532F.8030902@gmail.com> References: <20111228010119.GA32480@noboost.org> <4EFB532F.8030902@gmail.com> Message-ID: <4F04995F.5060101@redhat.com> Erinn Looney-Triggs wrote: > On 12/27/2011 04:01 PM, Craig T wrote: >> Hi, >> >> Is there a hot backup technique for IPA? From my reading the best solution is to setup a replication server then shut the replication server down and do a backup? >> >> cya >> >> Craig >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > Yeah this seems to be a bit of a problem. I am currently working through > the same thing and all I can find is advice like, "back everything up", > because there are files used by IPA all over the place. That seems a bit > ridiculous to me, so I am trying to piece together what it really does, > and what files are really needed. > > One part I have found so far is the hot backups for the directory > servers (note the plural, PKI has its own instance). You need to use the > db2bak.pl (not the db2bak script which requires dirsrv to be stopped) > script to do a hot backup of the directory server. The general idea can > be found in these docs here: > > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Backing_Up_and_Restoring_Data.html > > > Under section 4.3.1.2. Unfortunately, those docs are wrong about how to > run the db2bak.pl script, so to figure that out you have to read here: > > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Perl_Scripts.html#Perl_Scripts-db2bak.pl_Create_backup_of_database > > > So far that is all I have, just remember to back up both your domain > instance of the LDAP db, as well as the PKI instance. You can then > easily copy those backup files, using your backup tool of choice. As > well as taking a copy of /etc/dirsrv/ and all it contains. > > -Erinn This covers just one piece of IPA. There are also config files, SSL certificates, etc, for many different services. Backing up is easy. Restoring to a new bare metal machine and having it actually work is hard. Better to back up too much than too little. rob From erinn.looneytriggs at gmail.com Wed Jan 4 18:29:37 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 04 Jan 2012 09:29:37 -0900 Subject: [Freeipa-users] Hot Backup Solution for IPA 2.x? In-Reply-To: <4F04995F.5060101@redhat.com> References: <20111228010119.GA32480@noboost.org> <4EFB532F.8030902@gmail.com> <4F04995F.5060101@redhat.com> Message-ID: <4F049A91.3020503@gmail.com> On 01/04/2012 09:24 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> On 12/27/2011 04:01 PM, Craig T wrote: >>> Hi, >>> >>> Is there a hot backup technique for IPA? From my reading the best >>> solution is to setup a replication server then shut the replication >>> server down and do a backup? >>> >>> cya >>> >>> Craig >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> Yeah this seems to be a bit of a problem. I am currently working through >> the same thing and all I can find is advice like, "back everything up", >> because there are files used by IPA all over the place. That seems a bit >> ridiculous to me, so I am trying to piece together what it really does, >> and what files are really needed. >> >> One part I have found so far is the hot backups for the directory >> servers (note the plural, PKI has its own instance). You need to use the >> db2bak.pl (not the db2bak script which requires dirsrv to be stopped) >> script to do a hot backup of the directory server. The general idea can >> be found in these docs here: >> >> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Backing_Up_and_Restoring_Data.html >> >> >> >> Under section 4.3.1.2. Unfortunately, those docs are wrong about how to >> run the db2bak.pl script, so to figure that out you have to read here: >> >> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Perl_Scripts.html#Perl_Scripts-db2bak.pl_Create_backup_of_database >> >> >> >> So far that is all I have, just remember to back up both your domain >> instance of the LDAP db, as well as the PKI instance. You can then >> easily copy those backup files, using your backup tool of choice. As >> well as taking a copy of /etc/dirsrv/ and all it contains. >> >> -Erinn > > This covers just one piece of IPA. There are also config files, SSL > certificates, etc, for many different services. > > Backing up is easy. Restoring to a new bare metal machine and having it > actually work is hard. Better to back up too much than too little. > > rob Yeah folks, that is why I say "one part". I am pointing out how to deal with one, and only one, piece of your setup. If I had unlimited storage I would back everything up all the time, forever, because more is better than less. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Wed Jan 4 18:30:43 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jan 2012 13:30:43 -0500 Subject: [Freeipa-users] anonymous bind + ipa-install-client failure In-Reply-To: <4EF4F4E0.2060708@opennms.org> References: <4EF3EB90.9060003@opennms.org> <4EF3FB82.1010800@opennms.org> <1324659737.28622.202.camel@willson.li.ssimo.org> <4EF4F4E0.2060708@opennms.org> Message-ID: <4F049AD3.2030301@redhat.com> Benjamin Reed wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/23/11 12:02 PM, Simo Sorce wrote: >> One thing you can test is if the ca.crt exposed via http is the same >> that is stored on the server in /etc/ipa/ca.crt > > they are identical, I did find that the errors file is complaining about > this: > > [22/Dec/2011:21:31:15 -0600] attrcrypt - attrcrypt_unwrap_key: failed to > unwrap key for cipher AES > [22/Dec/2011:21:31:15 -0600] attrcrypt - attrcrypt_cipher_init: > symmetric key failed to unwrap with the private key; Cert might have > been renewed since the key is wrapped. To recover the encrypted > contents, keep the wrapped symmetric key value. > [22/Dec/2011:21:31:15 -0600] attrcrypt - attrcrypt_unwrap_key: failed to > unwrap key for cipher 3DES > [22/Dec/2011:21:31:15 -0600] attrcrypt - attrcrypt_cipher_init: > symmetric key failed to unwrap with the private key; Cert might have > been renewed since the key is wrapped. To recover the encrypted > contents, keep the wrapped symmetric key value. > [22/Dec/2011:21:31:16 -0600] attrcrypt - All prepared ciphers are not > available. Please disable attribute encryption. These are not related. IIRC 389-ds generates symmetric keys automatically when it is first started and if you've replaced your NSS cert db in the meantime those keys are not available. This would only be a problem if you decided to use per-attribute encryption at some future point. You might want to try pulling the CA out of the DS instance and comparing that to what is being served up by the HTTP server: certutil -L -d /etc/dirsrv/slapd-INSTANCE to get the list of certs This to get a specific cert certutil -L -n 'some nickname' -d /etc/dirsrv/slapd-INSTANCE -a > /tmp/dsca.crt The error here is that the client doesn't trust the certificate that 389-ds is using. rob From danieljamesscott at gmail.com Wed Jan 4 18:35:48 2012 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 4 Jan 2012 13:35:48 -0500 Subject: [Freeipa-users] FreeIPA 2.1.4 replication Message-ID: Hi, Recently I've had some crash/hang problems with my FreeIPA 2 installation which appear solved using the updates-testing version of freeipa-server (2.1.4-2.fc16.x86_64) which I'm currently running on both servers (as a quick aside, does anyone know when 2.1.4 will be released to the main repos?). I'm still having problems creating replicas however. The replication process mostly completes, but fails with: Restarting IPA to initialize updates before performing deletes: [1/2]: stopping directory server [2/2]: starting directory server done configuring dirsrv. creation of replica failed: Command '/bin/systemctl restart krb5kdc.service' returned non-zero exit status 1 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. [root at fileserver4 ~]# The replication appears to be working, but I'd like to have the configuration complete successfully to be sure. If I use the --setup-ca option, the process fails even earlier: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/12]: creating certificate server user [2/12]: creating pki-ca instance [3/12]: configuring certificate server instance root : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' 'fileserver4.example.com' '-cs_port' '9445' '-client_certdb_dir' '/tmp/tmp-0h0omd' '-client_certdb_pwd' XXXXXXXX '-preop_pin' 'Vi8OHzzN0yjMDcqMv3aD' '-domain_name' 'IPA' '-admin_user' 'admin' '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' '-agent_key_type' 'rsa' '-agent_cert_subject' 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'fileserver4.example.com' '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name' 'CN=fileserver4.example.com,O=EXAMPLE.COM' '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' '-clone_p12_password' XXXXXXXX '-sd_hostname' 'fileserver1.example.com' '-sd_admin_port' '443' '-sd_admin_name' 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' '-clone_uri' 'https://fileserver1.example.com:443'' returned non-zero exit status 255 creation of replica failed: Configuration of CA failed Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. [root at fileserver4 ~]# I'm running 389-ds-base-1.2.10-0.5.a5.fc16.x86_64, if that helps Can anyone help to fix this? I can send the log file from either attempt to someone if that would help. Thanks, Dan From rmeggins at redhat.com Wed Jan 4 18:36:01 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 04 Jan 2012 11:36:01 -0700 Subject: [Freeipa-users] FreeIPA 2.1.4 replication In-Reply-To: References: Message-ID: <4F049C11.9010206@redhat.com> On 01/04/2012 11:35 AM, Dan Scott wrote: > Hi, > > Recently I've had some crash/hang problems with my FreeIPA 2 > installation which appear solved using the updates-testing version of > freeipa-server (2.1.4-2.fc16.x86_64) which I'm currently running on > both servers (as a quick aside, does anyone know when 2.1.4 will be > released to the main repos?). > > I'm still having problems creating replicas however. The replication > process mostly completes, but fails with: > > Restarting IPA to initialize updates before performing deletes: > [1/2]: stopping directory server > [2/2]: starting directory server > done configuring dirsrv. > creation of replica failed: Command '/bin/systemctl restart > krb5kdc.service' returned non-zero exit status 1 > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > [root at fileserver4 ~]# > > The replication appears to be working, but I'd like to have the > configuration complete successfully to be sure. > > If I use the --setup-ca option, the process fails even earlier: > > Configuring certificate server: Estimated time 3 minutes 30 seconds > [1/12]: creating certificate server user > [2/12]: creating pki-ca instance > [3/12]: configuring certificate server instance > root : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' > 'fileserver4.example.com' '-cs_port' '9445' '-client_certdb_dir' > '/tmp/tmp-0h0omd' '-client_certdb_pwd' XXXXXXXX '-preop_pin' > 'Vi8OHzzN0yjMDcqMv3aD' '-domain_name' 'IPA' '-admin_user' 'admin' > '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX > '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' > '-agent_key_type' 'rsa' '-agent_cert_subject' > 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'fileserver4.example.com' > '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' > XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' > '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' > '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' > 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA > Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP > Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name' > 'CN=fileserver4.example.com,O=EXAMPLE.COM' > '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' > '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' > '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' > '-clone_p12_password' XXXXXXXX '-sd_hostname' > 'fileserver1.example.com' '-sd_admin_port' '443' '-sd_admin_name' > 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' > '-clone_uri' 'https://fileserver1.example.com:443'' returned non-zero > exit status 255 > creation of replica failed: Configuration of CA failed > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > [root at fileserver4 ~]# > > I'm running 389-ds-base-1.2.10-0.5.a5.fc16.x86_64, if that helps try 389-ds-base-1.2.10-0.6.a6.fc16.x86_64 from updates-testing > Can anyone help to fix this? I can send the log file from either > attempt to someone if that would help. > > Thanks, > > Dan > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Wed Jan 4 18:41:12 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Jan 2012 13:41:12 -0500 Subject: [Freeipa-users] Hot Backup Solution for IPA 2.x? In-Reply-To: <4F049A91.3020503@gmail.com> References: <20111228010119.GA32480@noboost.org> <4EFB532F.8030902@gmail.com> <4F04995F.5060101@redhat.com> <4F049A91.3020503@gmail.com> Message-ID: <4F049D48.1050504@redhat.com> On 01/04/2012 01:29 PM, Erinn Looney-Triggs wrote: > On 01/04/2012 09:24 AM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> On 12/27/2011 04:01 PM, Craig T wrote: >>>> Hi, >>>> >>>> Is there a hot backup technique for IPA? From my reading the best >>>> solution is to setup a replication server then shut the replication >>>> server down and do a backup? >>>> >>>> cya >>>> >>>> Craig >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> Yeah this seems to be a bit of a problem. I am currently working through >>> the same thing and all I can find is advice like, "back everything up", >>> because there are files used by IPA all over the place. That seems a bit >>> ridiculous to me, so I am trying to piece together what it really does, >>> and what files are really needed. >>> >>> One part I have found so far is the hot backups for the directory >>> servers (note the plural, PKI has its own instance). You need to use the >>> db2bak.pl (not the db2bak script which requires dirsrv to be stopped) >>> script to do a hot backup of the directory server. The general idea can >>> be found in these docs here: >>> >>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Backing_Up_and_Restoring_Data.html >>> >>> >>> >>> Under section 4.3.1.2. Unfortunately, those docs are wrong about how to >>> run the db2bak.pl script, so to figure that out you have to read here: >>> >>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Perl_Scripts.html#Perl_Scripts-db2bak.pl_Create_backup_of_database >>> >>> >>> >>> So far that is all I have, just remember to back up both your domain >>> instance of the LDAP db, as well as the PKI instance. You can then >>> easily copy those backup files, using your backup tool of choice. As >>> well as taking a copy of /etc/dirsrv/ and all it contains. >>> >>> -Erinn >> This covers just one piece of IPA. There are also config files, SSL >> certificates, etc, for many different services. >> >> Backing up is easy. Restoring to a new bare metal machine and having it >> actually work is hard. Better to back up too much than too little. >> >> rob > Yeah folks, that is why I say "one part". I am pointing out how to deal > with one, and only one, piece of your setup. If I had unlimited storage > I would back everything up all the time, forever, because more is better > than less. > You probably just need to backup one system out of the ring of the servers. It depend upon your requirements and how much activity happens in between the backups. > -Erinn > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Jan 4 18:46:06 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 4 Jan 2012 21:46:06 +0300 Subject: [Freeipa-users] FreeIPA 2.1.4 replication In-Reply-To: <4F049C11.9010206@redhat.com> References: <4F049C11.9010206@redhat.com> Message-ID: <20120104184606.GB24492@redhat.com> On Wed, 04 Jan 2012, Rich Megginson wrote: > >Your system may be partly configured. > >Run /usr/sbin/ipa-server-install --uninstall to clean up. > >[root at fileserver4 ~]# > > > >I'm running 389-ds-base-1.2.10-0.5.a5.fc16.x86_64, if that helps > try > > 389-ds-base-1.2.10-0.6.a6.fc16.x86_64 > from updates-testing That would mean taking in also nss packages (they are in stable already for F16) which will break FreeIPA. If no those breaks from nss (FEDORA-2011-17400 update), we could have 2.1.4 in stable already. Look at http://bugzilla.redhat.com/show_bug.cgi?id=771357 for details. Unfortunately, workarounds are kludgy and require modification deep in Dogtag templates. Backstory for nss part is here https://bugzilla.redhat.com/show_bug.cgi?id=737506 -- / Alexander Bokovoy From rcritten at redhat.com Wed Jan 4 18:48:41 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jan 2012 13:48:41 -0500 Subject: [Freeipa-users] FreeIPA 2.1.4 replication In-Reply-To: References: Message-ID: <4F049F09.8000000@redhat.com> Dan Scott wrote: > Hi, > > Recently I've had some crash/hang problems with my FreeIPA 2 > installation which appear solved using the updates-testing version of > freeipa-server (2.1.4-2.fc16.x86_64) which I'm currently running on > both servers (as a quick aside, does anyone know when 2.1.4 will be > released to the main repos?). > > I'm still having problems creating replicas however. The replication > process mostly completes, but fails with: > > Restarting IPA to initialize updates before performing deletes: > [1/2]: stopping directory server > [2/2]: starting directory server > done configuring dirsrv. > creation of replica failed: Command '/bin/systemctl restart > krb5kdc.service' returned non-zero exit status 1 You'd need to see why the kdc is failing to start. /var/log/krb5kdc.log is a place to start. dmesg/messages may have info, as well as systemctl status service.krb5kdc. > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > [root at fileserver4 ~]# > > The replication appears to be working, but I'd like to have the > configuration complete successfully to be sure. > > If I use the --setup-ca option, the process fails even earlier: > > Configuring certificate server: Estimated time 3 minutes 30 seconds > [1/12]: creating certificate server user > [2/12]: creating pki-ca instance > [3/12]: configuring certificate server instance > root : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' > 'fileserver4.example.com' '-cs_port' '9445' '-client_certdb_dir' > '/tmp/tmp-0h0omd' '-client_certdb_pwd' XXXXXXXX '-preop_pin' > 'Vi8OHzzN0yjMDcqMv3aD' '-domain_name' 'IPA' '-admin_user' 'admin' > '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX > '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' > '-agent_key_type' 'rsa' '-agent_cert_subject' > 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'fileserver4.example.com' > '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' > XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' > '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' > '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' > 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA > Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP > Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name' > 'CN=fileserver4.example.com,O=EXAMPLE.COM' > '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' > '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' > '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' > '-clone_p12_password' XXXXXXXX '-sd_hostname' > 'fileserver1.example.com' '-sd_admin_port' '443' '-sd_admin_name' > 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' > '-clone_uri' 'https://fileserver1.example.com:443'' returned non-zero > exit status 255 > creation of replica failed: Configuration of CA failed You need to look in /var/log/pki-ca/debug to determine where it failed. IIRC the last time we looked at this there was some issue with the security domain. rob > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > [root at fileserver4 ~]# > > I'm running 389-ds-base-1.2.10-0.5.a5.fc16.x86_64, if that helps > > Can anyone help to fix this? I can send the log file from either > attempt to someone if that would help. > > Thanks, > > Dan > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Wed Jan 4 19:52:02 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jan 2012 14:52:02 -0500 Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <1325668837.96182.YahooMailClassic@web161305.mail.bf1.yahoo.com> References: <1325668837.96182.YahooMailClassic@web161305.mail.bf1.yahoo.com> Message-ID: <4F04ADE2.6080505@redhat.com> nasir nasir wrote: > Thanks for all the replies. > > Rob, > Please find the output of your guidelines. Here is the culprit: ca-error: Error setting up ccache for local "host" service using default keytab. certmonger authenticates to IPA using the host service principal installed on each client (and master). For some reason that can't be used. Check the keytab: # klist -kt /etc/krb5.keytab If there are host entries there, try it: # kinit -kt /etc/krb5.keytab host/server.example.com rob > > # ipa-getcert list > Number of certificates and requests being tracked: 3. > Request ID '20110619112648': > status: MONITORING > ca-error: Error setting up ccache for local "host" service using default > keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-COM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxx.COM > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > expires: 20111216112647 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112705': > status: MONITORING > ca-error: Error setting up ccache for local "host" service using default > keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxx.COM > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > expires: 20111216112704 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112721': > status: MONITORING > ca-error: Error setting up ccache for local "host" service using default > keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxx.COM > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > expires: 20111216112720 eku: id-kp-serverAuth track: yes > auto-renew: yes > > # certutil -L -d /etc/httpd/alias > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > Server-Cert u,u,u > HUGAYET.COM IPA CA CT,C,C > ipaCert u,u,u > Signing-Cert u,u,u > > Now track it > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert > Request "20110619112721" modified. > > #ipa-getcert list > Number of certificates and requests being tracked: 3. > Request ID '20110619112648': > status: MONITORING > ca-error: Error setting up ccache for local "host" service using default > keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-COM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxx.COM > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > expires: 20111216112647 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112705': > status: MONITORING > ca-error: Error setting up ccache for local "host" service using default > keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxx.COM > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > expires: 20111216112704 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112721': > status: MONITORING > ca-error: Error setting up ccache for local "host" service using default > keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxx.COM > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > expires: 20111216112720 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > > The issue is still there as you can see the expiry dates are not getting > modified. > > Nidal. > > --- On *Tue, 1/3/12, Rob Crittenden //* wrote: > > > From: Rob Crittenden > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > To: "nasir nasir" > Cc: "Rich Megginson" , > freeipa-users at redhat.com, fasilkaks at gmail.com > Date: Tuesday, January 3, 2012, 2:23 PM > > nasir nasir wrote: > > > > > > --- On *Tue, 1/3/12, Rich Megginson / >/*wrote: > > > > > > From: Rich Megginson > > > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > > To: "nasir nasir" > > > Cc: freeipa-users at redhat.com > , fasilkaks at gmail.com > > > Date: Tuesday, January 3, 2012, 7:41 AM > > > > On 01/03/2012 12:52 AM, nasir nasir wrote: > >> Hi, > >> > >> I am facing a serious issue with my production IPA server. When I > >> try to access IPA web interface using Firefox, it hangs and > >> doesn't allow me to get in. It seems to be due to expired SSL > >> certificate as seen in the apache log file, > >> > >> > >> [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: > >> 'Server-Cert' > >> [Tue Jan 03 10:34:08 2012] [error] SSL Library Error: -8181 > >> Certificate has expired > >> [Tue Jan 03 10:34:08 2012] [error] Unable to verify certificate > >> 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the > >> server can start until the problem can be resolved. > >> [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: > >> 'Server-Cert' > >> > >> > >> Also, when I try to use the command line (ipa user-mod or > >> user-show commands) it too just hangs and doesn't give any output > >> or allow me for any input. I can see the following in krb5kdc.log , > >> > >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): preauth > >> (timestamp) verify failure: Decrypt integrity check failed > >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): AS_REQ (4 > >> etypes {18 17 16 23}) 192.168.1.10: PREAUTH_FAILED: > >> host/xxxxx.xxxxx.com at XXXXXX.COM > > >> > for > >> krbtgt/XXXXXX.COM at XXXXXX.COM > >> >, Decrypt integrity > >> check failed > >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2429](info): AS_REQ (4 > >> etypes {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: > >> host/xxxx.xxxxx.com at XXXXX.COM > > >> > for > >> krbtgt/XXXXXX.COM at XXXXXX.COM > >> >, Additional > >> pre-authentication required > >> > >> > >> The output of "certutil -L -d /etc/httpd/alias -n Server-Cert" > >> confirms that certificate is expired as given below. > >> > >> Certificate: > >> Data: > >> Version: 3 (0x2) > >> Serial Number: 10 (0xa) > >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption > >> Issuer: "CN=Certificate Authority,O=XXXXXX.COM" > >> Validity: > >> Not Before: Sun Jun 19 11:27:20 2011 > >> Not After : Fri Dec 16 11:27:20 2011 > >> > >> > >> Relevant info > >> > >> OS: RHEL 6.1 > >> > >> > >> Output of rpm -qa | grep ipa > >> > >> ipa-client-2.0.0-23.el6.i686 > >> ipa-pki-ca-theme-9.0.3-6.el6.noarch > >> ipa-pki-common-theme-9.0.3-6.el6.noarch > >> device-mapper-multipath-libs-0.4.9-41.el6.i686 > >> python-iniparse-0.3.1-2.1.el6.noarch > >> ipa-python-2.0.0-23.el6.i686 > >> ipa-server-selinux-2.0.0-23.el6.i686 > >> ipa-server-2.0.0-23.el6.i686 > >> device-mapper-multipath-0.4.9-41.el6.i686 > >> ipa-admintools-2.0.0-23.el6.i686 > >> > >> > >> I went through the documentations to check how to renew the > >> expired certs but it seems to be confusing and different across > >> versions. Could someone please help me out by suggesting which is > >> the best way to achieve this ? Any help would be greatly > >> appreciated as I am unable to perform any task on the IPA server > >> now because of this. > >> > > I suggest following the mod_nss suggestion to allow it to start and > > use the expired cert while you attempt to figure this out. > > > > Thanks indeed for the suggestion. I will consider this. But can > > anyone point me the steps to renew certificate from the expired one ? > > > > Thankds and regards, > > Nidal > > Lets start with figuring out why certmonger didn't do this for you: > > Can you run as root: ipa-getcert list > > You should have something like: > > Request ID '20111215203350': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB' > CA: IPA > issuer: CN=EXAMPLE.COM Certificate Authority > subject: CN=rawhide.example.com,O=EXAMPLE.COM > expires: 2021-12-15 20:33:50 UTC > track: yes > auto-renew: yes > > If you don't have something like this then perhaps the easiest way to > get it renewed is to tell certmonger to track it. First, look at your > current database, it should look something like: > > # certutil -L -d /etc/httpd/alias > > Server-Cert u,u,u > EXAMPLE.COM IPA CA CTu,u,Cu > Signing-Cert u,u,u > > Now track it > > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert > > Use ipa-getcert list to track the status of the renewal. Once it has > been completed you can reset the EnforceValidCerts option and restart > Apache. > > If certmonger is already tracking the cert and the renewal has failed > then please provide the ipa-getcert list output. > > rob > From nalin at redhat.com Wed Jan 4 21:13:26 2012 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 4 Jan 2012 16:13:26 -0500 Subject: [Freeipa-users] NIS maps via FreeIPA In-Reply-To: References: Message-ID: <20120104211326.GB20180@redhat.com> On Tue, Dec 27, 2011 at 09:06:22AM -0500, Boris Epstein wrote: > How do I control which NIS maps FreeIPA makes available? Specifically > I may need?passwd.byname. The the set of maps that the NIS service provides is controlled by the entries listed under the directory server's configuration entry for the plugin (cn=NIS Server, cn=plugins, cn=config), and they're typically named "nis-domain=$DOMAIN+nis-map=$MAP". To remove a map (or a whole domain), you can remove the entries, either by stopping the directory server and editing its dse.ldif file directly, or by using the 'ldapdelete' command, like so: ldapdelete -H ldaps://ipa.example.com -D 'cn=Directory Manager' -x \ "nis-domain=$DOMAIN+nis-map=$MAP,cn=NIS Server,cn=plugins,cn=config" To add a map, you'd create an entry for the map and define how the NIS server plugin will massage the contents of directory server entries to create entries in the map -- there are predefined defaults for a number of maps, so you don't often need to do that, but it's there's more to it than I can fully describe here. The documentation in the slapi-nis package should cover it in depth, though. > Also, how do I control what sort of encryption it uses for passwords? I'm assuming you're referring to how user passwords are hashed. The directory server component uses the value of the "passwordStorageScheme" attribute in the "cn=config" entry to control how it hashes passwords. The default should be "SSHA" if it's not set, but I'm guessing you'll want to try "CRYPT" (without quotes). It won't affect any passwords that have already been set, but it should affect passwords changes made in the future. HTH, Nalin From kollathodi at yahoo.com Wed Jan 4 21:50:36 2012 From: kollathodi at yahoo.com (nasir nasir) Date: Wed, 4 Jan 2012 13:50:36 -0800 (PST) Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <4F04ADE2.6080505@redhat.com> Message-ID: <1325713836.74625.YahooMailClassic@web161301.mail.bf1.yahoo.com> Thanks for the reply Rob, Indeed there are host entries.Please find below the output of your below mentioned guidelines. # klist -kt /etc/krb5.keytabKeytab name: WRFILE:/etc/krb5.keytabKVNO Timestamp ? ? ? ? Principal---- ----------------- --------------------------------------------------------? ?2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM? ?2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM? ?2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM? ?2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM? ?2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM? ?2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM? ?2 06/20/11 09:07:26 host/test1.xxxxxx.com at xxxxxx.COM? ?2 06/20/11 09:07:26 host/test1.xxxxxx.com at xxxxxx.COM? ?2 06/20/11 09:07:26 host/test1.xxxxxx.com at xxxxxx.COM? ?2 06/20/11 09:07:26 host/test1.xxxxxx.com at xxxxxx.COM? ?6 06/20/11 09:09:12 nfs/nfs.xxxxxx.com at xxxxxx.COM? ?6 06/20/11 09:09:12 nfs/nfs.xxxxxx.com at xxxxxx.COM? ?6 06/20/11 09:09:12 nfs/nfs.xxxxxx.com at xxxxxx.COM? ?6 06/20/11 09:09:12 nfs/nfs.xxxxxx.com at xxxxxx.COM? ?2 06/20/11 09:11:24 nfs/test1.xxxxxx.com at xxxxxx.COM? ?2 06/20/11 09:11:24 nfs/test1.xxxxxx.com at xxxxxx.COM? ?2 06/20/11 09:11:24 nfs/test1.xxxxxx.com at xxxxxx.COM? ?2 06/20/11 09:11:24 nfs/test1.xxxxxx.com at xxxxxx.COM # kinit -kt /etc/krb5.keytab host/openipa.hugayet.comkinit: Password incorrect while getting initial credentials # kinit admin(the password is accepted successfully here) # kinit -kt /etc/krb5.keytab host/openipa.hugayet.comkinit: Password incorrect while getting initial credentials What could be the possible issue of the invalid credential error? Please help. Nidal--- On Wed, 1/4/12, Rob Crittenden wrote: From: Rob Crittenden Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: "nasir nasir" Cc: "Rich Megginson" , freeipa-users at redhat.com, fasilkaks at gmail.com Date: Wednesday, January 4, 2012, 11:52 AM nasir nasir wrote: > Thanks for all the replies. > > Rob, > Please find the output of your guidelines. Here is the culprit: ca-error: Error setting up ccache for local "host" service using default keytab. certmonger authenticates to IPA using the host service principal installed on each client (and master). For some reason that can't be used. Check the keytab: # klist -kt /etc/krb5.keytab If there are host entries there, try it: # kinit -kt /etc/krb5.keytab host/server.example.com rob > > # ipa-getcert list > Number of certificates and requests being tracked: 3. > Request ID '20110619112648': > status: MONITORING > ca-error: Error setting up ccache for local "host" service using default > keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-COM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxx.COM > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > expires: 20111216112647 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112705': > status: MONITORING > ca-error: Error setting up ccache for local "host" service using default > keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxx.COM > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > expires: 20111216112704 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112721': > status: MONITORING > ca-error: Error setting up ccache for local "host" service using default > keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxx.COM > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > expires: 20111216112720 eku: id-kp-serverAuth track: yes > auto-renew: yes > > # certutil -L -d /etc/httpd/alias > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > Server-Cert u,u,u > HUGAYET.COM IPA CA CT,C,C > ipaCert u,u,u > Signing-Cert u,u,u > > Now track it > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert > Request "20110619112721" modified. > > #ipa-getcert list > Number of certificates and requests being tracked: 3. > Request ID '20110619112648': > status: MONITORING > ca-error: Error setting up ccache for local "host" service using default > keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-COM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxx.COM > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > expires: 20111216112647 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112705': > status: MONITORING > ca-error: Error setting up ccache for local "host" service using default > keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxx.COM > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > expires: 20111216112704 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112721': > status: MONITORING > ca-error: Error setting up ccache for local "host" service using default > keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxx.COM > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > expires: 20111216112720 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > > The issue is still there as you can see the expiry dates are not getting > modified. > > Nidal. > > --- On *Tue, 1/3/12, Rob Crittenden //* wrote: > > >? ???From: Rob Crittenden >? ???Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ???To: "nasir nasir" >? ???Cc: "Rich Megginson" , >? ???freeipa-users at redhat.com, fasilkaks at gmail.com >? ???Date: Tuesday, January 3, 2012, 2:23 PM > >? ???nasir nasir wrote: >? ? ? > >? ? ? > >? ? ? > --- On *Tue, 1/3/12, Rich Megginson /? ???>/*wrote: >? ? ? > >? ? ? > >? ? ? > From: Rich Megginson ? ???> >? ? ? > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ? ? > To: "nasir nasir" ? ???> >? ? ? > Cc: freeipa-users at redhat.com >? ???, fasilkaks at gmail.com >? ??? >? ? ? > Date: Tuesday, January 3, 2012, 7:41 AM >? ? ? > >? ? ? > On 01/03/2012 12:52 AM, nasir nasir wrote: >? ? ? >> Hi, >? ? ? >> >? ? ? >> I am facing a serious issue with my production IPA server. When I >? ? ? >> try to access IPA web interface using Firefox, it hangs and >? ? ? >> doesn't allow me to get in. It seems to be due to expired SSL >? ? ? >> certificate as seen in the apache log file, >? ? ? >> >? ? ? >> >? ? ? >> [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: >? ? ? >> 'Server-Cert' >? ? ? >> [Tue Jan 03 10:34:08 2012] [error] SSL Library Error: -8181 >? ? ? >> Certificate has expired >? ? ? >> [Tue Jan 03 10:34:08 2012] [error] Unable to verify certificate >? ? ? >> 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the >? ? ? >> server can start until the problem can be resolved. >? ? ? >> [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: >? ? ? >> 'Server-Cert' >? ? ? >> >? ? ? >> >? ? ? >> Also, when I try to use the command line (ipa user-mod or >? ? ? >> user-show commands) it too just hangs and doesn't give any output >? ? ? >> or allow me for any input. I can see the following in krb5kdc.log , >? ? ? >> >? ? ? >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): preauth >? ? ? >> (timestamp) verify failure: Decrypt integrity check failed >? ? ? >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): AS_REQ (4 >? ? ? >> etypes {18 17 16 23}) 192.168.1.10: PREAUTH_FAILED: >? ? ? >> host/xxxxx.xxxxx.com at XXXXXX.COM >? ??? >? ? ? >> ? ???> for >? ? ? >> krbtgt/XXXXXX.COM at XXXXXX.COM >? ? ? >> ? ???>, Decrypt integrity >? ? ? >> check failed >? ? ? >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2429](info): AS_REQ (4 >? ? ? >> etypes {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: >? ? ? >> host/xxxx.xxxxx.com at XXXXX.COM >? ??? >? ? ? >> ? ???> for >? ? ? >> krbtgt/XXXXXX.COM at XXXXXX.COM >? ? ? >> ? ???>, Additional >? ? ? >> pre-authentication required >? ? ? >> >? ? ? >> >? ? ? >> The output of "certutil -L -d /etc/httpd/alias -n Server-Cert" >? ? ? >> confirms that certificate is expired as given below. >? ? ? >> >? ? ? >> Certificate: >? ? ? >> Data: >? ? ? >> Version: 3 (0x2) >? ? ? >> Serial Number: 10 (0xa) >? ? ? >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >? ? ? >> Issuer: "CN=Certificate Authority,O=XXXXXX.COM" >? ? ? >> Validity: >? ? ? >> Not Before: Sun Jun 19 11:27:20 2011 >? ? ? >> Not After : Fri Dec 16 11:27:20 2011 >? ? ? >> >? ? ? >> >? ? ? >> Relevant info >? ? ? >> >? ? ? >> OS: RHEL 6.1 >? ? ? >> >? ? ? >> >? ? ? >> Output of rpm -qa | grep ipa >? ? ? >> >? ? ? >> ipa-client-2.0.0-23.el6.i686 >? ? ? >> ipa-pki-ca-theme-9.0.3-6.el6.noarch >? ? ? >> ipa-pki-common-theme-9.0.3-6.el6.noarch >? ? ? >> device-mapper-multipath-libs-0.4.9-41.el6.i686 >? ? ? >> python-iniparse-0.3.1-2.1.el6.noarch >? ? ? >> ipa-python-2.0.0-23.el6.i686 >? ? ? >> ipa-server-selinux-2.0.0-23.el6.i686 >? ? ? >> ipa-server-2.0.0-23.el6.i686 >? ? ? >> device-mapper-multipath-0.4.9-41.el6.i686 >? ? ? >> ipa-admintools-2.0.0-23.el6.i686 >? ? ? >> >? ? ? >> >? ? ? >> I went through the documentations to check how to renew the >? ? ? >> expired certs but it seems to be confusing and different across >? ? ? >> versions. Could someone please help me out by suggesting which is >? ? ? >> the best way to achieve this ? Any help would be greatly >? ? ? >> appreciated as I am unable to perform any task on the IPA server >? ? ? >> now because of this. >? ? ? >> >? ? ? > I suggest following the mod_nss suggestion to allow it to start and >? ? ? > use the expired cert while you attempt to figure this out. >? ? ? > >? ? ? > Thanks indeed for the suggestion. I will consider this. But can >? ? ? > anyone point me the steps to renew certificate from the expired one ? >? ? ? > >? ? ? > Thankds and regards, >? ? ? > Nidal > >? ???Lets start with figuring out why certmonger didn't do this for you: > >? ???Can you run as root: ipa-getcert list > >? ???You should have something like: > >? ???Request ID '20111215203350': >? ???status: MONITORING >? ???stuck: no >? ???key pair storage: >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > >? ???Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ???certificate: >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > >? ???Certificate DB' >? ???CA: IPA >? ???issuer: CN=EXAMPLE.COM Certificate Authority >? ???subject: CN=rawhide.example.com,O=EXAMPLE.COM >? ???expires: 2021-12-15 20:33:50 UTC >? ???track: yes >? ???auto-renew: yes > >? ???If you don't have something like this then perhaps the easiest way to >? ???get it renewed is to tell certmonger to track it. First, look at your >? ???current database, it should look something like: > >? ???# certutil -L -d /etc/httpd/alias > >? ???Server-Cert u,u,u >? ???EXAMPLE.COM IPA CA CTu,u,Cu >? ???Signing-Cert u,u,u > >? ???Now track it > >? ???# ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert > >? ???Use ipa-getcert list to track the status of the renewal. Once it has >? ???been completed you can reset the EnforceValidCerts option and restart >? ???Apache. > >? ???If certmonger is already tracking the cert and the renewal has failed >? ???then please provide the ipa-getcert list output. > >? ???rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Jan 4 22:40:31 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jan 2012 17:40:31 -0500 Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <1325713836.74625.YahooMailClassic@web161301.mail.bf1.yahoo.com> References: <1325713836.74625.YahooMailClassic@web161301.mail.bf1.yahoo.com> Message-ID: <4F04D55F.9090104@redhat.com> nasir nasir wrote: > Thanks for the reply Rob, > > Indeed there are host entries. > Please find below the output of your below mentioned guidelines. > > # klist -kt /etc/krb5.keytab > Keytab name: WRFILE:/etc/krb5.keytab > KVNO Timestamp Principal > ---- ----------------- > -------------------------------------------------------- > 2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM > 2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM > 2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM > 2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM > 2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM > 2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:07:26 host/test1.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:07:26 host/test1.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:07:26 host/test1.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:07:26 host/test1.xxxxxx.com at xxxxxx.COM > 6 06/20/11 09:09:12 nfs/nfs.xxxxxx.com at xxxxxx.COM > 6 06/20/11 09:09:12 nfs/nfs.xxxxxx.com at xxxxxx.COM > 6 06/20/11 09:09:12 nfs/nfs.xxxxxx.com at xxxxxx.COM > 6 06/20/11 09:09:12 nfs/nfs.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:11:24 nfs/test1.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:11:24 nfs/test1.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:11:24 nfs/test1.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:11:24 nfs/test1.xxxxxx.com at xxxxxx.COM > > # kinit -kt /etc/krb5.keytab host/openipa.hugayet.com > kinit: Password incorrect while getting initial credentials > > # kinit admin > (the password is accepted successfully here) > > # kinit -kt /etc/krb5.keytab host/openipa.hugayet.com > kinit: Password incorrect while getting initial credentials > > What could be the possible issue of the invalid credential error? Please > help. Probably the most expedient fix is to use ipa-getkeytab to get new credentials for the host service. Here is an example assuming you need a new keytab for your freeIPA server itself: # ipa-getkeytab -s ipa.example.com -p host/ipa.example.com -k /etc/krb5.keytab rob > > Nidal > --- On *Wed, 1/4/12, Rob Crittenden / */.com>/* wrote: > > > From: Rob Crittenden > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > To: "nasir nasir" > Cc: "Rich Megginson" , > freeipa-users at redhat.com, fasilkaks at gmail.com > Date: Wednesday, January 4, 2012, 11:52 AM > > nasir nasir wrote: > > Thanks for all the replies. > > > > Rob, > > Please find the output of your guidelines. > > Here is the culprit: > > ca-error: Error setting up ccache for local "host" service using > default > keytab. > > certmonger authenticates to IPA using the host service principal > installed on each client (and master). For some reason that can't be > used. > > Check the keytab: > > # klist -kt /etc/krb5.keytab > > If there are host entries there, try it: > > # kinit -kt /etc/krb5.keytab host/server.example.com > > rob > > > > > # ipa-getcert list > > Number of certificates and requests being tracked: 3. > > Request ID '20110619112648': > > status: MONITORING > > ca-error: Error setting up ccache for local "host" service using > default > > keytab. > > stuck: no > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-COM//pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=xxxxx.COM > > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > > expires: 20111216112647 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > Request ID '20110619112705': > > status: MONITORING > > ca-error: Error setting up ccache for local "host" service using > default > > keytab. > > stuck: no > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=xxxxx.COM > > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > > expires: 20111216112704 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > Request ID '20110619112721': > > status: MONITORING > > ca-error: Error setting up ccache for local "host" service using > default > > keytab. > > stuck: no > > key pair storage: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=xxxxx.COM > > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > > expires: 20111216112720 eku: id-kp-serverAuth track: yes > > auto-renew: yes > > > > # certutil -L -d /etc/httpd/alias > > Certificate Nickname Trust Attributes > > SSL,S/MIME,JAR/XPI > > Server-Cert u,u,u > > HUGAYET.COM IPA CA CT,C,C > > ipaCert u,u,u > > Signing-Cert u,u,u > > > > Now track it > > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert > > Request "20110619112721" modified. > > > > #ipa-getcert list > > Number of certificates and requests being tracked: 3. > > Request ID '20110619112648': > > status: MONITORING > > ca-error: Error setting up ccache for local "host" service using > default > > keytab. > > stuck: no > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-COM//pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=xxxxx.COM > > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > > expires: 20111216112647 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > Request ID '20110619112705': > > status: MONITORING > > ca-error: Error setting up ccache for local "host" service using > default > > keytab. > > stuck: no > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=xxxxx.COM > > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > > expires: 20111216112704 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > Request ID '20110619112721': > > status: MONITORING > > ca-error: Error setting up ccache for local "host" service using > default > > keytab. > > stuck: no > > key pair storage: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=xxxxx.COM > > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM > > expires: 20111216112720 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > > > The issue is still there as you can see the expiry dates are not > getting > > modified. > > > > Nidal. > > > > --- On *Tue, 1/3/12, Rob Crittenden / >/* wrote: > > > > > > From: Rob Crittenden > > > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > > To: "nasir nasir" > > > Cc: "Rich Megginson" >, > > freeipa-users at redhat.com > , fasilkaks at gmail.com > > > Date: Tuesday, January 3, 2012, 2:23 PM > > > > nasir nasir wrote: > > > > > > > > > --- On *Tue, 1/3/12, Rich Megginson / > > >>/*wrote: > > > > > > > > > From: Rich Megginson > > >> > > > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > > > To: "nasir nasir" > > >> > > > Cc: freeipa-users at redhat.com > > > >, fasilkaks at gmail.com > > > > > > > Date: Tuesday, January 3, 2012, 7:41 AM > > > > > > On 01/03/2012 12:52 AM, nasir nasir wrote: > > >> Hi, > > >> > > >> I am facing a serious issue with my production IPA server. When I > > >> try to access IPA web interface using Firefox, it hangs and > > >> doesn't allow me to get in. It seems to be due to expired SSL > > >> certificate as seen in the apache log file, > > >> > > >> > > >> [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: > > >> 'Server-Cert' > > >> [Tue Jan 03 10:34:08 2012] [error] SSL Library Error: -8181 > > >> Certificate has expired > > >> [Tue Jan 03 10:34:08 2012] [error] Unable to verify certificate > > >> 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the > > >> server can start until the problem can be resolved. > > >> [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: > > >> 'Server-Cert' > > >> > > >> > > >> Also, when I try to use the command line (ipa user-mod or > > >> user-show commands) it too just hangs and doesn't give any output > > >> or allow me for any input. I can see the following in > krb5kdc.log , > > >> > > >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): preauth > > >> (timestamp) verify failure: Decrypt integrity check failed > > >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): AS_REQ (4 > > >> etypes {18 17 16 23}) 192.168.1.10: PREAUTH_FAILED: > > >> host/xxxxx.xxxxx.com at XXXXXX.COM > > > > > > >> > > >> for > > >> krbtgt/XXXXXX.COM at XXXXXX.COM > > > > > >> > > >>, Decrypt integrity > > >> check failed > > >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2429](info): AS_REQ (4 > > >> etypes {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: > > >> host/xxxx.xxxxx.com at XXXXX.COM > > > > > > >> > > >> for > > >> krbtgt/XXXXXX.COM at XXXXXX.COM > > > > > >> > > >>, Additional > > >> pre-authentication required > > >> > > >> > > >> The output of "certutil -L -d /etc/httpd/alias -n Server-Cert" > > >> confirms that certificate is expired as given below. > > >> > > >> Certificate: > > >> Data: > > >> Version: 3 (0x2) > > >> Serial Number: 10 (0xa) > > >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption > > >> Issuer: "CN=Certificate Authority,O=XXXXXX.COM" > > >> Validity: > > >> Not Before: Sun Jun 19 11:27:20 2011 > > >> Not After : Fri Dec 16 11:27:20 2011 > > >> > > >> > > >> Relevant info > > >> > > >> OS: RHEL 6.1 > > >> > > >> > > >> Output of rpm -qa | grep ipa > > >> > > >> ipa-client-2.0.0-23.el6.i686 > > >> ipa-pki-ca-theme-9.0.3-6.el6.noarch > > >> ipa-pki-common-theme-9.0.3-6.el6.noarch > > >> device-mapper-multipath-libs-0.4.9-41.el6.i686 > > >> python-iniparse-0.3.1-2.1.el6.noarch > > >> ipa-python-2.0.0-23.el6.i686 > > >> ipa-server-selinux-2.0.0-23.el6.i686 > > >> ipa-server-2.0.0-23.el6.i686 > > >> device-mapper-multipath-0.4.9-41.el6.i686 > > >> ipa-admintools-2.0.0-23.el6.i686 > > >> > > >> > > >> I went through the documentations to check how to renew the > > >> expired certs but it seems to be confusing and different across > > >> versions. Could someone please help me out by suggesting which is > > >> the best way to achieve this ? Any help would be greatly > > >> appreciated as I am unable to perform any task on the IPA server > > >> now because of this. > > >> > > > I suggest following the mod_nss suggestion to allow it to start and > > > use the expired cert while you attempt to figure this out. > > > > > > Thanks indeed for the suggestion. I will consider this. But can > > > anyone point me the steps to renew certificate from the expired > one ? > > > > > > Thankds and regards, > > > Nidal > > > > Lets start with figuring out why certmonger didn't do this for you: > > > > Can you run as root: ipa-getcert list > > > > You should have something like: > > > > Request ID '20111215203350': > > status: MONITORING > > stuck: no > > key pair storage: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > > Certificate DB' > > CA: IPA > > issuer: CN=EXAMPLE.COM Certificate Authority > > subject: CN=rawhide.example.com,O=EXAMPLE.COM > > expires: 2021-12-15 20:33:50 UTC > > track: yes > > auto-renew: yes > > > > If you don't have something like this then perhaps the easiest way to > > get it renewed is to tell certmonger to track it. First, look at your > > current database, it should look something like: > > > > # certutil -L -d /etc/httpd/alias > > > > Server-Cert u,u,u > > EXAMPLE.COM IPA CA CTu,u,Cu > > Signing-Cert u,u,u > > > > Now track it > > > > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert > > > > Use ipa-getcert list to track the status of the renewal. Once it has > > been completed you can reset the EnforceValidCerts option and restart > > Apache. > > > > If certmonger is already tracking the cert and the renewal has failed > > then please provide the ipa-getcert list output. > > > > rob > > > From ian at crystal.harvard.edu Wed Jan 4 23:32:37 2012 From: ian at crystal.harvard.edu (Ian Levesque) Date: Wed, 4 Jan 2012 18:32:37 -0500 Subject: [Freeipa-users] Password token manipulation errors after upgrade Message-ID: <4AC6FF47-75EB-46A1-96F1-2FDA7320D217@crystal.harvard.edu> Hello, I've upgraded a FreeIPA server to RHEL 6.2 (from 6.1), putting me at version 2.1.3-9. Since the upgrade, I haven't been able to change any existing passwords, all I get is an "Authentication token manipulation error". Newly-created accounts don't have this problem. I /can/ login using my existing password, but one user's password is expired and is effectively locked out until I can figure this out. Any ideas? Best, Ian -bash-4.1$ whoami ian -bash-4.1$ passwd Changing password for user ian. Current Password: New password: Retype new password: Password change failed. Server message: Password change failed passwd: Authentication token manipulation error krb5kdc.log: krb5kdc[1558](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.10.54: NEEDED_PREAUTH: ian at SBGRID.ORG for kadmin/changepw at SBGRID.ORG, Additional pre-authentication required krb5kdc[1558](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.10.54: ISSUE: authtime 1325719595, etypes {rep=18 tkt=18 ses=18}, ian at SBGRID.ORG for kadmin/changepw at SBGRID.ORG krb5kdc[1558](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.10.54: NEEDED_PREAUTH: kadmin/changepw at SBGRID.ORG for krbtgt/SBGRID.ORG at SBGRID.ORG, Additional pre-authentication required krb5kdc[1558](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.10.54: ISSUE: authtime 1325719595, etypes {rep=18 tkt=18 ses=18}, kadmin/changepw at SBGRID.ORG for krbtgt/SBGRID.ORG at SBGRID.ORG krb5kdc[1558](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.10.54: ISSUE: authtime 1325719595, etypes {rep=18 tkt=18 ses=18}, kadmin/changepw at SBGRID.ORG for ldap/sbgrid-directory.in.hwlab at SBGRID.ORG messages: passwd: pam_sss(passwd:chauthtok): system info: [Generic error (see e-text)] passwd: pam_sss(passwd:chauthtok): User info message: Password change failed. Server message: Password change failed passwd: pam_sss(passwd:chauthtok): Password change failed for user ian: 20 (Authentication token manipulation error) From ian at crystal.harvard.edu Wed Jan 4 23:45:59 2012 From: ian at crystal.harvard.edu (Ian Levesque) Date: Wed, 4 Jan 2012 18:45:59 -0500 Subject: [Freeipa-users] Password token manipulation errors after upgrade In-Reply-To: <4AC6FF47-75EB-46A1-96F1-2FDA7320D217@crystal.harvard.edu> References: <4AC6FF47-75EB-46A1-96F1-2FDA7320D217@crystal.harvard.edu> Message-ID: <0F5A935D-FF36-4B37-A83D-FFA076C7A528@crystal.harvard.edu> Figured out the problem. For future reference, a more informative log entry appeared in /var/log/dirsrv/slapd-/errors: Entry "uid=ian,cn=users,cn=accounts,dc=sbgrid,dc=org" has unknown object class "radiusprofile" Sure enough, when I upgraded our old (v1) FreeIPA server I had to add some schema because "radiusprofile" was a previously-included objectClass. I guess the upgraded server didn't include that schema. After ldapmodifying the user accounts to remove that objectClass, we're back in business. ~irl On Jan 4, 2012, at 6:32 PM, Ian Levesque wrote: > Hello, > > I've upgraded a FreeIPA server to RHEL 6.2 (from 6.1), putting me at version 2.1.3-9. Since the upgrade, I haven't been able to change any existing passwords, all I get is an "Authentication token manipulation error". Newly-created accounts don't have this problem. I /can/ login using my existing password, but one user's password is expired and is effectively locked out until I can figure this out. Any ideas? > > Best, > Ian From dpal at redhat.com Wed Jan 4 23:47:37 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Jan 2012 18:47:37 -0500 Subject: [Freeipa-users] Password token manipulation errors after upgrade In-Reply-To: <4AC6FF47-75EB-46A1-96F1-2FDA7320D217@crystal.harvard.edu> References: <4AC6FF47-75EB-46A1-96F1-2FDA7320D217@crystal.harvard.edu> Message-ID: <4F04E519.4040506@redhat.com> On 01/04/2012 06:32 PM, Ian Levesque wrote: > Hello, > > I've upgraded a FreeIPA server to RHEL 6.2 (from 6.1), putting me at version 2.1.3-9. Since the upgrade, I haven't been able to change any existing passwords, all I get is an "Authentication token manipulation error". Newly-created accounts don't have this problem. I /can/ login using my existing password, but one user's password is expired and is effectively locked out until I can figure this out. Any ideas? First of all in place upgrade from tech preview 6.1 bits to 6.2 is not supported by Red Hat as 6.2 is the first supported release. This being said you might try to remove passwords. Can you use some old account as a test, remove the kerberos password attribute and then follow the migration procedure for it, i.e. authenticate using special migration UI page or with SSSD in migration mode? If that works then you might want to do it for all old users. > Best, > Ian > > > -bash-4.1$ whoami > ian > > -bash-4.1$ passwd > Changing password for user ian. > Current Password: > New password: > Retype new password: > Password change failed. Server message: Password change failed > passwd: Authentication token manipulation error > > > krb5kdc.log: > > krb5kdc[1558](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.10.54: NEEDED_PREAUTH: ian at SBGRID.ORG for kadmin/changepw at SBGRID.ORG, Additional pre-authentication required > krb5kdc[1558](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.10.54: ISSUE: authtime 1325719595, etypes {rep=18 tkt=18 ses=18}, ian at SBGRID.ORG for kadmin/changepw at SBGRID.ORG > krb5kdc[1558](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.10.54: NEEDED_PREAUTH: kadmin/changepw at SBGRID.ORG for krbtgt/SBGRID.ORG at SBGRID.ORG, Additional pre-authentication required > krb5kdc[1558](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.10.54: ISSUE: authtime 1325719595, etypes {rep=18 tkt=18 ses=18}, kadmin/changepw at SBGRID.ORG for krbtgt/SBGRID.ORG at SBGRID.ORG > krb5kdc[1558](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.10.54: ISSUE: authtime 1325719595, etypes {rep=18 tkt=18 ses=18}, kadmin/changepw at SBGRID.ORG for ldap/sbgrid-directory.in.hwlab at SBGRID.ORG > > messages: > > passwd: pam_sss(passwd:chauthtok): system info: [Generic error (see e-text)] > passwd: pam_sss(passwd:chauthtok): User info message: Password change failed. Server message: Password change failed > passwd: pam_sss(passwd:chauthtok): Password change failed for user ian: 20 (Authentication token manipulation error) > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Thu Jan 5 09:10:42 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Jan 2012 12:10:42 +0300 Subject: [Freeipa-users] FreeIPA 2.1.4 replication In-Reply-To: <20120104184606.GB24492@redhat.com> References: <4F049C11.9010206@redhat.com> <20120104184606.GB24492@redhat.com> Message-ID: <20120105091042.GC24492@redhat.com> On Wed, 04 Jan 2012, Alexander Bokovoy wrote: > On Wed, 04 Jan 2012, Rich Megginson wrote: > > >Your system may be partly configured. > > >Run /usr/sbin/ipa-server-install --uninstall to clean up. > > >[root at fileserver4 ~]# > > > > > >I'm running 389-ds-base-1.2.10-0.5.a5.fc16.x86_64, if that helps > > try > > > > 389-ds-base-1.2.10-0.6.a6.fc16.x86_64 > > from updates-testing > That would mean taking in also nss packages (they are in stable > already for F16) which will break FreeIPA. > > If no those breaks from nss (FEDORA-2011-17400 update), we could have > 2.1.4 in stable already. > > Look at http://bugzilla.redhat.com/show_bug.cgi?id=771357 for details. > Unfortunately, workarounds are kludgy and require modification deep in > Dogtag templates. > > Backstory for nss part is here > https://bugzilla.redhat.com/show_bug.cgi?id=737506 As a workaround temporarily one can add following line to /usr/share/pki/ca/tomcat6.conf before running ipa-server-install: NSS_SSL_CBC_RANDOM_IV=0 -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jan 5 09:18:10 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Jan 2012 12:18:10 +0300 Subject: [Freeipa-users] FreeIPA 2.1.4 replication In-Reply-To: <20120105091042.GC24492@redhat.com> References: <4F049C11.9010206@redhat.com> <20120104184606.GB24492@redhat.com> <20120105091042.GC24492@redhat.com> Message-ID: <20120105091810.GD24492@redhat.com> On Thu, 05 Jan 2012, Alexander Bokovoy wrote: > On Wed, 04 Jan 2012, Alexander Bokovoy wrote: > > On Wed, 04 Jan 2012, Rich Megginson wrote: > > > >Your system may be partly configured. > > > >Run /usr/sbin/ipa-server-install --uninstall to clean up. > > > >[root at fileserver4 ~]# > > > > > > > >I'm running 389-ds-base-1.2.10-0.5.a5.fc16.x86_64, if that helps > > > try > > > > > > 389-ds-base-1.2.10-0.6.a6.fc16.x86_64 > > > from updates-testing > > That would mean taking in also nss packages (they are in stable > > already for F16) which will break FreeIPA. > > > > If no those breaks from nss (FEDORA-2011-17400 update), we could have > > 2.1.4 in stable already. > > > > Look at http://bugzilla.redhat.com/show_bug.cgi?id=771357 for details. > > Unfortunately, workarounds are kludgy and require modification deep in > > Dogtag templates. > > > > Backstory for nss part is here > > https://bugzilla.redhat.com/show_bug.cgi?id=737506 > As a workaround temporarily one can add following line to > /usr/share/pki/ca/tomcat6.conf before running ipa-server-install: /usr/share/pki/ca/conf/tomcat6.conf, sorry. -- / Alexander Bokovoy From kollathodi at yahoo.com Thu Jan 5 13:09:42 2012 From: kollathodi at yahoo.com (nasir nasir) Date: Thu, 5 Jan 2012 05:09:42 -0800 (PST) Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <4F04D55F.9090104@redhat.com> Message-ID: <1325768982.8071.YahooMailClassic@web161305.mail.bf1.yahoo.com> Thanks for the reply Rob. Please find below the output of your guidelines. #?ipa-getkeytab -s xxxxxxx.xxxxxxx.com -p host/xxxxxx.xxxxxx.com -k /etc/krb5.keytab(the command was successful; it din't show any errors in the krb5kdc.log or audit.log) #?kinit -kt /etc/krb5.keytab host/xxxxxx.xxxxxx.com krb5kdc.log-----------------Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2431](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: host/xxxxxx.xxxxxx.com at xxxxxx.COM for krbtgt/xxxxxx.COM at xxxxxx.COM, Additional pre-authentication requiredJan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2427](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.1.10: ISSUE: authtime 1325766032, etypes {rep=18 tkt=18 ses=18}, host/xxxxxx.xxxxxx.com at xxxxxx.COM for krbtgt/xxxxxx.COM at xxxxxx.COM #?ipa-getcert listNumber of certificates and requests being tracked: 3.Request ID '20110619112648':? ? ? ? status: CA_UNREACHABLE? ? ? ? ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. ?SSL connect error).? ? ? ? stuck: yes? ? ? ? key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxxx-COM//pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=xxxxxx.COM? ? ? ? subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM? ? ? ? expires: 20111216112647? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yesRequest ID '20110619112705':? ? ? ? status: CA_UNREACHABLE? ? ? ? ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. ?SSL connect error).? ? ? ? stuck: yes? ? ? ? key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=xxxxxx.COM? ? ? ? subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM? ? ? ? expires: 20111216112704? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yesRequest ID '20110619112721':? ? ? ? status: CA_UNREACHABLE? ? ? ? ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. ?SSL connect error).? ? ? ? stuck: yes? ? ? ? key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=xxxxxx.COM? ? ? ? subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM? ? ? ? expires: 20111216112720? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yes # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-CertRequest "20110619112721" modified. # ipa-getcert listNumber of certificates and requests being tracked: 3.Request ID '20110619112648':? ? ? ? status: CA_UNREACHABLE? ? ? ? ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. ?SSL connect error).? ? ? ? stuck: yes? ? ? ? key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=HUGAYET.COM? ? ? ? subject: CN=openipa.hugayet.com,O=HUGAYET.COM? ? ? ? expires: 20111216112647? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yesRequest ID '20110619112705':? ? ? ? status: CA_UNREACHABLE? ? ? ? ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. ?SSL connect error).? ? ? ? stuck: yes? ? ? ? key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=HUGAYET.COM? ? ? ? subject: CN=openipa.hugayet.com,O=HUGAYET.COM? ? ? ? expires: 20111216112704? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yesRequest ID '20110619112721':? ? ? ? status: SUBMITTING? ? ? ? stuck: no? ? ? ? key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=HUGAYET.COM? ? ? ? subject: CN=openipa.hugayet.com,O=HUGAYET.COM? ? ? ? expires: 20111216112720? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yes and after few minutes, the status 'SUBMITTING' will be changed as 'CA_UNREACHABLE'Do we need to restart the /etc/init.d/ipa service for this? I am working remotely. I need to upgrade my IPA version. Before going for this I need to have a replica of the existing one. Is it okay to have the replica while all these issues exist?? Nidal. --- On Wed, 1/4/12, Rob Crittenden wrote: From: Rob Crittenden Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: "nasir nasir" Cc: freeipa-users at redhat.com, fasilkaks at gmail.com Date: Wednesday, January 4, 2012, 2:40 PM nasir nasir wrote: > Thanks for the reply Rob, > > Indeed there are host entries. > Please find below the output of your below mentioned guidelines. > > # klist -kt /etc/krb5.keytab > Keytab name: WRFILE:/etc/krb5.keytab > KVNO Timestamp Principal > ---- ----------------- > -------------------------------------------------------- > 2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM > 2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM > 2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM > 2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM > 2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM > 2 06/19/11 14:27:17 host/xxxxxx.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:07:26 host/test1.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:07:26 host/test1.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:07:26 host/test1.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:07:26 host/test1.xxxxxx.com at xxxxxx.COM > 6 06/20/11 09:09:12 nfs/nfs.xxxxxx.com at xxxxxx.COM > 6 06/20/11 09:09:12 nfs/nfs.xxxxxx.com at xxxxxx.COM > 6 06/20/11 09:09:12 nfs/nfs.xxxxxx.com at xxxxxx.COM > 6 06/20/11 09:09:12 nfs/nfs.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:11:24 nfs/test1.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:11:24 nfs/test1.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:11:24 nfs/test1.xxxxxx.com at xxxxxx.COM > 2 06/20/11 09:11:24 nfs/test1.xxxxxx.com at xxxxxx.COM > > # kinit -kt /etc/krb5.keytab host/openipa.hugayet.com > kinit: Password incorrect while getting initial credentials > > # kinit admin > (the password is accepted successfully here) > > # kinit -kt /etc/krb5.keytab host/openipa.hugayet.com > kinit: Password incorrect while getting initial credentials > > What could be the possible issue of the invalid credential error? Please > help. Probably the most expedient fix is to use ipa-getkeytab to get new credentials for the host service. Here is an example assuming you need a new keytab for your freeIPA server itself: # ipa-getkeytab -s ipa.example.com -p host/ipa.example.com -k /etc/krb5.keytab rob > > Nidal > --- On *Wed, 1/4/12, Rob Crittenden / */.com>/* wrote: > > >? ???From: Rob Crittenden >? ???Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ???To: "nasir nasir" >? ???Cc: "Rich Megginson" , >? ???freeipa-users at redhat.com, fasilkaks at gmail.com >? ???Date: Wednesday, January 4, 2012, 11:52 AM > >? ???nasir nasir wrote: >? ? ? > Thanks for all the replies. >? ? ? > >? ? ? > Rob, >? ? ? > Please find the output of your guidelines. > >? ???Here is the culprit: > >? ???ca-error: Error setting up ccache for local "host" service using >? ???default >? ???keytab. > >? ???certmonger authenticates to IPA using the host service principal >? ???installed on each client (and master). For some reason that can't be >? ???used. > >? ???Check the keytab: > >? ???# klist -kt /etc/krb5.keytab > >? ???If there are host entries there, try it: > >? ???# kinit -kt /etc/krb5.keytab host/server.example.com > >? ???rob > >? ? ? > >? ? ? > # ipa-getcert list >? ? ? > Number of certificates and requests being tracked: 3. >? ? ? > Request ID '20110619112648': >? ? ? > status: MONITORING >? ? ? > ca-error: Error setting up ccache for local "host" service using >? ???default >? ? ? > keytab. >? ? ? > stuck: no >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-COM//pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=xxxxx.COM >? ? ? > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM >? ? ? > expires: 20111216112647 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > Request ID '20110619112705': >? ? ? > status: MONITORING >? ? ? > ca-error: Error setting up ccache for local "host" service using >? ???default >? ? ? > keytab. >? ? ? > stuck: no >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=xxxxx.COM >? ? ? > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM >? ? ? > expires: 20111216112704 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > Request ID '20110619112721': >? ? ? > status: MONITORING >? ? ? > ca-error: Error setting up ccache for local "host" service using >? ???default >? ? ? > keytab. >? ? ? > stuck: no >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=xxxxx.COM >? ? ? > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM >? ? ? > expires: 20111216112720 eku: id-kp-serverAuth track: yes >? ? ? > auto-renew: yes >? ? ? > >? ? ? > # certutil -L -d /etc/httpd/alias >? ? ? > Certificate Nickname Trust Attributes >? ? ? > SSL,S/MIME,JAR/XPI >? ? ? > Server-Cert u,u,u >? ? ? > HUGAYET.COM IPA CA CT,C,C >? ? ? > ipaCert u,u,u >? ? ? > Signing-Cert u,u,u >? ? ? > >? ? ? > Now track it >? ? ? > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert >? ? ? > Request "20110619112721" modified. >? ? ? > >? ? ? > #ipa-getcert list >? ? ? > Number of certificates and requests being tracked: 3. >? ? ? > Request ID '20110619112648': >? ? ? > status: MONITORING >? ? ? > ca-error: Error setting up ccache for local "host" service using >? ???default >? ? ? > keytab. >? ? ? > stuck: no >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-COM//pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-COM',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=xxxxx.COM >? ? ? > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM >? ? ? > expires: 20111216112647 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > Request ID '20110619112705': >? ? ? > status: MONITORING >? ? ? > ca-error: Error setting up ccache for local "host" service using >? ???default >? ? ? > keytab. >? ? ? > stuck: no >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=xxxxx.COM >? ? ? > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM >? ? ? > expires: 20111216112704 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > Request ID '20110619112721': >? ? ? > status: MONITORING >? ? ? > ca-error: Error setting up ccache for local "host" service using >? ???default >? ? ? > keytab. >? ? ? > stuck: no >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=xxxxx.COM >? ? ? > subject: CN=xxxxx.xxxxx.com,O=xxxxx.COM >? ? ? > expires: 20111216112720 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > >? ? ? > The issue is still there as you can see the expiry dates are not >? ???getting >? ? ? > modified. >? ? ? > >? ? ? > Nidal. >? ? ? > >? ? ? > --- On *Tue, 1/3/12, Rob Crittenden /? ???>/* wrote: >? ? ? > >? ? ? > >? ? ? > From: Rob Crittenden ? ???> >? ? ? > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ? ? > To: "nasir nasir" ? ???> >? ? ? > Cc: "Rich Megginson" ? ???>, >? ? ? > freeipa-users at redhat.com >? ???, fasilkaks at gmail.com >? ??? >? ? ? > Date: Tuesday, January 3, 2012, 2:23 PM >? ? ? > >? ? ? > nasir nasir wrote: >? ? ? > > >? ? ? > > >? ? ? > > --- On *Tue, 1/3/12, Rich Megginson /? ??? >? ? ? > ? ???>>/*wrote: >? ? ? > > >? ? ? > > >? ? ? > > From: Rich Megginson ? ??? >? ? ? > ? ???>> >? ? ? > > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ? ? > > To: "nasir nasir" ? ??? >? ? ? > ? ???>> >? ? ? > > Cc: freeipa-users at redhat.com >? ??? >? ? ? > ? ???>, fasilkaks at gmail.com >? ??? >? ? ? > ? ???> >? ? ? > > Date: Tuesday, January 3, 2012, 7:41 AM >? ? ? > > >? ? ? > > On 01/03/2012 12:52 AM, nasir nasir wrote: >? ? ? > >> Hi, >? ? ? > >> >? ? ? > >> I am facing a serious issue with my production IPA server. When I >? ? ? > >> try to access IPA web interface using Firefox, it hangs and >? ? ? > >> doesn't allow me to get in. It seems to be due to expired SSL >? ? ? > >> certificate as seen in the apache log file, >? ? ? > >> >? ? ? > >> >? ? ? > >> [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: >? ? ? > >> 'Server-Cert' >? ? ? > >> [Tue Jan 03 10:34:08 2012] [error] SSL Library Error: -8181 >? ? ? > >> Certificate has expired >? ? ? > >> [Tue Jan 03 10:34:08 2012] [error] Unable to verify certificate >? ? ? > >> 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the >? ? ? > >> server can start until the problem can be resolved. >? ? ? > >> [Tue Jan 03 10:34:08 2012] [error] Certificate not verified: >? ? ? > >> 'Server-Cert' >? ? ? > >> >? ? ? > >> >? ? ? > >> Also, when I try to use the command line (ipa user-mod or >? ? ? > >> user-show commands) it too just hangs and doesn't give any output >? ? ? > >> or allow me for any input. I can see the following in >? ???krb5kdc.log , >? ? ? > >> >? ? ? > >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): preauth >? ? ? > >> (timestamp) verify failure: Decrypt integrity check failed >? ? ? > >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2426](info): AS_REQ (4 >? ? ? > >> etypes {18 17 16 23}) 192.168.1.10: PREAUTH_FAILED: >? ? ? > >> host/xxxxx.xxxxx.com at XXXXXX.COM >? ??? >? ? ? > ? ???> >? ? ? > >> ? ??? >? ? ? > ? ???>> for >? ? ? > >> krbtgt/XXXXXX.COM at XXXXXX.COM >? ??? >? ???? ???> >? ? ? > >> ? ??? >? ? ? > ? ???>>, Decrypt integrity >? ? ? > >> check failed >? ? ? > >> Jan 03 10:29:16 xxxxxx.xxxxxx.com krb5kdc[2429](info): AS_REQ (4 >? ? ? > >> etypes {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: >? ? ? > >> host/xxxx.xxxxx.com at XXXXX.COM >? ??? >? ? ? > ? ???> >? ? ? > >> ? ??? >? ? ? > ? ???>> for >? ? ? > >> krbtgt/XXXXXX.COM at XXXXXX.COM >? ??? >? ???? ???> >? ? ? > >> ? ??? >? ? ? > ? ???>>, Additional >? ? ? > >> pre-authentication required >? ? ? > >> >? ? ? > >> >? ? ? > >> The output of "certutil -L -d /etc/httpd/alias -n Server-Cert" >? ? ? > >> confirms that certificate is expired as given below. >? ? ? > >> >? ? ? > >> Certificate: >? ? ? > >> Data: >? ? ? > >> Version: 3 (0x2) >? ? ? > >> Serial Number: 10 (0xa) >? ? ? > >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >? ? ? > >> Issuer: "CN=Certificate Authority,O=XXXXXX.COM" >? ? ? > >> Validity: >? ? ? > >> Not Before: Sun Jun 19 11:27:20 2011 >? ? ? > >> Not After : Fri Dec 16 11:27:20 2011 >? ? ? > >> >? ? ? > >> >? ? ? > >> Relevant info >? ? ? > >> >? ? ? > >> OS: RHEL 6.1 >? ? ? > >> >? ? ? > >> >? ? ? > >> Output of rpm -qa | grep ipa >? ? ? > >> >? ? ? > >> ipa-client-2.0.0-23.el6.i686 >? ? ? > >> ipa-pki-ca-theme-9.0.3-6.el6.noarch >? ? ? > >> ipa-pki-common-theme-9.0.3-6.el6.noarch >? ? ? > >> device-mapper-multipath-libs-0.4.9-41.el6.i686 >? ? ? > >> python-iniparse-0.3.1-2.1.el6.noarch >? ? ? > >> ipa-python-2.0.0-23.el6.i686 >? ? ? > >> ipa-server-selinux-2.0.0-23.el6.i686 >? ? ? > >> ipa-server-2.0.0-23.el6.i686 >? ? ? > >> device-mapper-multipath-0.4.9-41.el6.i686 >? ? ? > >> ipa-admintools-2.0.0-23.el6.i686 >? ? ? > >> >? ? ? > >> >? ? ? > >> I went through the documentations to check how to renew the >? ? ? > >> expired certs but it seems to be confusing and different across >? ? ? > >> versions. Could someone please help me out by suggesting which is >? ? ? > >> the best way to achieve this ? Any help would be greatly >? ? ? > >> appreciated as I am unable to perform any task on the IPA server >? ? ? > >> now because of this. >? ? ? > >> >? ? ? > > I suggest following the mod_nss suggestion to allow it to start and >? ? ? > > use the expired cert while you attempt to figure this out. >? ? ? > > >? ? ? > > Thanks indeed for the suggestion. I will consider this. But can >? ? ? > > anyone point me the steps to renew certificate from the expired >? ???one ? >? ? ? > > >? ? ? > > Thankds and regards, >? ? ? > > Nidal >? ? ? > >? ? ? > Lets start with figuring out why certmonger didn't do this for you: >? ? ? > >? ? ? > Can you run as root: ipa-getcert list >? ? ? > >? ? ? > You should have something like: >? ? ? > >? ? ? > Request ID '20111215203350': >? ? ? > status: MONITORING >? ? ? > stuck: no >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > >? ? ? > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=EXAMPLE.COM Certificate Authority >? ? ? > subject: CN=rawhide.example.com,O=EXAMPLE.COM >? ? ? > expires: 2021-12-15 20:33:50 UTC >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > >? ? ? > If you don't have something like this then perhaps the easiest way to >? ? ? > get it renewed is to tell certmonger to track it. First, look at your >? ? ? > current database, it should look something like: >? ? ? > >? ? ? > # certutil -L -d /etc/httpd/alias >? ? ? > >? ? ? > Server-Cert u,u,u >? ? ? > EXAMPLE.COM IPA CA CTu,u,Cu >? ? ? > Signing-Cert u,u,u >? ? ? > >? ? ? > Now track it >? ? ? > >? ? ? > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert >? ? ? > >? ? ? > Use ipa-getcert list to track the status of the renewal. Once it has >? ? ? > been completed you can reset the EnforceValidCerts option and restart >? ? ? > Apache. >? ? ? > >? ? ? > If certmonger is already tracking the cert and the renewal has failed >? ? ? > then please provide the ipa-getcert list output. >? ? ? > >? ? ? > rob >? ? ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Jan 5 15:38:11 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Jan 2012 10:38:11 -0500 Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <1325768982.8071.YahooMailClassic@web161305.mail.bf1.yahoo.com> References: <1325768982.8071.YahooMailClassic@web161305.mail.bf1.yahoo.com> Message-ID: <4F05C3E3.4060904@redhat.com> nasir nasir wrote: > Thanks for the reply Rob. > > Please find below the output of your guidelines. > > # ipa-getkeytab -s xxxxxxx.xxxxxxx.com -p host/xxxxxx.xxxxxx.com -k > /etc/krb5.keytab > (the command was successful; it din't show any errors in the krb5kdc.log > or audit.log) > > # kinit -kt /etc/krb5.keytab host/xxxxxx.xxxxxx.com > > krb5kdc.log > ----------------- > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2431](info): AS_REQ (4 etypes > {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: > host/xxxxxx.xxxxxx.com at xxxxxx.COM for krbtgt/xxxxxx.COM at xxxxxx.COM, > Additional pre-authentication required > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2427](info): AS_REQ (4 etypes > {18 17 16 23}) 192.168.1.10: ISSUE: authtime 1325766032, etypes {rep=18 > tkt=18 ses=18}, host/xxxxxx.xxxxxx.com at xxxxxx.COM for > krbtgt/xxxxxx.COM at xxxxxx.COM > > # ipa-getcert list > Number of certificates and requests being tracked: 3. > Request ID '20110619112648': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxxx-COM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxxx.COM > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > expires: 20111216112647 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112705': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxxx.COM > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > expires: 20111216112704 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112721': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxxx.COM > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > expires: 20111216112720 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert > Request "20110619112721" modified. > > # ipa-getcert list > Number of certificates and requests being tracked: 3. > Request ID '20110619112648': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=HUGAYET.COM > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > expires: 20111216112647 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112705': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=HUGAYET.COM > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > expires: 20111216112704 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112721': > status: SUBMITTING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=HUGAYET.COM > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > expires: 20111216112720 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > > and after few minutes, the status 'SUBMITTING' will be changed as > 'CA_UNREACHABLE' > Do we need to restart the /etc/init.d/ipa service for this? I am working > remotely. It isn't logging enough information to know why it failed. Can you look in the Apache error log to see why the request failed? My first thought was that there was a CA trust issue. I believe that certmonger uses the NSS database where the certificate is stored so since it is also doing this against Apache (which in theory trust is ok for it to start at all) so I'm baffled. Hopefully the httpd logs will be enlightening. > > I need to upgrade my IPA version. Before going for this I need to have a > replica of the existing one. Is it okay to have the replica while all > these issues exist? Yes, you should be able to create a replica, this shouldn't affect it. rob From kollathodi at yahoo.com Thu Jan 5 16:55:10 2012 From: kollathodi at yahoo.com (nasir nasir) Date: Thu, 5 Jan 2012 08:55:10 -0800 (PST) Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <4F05C3E3.4060904@redhat.com> Message-ID: <1325782510.74177.YahooMailClassic@web161301.mail.bf1.yahoo.com> Thanks for the input Rob, Please find below the /var/log/httpd/error_log [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: 'Server-Cert'[Thu Jan 05 19:50:46 2012] [error] SSL Library Error: -8181 Certificate has expired[Thu Jan 05 19:50:46 2012] [error] Certificate not verified: 'Server-Cert'[Thu Jan 05 19:50:46 2012] [error] Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the server can start until the problem can be resolved. Do I need to add "NSSEnforceValidCerts off" in?/etc/httpd/conf.d/nss.conf? Please advice. Nidal. --- On Thu, 1/5/12, Rob Crittenden wrote: From: Rob Crittenden Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: "nasir nasir" Cc: freeipa-users at redhat.com, fasilkaks at gmail.com Date: Thursday, January 5, 2012, 7:38 AM nasir nasir wrote: > Thanks for the reply Rob. > > Please find below the output of your guidelines. > > # ipa-getkeytab -s xxxxxxx.xxxxxxx.com -p host/xxxxxx.xxxxxx.com -k > /etc/krb5.keytab > (the command was successful; it din't show any errors in the krb5kdc.log > or audit.log) > > # kinit -kt /etc/krb5.keytab host/xxxxxx.xxxxxx.com > > krb5kdc.log > ----------------- > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2431](info): AS_REQ (4 etypes > {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: > host/xxxxxx.xxxxxx.com at xxxxxx.COM for krbtgt/xxxxxx.COM at xxxxxx.COM, > Additional pre-authentication required > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2427](info): AS_REQ (4 etypes > {18 17 16 23}) 192.168.1.10: ISSUE: authtime 1325766032, etypes {rep=18 > tkt=18 ses=18}, host/xxxxxx.xxxxxx.com at xxxxxx.COM for > krbtgt/xxxxxx.COM at xxxxxx.COM > > # ipa-getcert list > Number of certificates and requests being tracked: 3. > Request ID '20110619112648': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxxx-COM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxxx.COM > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > expires: 20111216112647 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112705': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxxx.COM > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > expires: 20111216112704 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112721': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxxx.COM > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > expires: 20111216112720 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert > Request "20110619112721" modified. > > # ipa-getcert list > Number of certificates and requests being tracked: 3. > Request ID '20110619112648': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=HUGAYET.COM > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > expires: 20111216112647 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112705': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=HUGAYET.COM > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > expires: 20111216112704 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112721': > status: SUBMITTING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=HUGAYET.COM > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > expires: 20111216112720 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > > and after few minutes, the status 'SUBMITTING' will be changed as > 'CA_UNREACHABLE' > Do we need to restart the /etc/init.d/ipa service for this? I am working > remotely. It isn't logging enough information to know why it failed. Can you look in the Apache error log to see why the request failed? My first thought was that there was a CA trust issue. I believe that certmonger uses the NSS database where the certificate is stored so since it is also doing this against Apache (which in theory trust is ok for it to start at all) so I'm baffled. Hopefully the httpd logs will be enlightening. > > I need to upgrade my IPA version. Before going for this I need to have a > replica of the existing one. Is it okay to have the replica while all > these issues exist? Yes, you should be able to create a replica, this shouldn't affect it. rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Jan 5 16:59:19 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Jan 2012 11:59:19 -0500 Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <1325782510.74177.YahooMailClassic@web161301.mail.bf1.yahoo.com> References: <1325782510.74177.YahooMailClassic@web161301.mail.bf1.yahoo.com> Message-ID: <4F05D6E7.7080208@redhat.com> nasir nasir wrote: > Thanks for the input Rob, > > Please find below the /var/log/httpd/error_log > > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: 'Server-Cert' > [Thu Jan 05 19:50:46 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: 'Server-Cert' > [Thu Jan 05 19:50:46 2012] [error] Unable to verify certificate > 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the server > can start until the problem can be resolved. > > Do I need to add "NSSEnforceValidCerts off" in > /etc/httpd/conf.d/nss.conf? Please advice. > That explains why certmonger can't connect. Yes, for now add that directive and restart httpd. Then try the start-tracking again and see if it renews the cert. rob > Nidal. > > > --- On *Thu, 1/5/12, Rob Crittenden //* wrote: > > > From: Rob Crittenden > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > To: "nasir nasir" > Cc: freeipa-users at redhat.com, fasilkaks at gmail.com > Date: Thursday, January 5, 2012, 7:38 AM > > nasir nasir wrote: > > Thanks for the reply Rob. > > > > Please find below the output of your guidelines. > > > > # ipa-getkeytab -s xxxxxxx.xxxxxxx.com -p host/xxxxxx.xxxxxx.com -k > > /etc/krb5.keytab > > (the command was successful; it din't show any errors in the > krb5kdc.log > > or audit.log) > > > > # kinit -kt /etc/krb5.keytab host/xxxxxx.xxxxxx.com > > > > krb5kdc.log > > ----------------- > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2431](info): AS_REQ (4 > etypes > > {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: > > host/xxxxxx.xxxxxx.com at xxxxxx.COM > for > krbtgt/xxxxxx.COM at xxxxxx.COM , > > Additional pre-authentication required > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2427](info): AS_REQ (4 > etypes > > {18 17 16 23}) 192.168.1.10: ISSUE: authtime 1325766032, etypes > {rep=18 > > tkt=18 ses=18}, host/xxxxxx.xxxxxx.com at xxxxxx.COM > for > > krbtgt/xxxxxx.COM at xxxxxx.COM > > > > # ipa-getcert list > > Number of certificates and requests being tracked: 3. > > Request ID '20110619112648': > > status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: -504 (libcurl failed to > > execute the HTTP POST transaction. SSL connect error). > > stuck: yes > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxxx-COM//pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=xxxxxx.COM > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > > expires: 20111216112647 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > Request ID '20110619112705': > > status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: -504 (libcurl failed to > > execute the HTTP POST transaction. SSL connect error). > > stuck: yes > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=xxxxxx.COM > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > > expires: 20111216112704 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > Request ID '20110619112721': > > status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: -504 (libcurl failed to > > execute the HTTP POST transaction. SSL connect error). > > stuck: yes > > key pair storage: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=xxxxxx.COM > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > > expires: 20111216112720 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > > > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert > > Request "20110619112721" modified. > > > > # ipa-getcert list > > Number of certificates and requests being tracked: 3. > > Request ID '20110619112648': > > status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: -504 (libcurl failed to > > execute the HTTP POST transaction. SSL connect error). > > stuck: yes > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > expires: 20111216112647 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > Request ID '20110619112705': > > status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: -504 (libcurl failed to > > execute the HTTP POST transaction. SSL connect error). > > stuck: yes > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > expires: 20111216112704 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > Request ID '20110619112721': > > status: SUBMITTING > > stuck: no > > key pair storage: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > expires: 20111216112720 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > > > and after few minutes, the status 'SUBMITTING' will be changed as > > 'CA_UNREACHABLE' > > Do we need to restart the /etc/init.d/ipa service for this? I am > working > > remotely. > > It isn't logging enough information to know why it failed. Can you look > in the Apache error log to see why the request failed? > > My first thought was that there was a CA trust issue. I believe that > certmonger uses the NSS database where the certificate is stored so > since it is also doing this against Apache (which in theory trust is ok > for it to start at all) so I'm baffled. Hopefully the httpd logs > will be > enlightening. > > > > > I need to upgrade my IPA version. Before going for this I need to > have a > > replica of the existing one. Is it okay to have the replica while all > > these issues exist? > > > Yes, you should be able to create a replica, this shouldn't affect it. > > rob > From danieljamesscott at gmail.com Thu Jan 5 17:03:04 2012 From: danieljamesscott at gmail.com (Dan Scott) Date: Thu, 5 Jan 2012 12:03:04 -0500 Subject: [Freeipa-users] FreeIPA 2.1.4 replication In-Reply-To: <4F049F09.8000000@redhat.com> References: <4F049F09.8000000@redhat.com> Message-ID: On Wed, Jan 4, 2012 at 13:48, Rob Crittenden wrote: > Dan Scott wrote: >> >> Hi, >> >> Recently I've had some crash/hang problems with my FreeIPA 2 >> installation which appear solved using the updates-testing version of >> freeipa-server (2.1.4-2.fc16.x86_64) which I'm currently running on >> both servers (as a quick aside, does anyone know when 2.1.4 will be >> released to the main repos?). >> >> I'm still having problems creating replicas however. The replication >> process mostly completes, but fails with: >> >> Restarting IPA to initialize updates before performing deletes: >> ? [1/2]: stopping directory server >> ? [2/2]: starting directory server >> done configuring dirsrv. >> creation of replica failed: Command '/bin/systemctl restart >> krb5kdc.service' returned non-zero exit status 1 > > > You'd need to see why the kdc is failing to start. /var/log/krb5kdc.log is a > place to start. dmesg/messages may have info, as well as systemctl status > service.krb5kdc. Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): shutdown signal received Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 11 Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 12 Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 10 Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 9 Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): shutting down krb5kdc: Can't contact LDAP server - while initializing database for realm EXAMPLE.COM Does it mean the new replica's LDAP server, or the existing LDAP server? >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> [root at fileserver4 ~]# >> >> The replication appears to be working, but I'd like to have the >> configuration complete successfully to be sure. >> >> If I use the --setup-ca option, the process fails even earlier: >> >> Configuring certificate server: Estimated time 3 minutes 30 seconds >> ? [1/12]: creating certificate server user >> ? [2/12]: creating pki-ca instance >> ? [3/12]: configuring certificate server instance >> root ? ? ? ?: CRITICAL failed to configure ca instance Command >> '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' >> 'fileserver4.example.com' '-cs_port' '9445' '-client_certdb_dir' >> '/tmp/tmp-0h0omd' '-client_certdb_pwd' XXXXXXXX '-preop_pin' >> 'Vi8OHzzN0yjMDcqMv3aD' '-domain_name' 'IPA' '-admin_user' 'admin' >> '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX >> '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' >> '-agent_key_type' 'rsa' '-agent_cert_subject' >> 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'fileserver4.example.com' >> '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' >> XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' >> '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' >> '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' >> 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA >> Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP >> Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name' >> 'CN=fileserver4.example.com,O=EXAMPLE.COM' >> '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' >> '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' >> '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' >> '-clone_p12_password' XXXXXXXX '-sd_hostname' >> 'fileserver1.example.com' '-sd_admin_port' '443' '-sd_admin_name' >> 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' >> '-clone_uri' 'https://fileserver1.example.com:443'' returned non-zero >> exit status 255 >> creation of replica failed: Configuration of CA failed > > > You need to look in /var/log/pki-ca/debug to determine where it failed. IIRC > the last time we looked at this there was some issue with the security > domain. Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](Error): preauth pkinit failed to initialize: No realms configured correctly for pkinit support Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): setting up network... Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening on fd 9: udp 0.0.0.0.88 (pktinfo) krb5kdc: setsockopt(10,IPV6_V6ONLY,1) worked krb5kdc: No realms configured correctly for pkinit support - Cannot request packet info for udp socket address :: port 88 Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): skipping unrecognized local address family 17 Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): skipping unrecognized local address family 17 krb5kdc: setsockopt(10,IPV6_V6ONLY,1) worked Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening on fd 10: udp fe80::a00:27ff:fe5f:27a2%p2p1.88 krb5kdc: setsockopt(11,IPV6_V6ONLY,1) worked Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening on fd 12: tcp 0.0.0.0.88 Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening on fd 11: tcp ::.88 Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): set up 4 sockets Jan 03 10:48:51 fileserver4.example.com krb5kdc[2568](info): commencing operation The only errors in /var/log/pki-ca/debug are: Error: unknown type org.apache.catalina.connector.ResponseFacade Error: unknown type java.lang.Boolean Error: unknown type org.apache.catalina.connector.RequestFacade Thanks, Dan >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> [root at fileserver4 ~]# >> >> I'm running 389-ds-base-1.2.10-0.5.a5.fc16.x86_64, if that helps >> >> Can anyone help to fix this? I can send the log file from either >> attempt to someone if that would help. >> >> Thanks, >> >> Dan >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > From nalin at redhat.com Thu Jan 5 17:43:22 2012 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 5 Jan 2012 12:43:22 -0500 Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <4F05C3E3.4060904@redhat.com> References: <1325768982.8071.YahooMailClassic@web161305.mail.bf1.yahoo.com> <4F05C3E3.4060904@redhat.com> Message-ID: <20120105174322.GC6609@redhat.com> On Thu, Jan 05, 2012 at 10:38:11AM -0500, Rob Crittenden wrote: > My first thought was that there was a CA trust issue. I believe that > certmonger uses the NSS database where the certificate is stored so > since it is also doing this against Apache (which in theory trust is > ok for it to start at all) so I'm baffled. Hopefully the httpd logs > will be enlightening. The APIs it's using don't appear to let it do that, so unless there's something going on under the covers, the IPA submission helper trusts only the root certificate found in /etc/ipa/ca.crt. HTH, Nalin From dpal at redhat.com Thu Jan 5 20:01:59 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Jan 2012 15:01:59 -0500 Subject: [Freeipa-users] FreeIPA 2.1.4 replication In-Reply-To: References: <4F049F09.8000000@redhat.com> Message-ID: <4F0601B7.5030702@redhat.com> On 01/05/2012 12:03 PM, Dan Scott wrote: > On Wed, Jan 4, 2012 at 13:48, Rob Crittenden wrote: >> Dan Scott wrote: >>> Hi, >>> >>> Recently I've had some crash/hang problems with my FreeIPA 2 >>> installation which appear solved using the updates-testing version of >>> freeipa-server (2.1.4-2.fc16.x86_64) which I'm currently running on >>> both servers (as a quick aside, does anyone know when 2.1.4 will be >>> released to the main repos?). >>> >>> I'm still having problems creating replicas however. The replication >>> process mostly completes, but fails with: >>> >>> Restarting IPA to initialize updates before performing deletes: >>> [1/2]: stopping directory server >>> [2/2]: starting directory server >>> done configuring dirsrv. >>> creation of replica failed: Command '/bin/systemctl restart >>> krb5kdc.service' returned non-zero exit status 1 >> >> You'd need to see why the kdc is failing to start. /var/log/krb5kdc.log is a >> place to start. dmesg/messages may have info, as well as systemctl status >> service.krb5kdc. > Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): shutdown > signal received > Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 11 > Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 12 > Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 10 > Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 9 > Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): shutting down > krb5kdc: Can't contact LDAP server - while initializing database for > realm EXAMPLE.COM > > Does it mean the new replica's LDAP server, or the existing LDAP server? KDC failed to connect to local DS instance. >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> [root at fileserver4 ~]# >>> >>> The replication appears to be working, but I'd like to have the >>> configuration complete successfully to be sure. >>> >>> If I use the --setup-ca option, the process fails even earlier: >>> >>> Configuring certificate server: Estimated time 3 minutes 30 seconds >>> [1/12]: creating certificate server user >>> [2/12]: creating pki-ca instance >>> [3/12]: configuring certificate server instance >>> root : CRITICAL failed to configure ca instance Command >>> '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' >>> 'fileserver4.example.com' '-cs_port' '9445' '-client_certdb_dir' >>> '/tmp/tmp-0h0omd' '-client_certdb_pwd' XXXXXXXX '-preop_pin' >>> 'Vi8OHzzN0yjMDcqMv3aD' '-domain_name' 'IPA' '-admin_user' 'admin' >>> '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX >>> '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' >>> '-agent_key_type' 'rsa' '-agent_cert_subject' >>> 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'fileserver4.example.com' >>> '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' >>> XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' >>> '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' >>> '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' >>> 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA >>> Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP >>> Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name' >>> 'CN=fileserver4.example.com,O=EXAMPLE.COM' >>> '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' >>> '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' >>> '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' >>> '-clone_p12_password' XXXXXXXX '-sd_hostname' >>> 'fileserver1.example.com' '-sd_admin_port' '443' '-sd_admin_name' >>> 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' >>> '-clone_uri' 'https://fileserver1.example.com:443'' returned non-zero >>> exit status 255 >>> creation of replica failed: Configuration of CA failed >> >> You need to look in /var/log/pki-ca/debug to determine where it failed. IIRC >> the last time we looked at this there was some issue with the security >> domain. > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](Error): preauth > pkinit failed to initialize: No realms configured correctly for pkinit > support > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): setting > up network... > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening > on fd 9: udp 0.0.0.0.88 (pktinfo) > krb5kdc: setsockopt(10,IPV6_V6ONLY,1) worked > krb5kdc: No realms configured correctly for pkinit support - Cannot > request packet info for udp socket address :: port 88 > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): skipping > unrecognized local address family 17 > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): skipping > unrecognized local address family 17 > krb5kdc: setsockopt(10,IPV6_V6ONLY,1) worked > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening > on fd 10: udp fe80::a00:27ff:fe5f:27a2%p2p1.88 > krb5kdc: setsockopt(11,IPV6_V6ONLY,1) worked > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening > on fd 12: tcp 0.0.0.0.88 > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening > on fd 11: tcp ::.88 > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): set up 4 sockets > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2568](info): > commencing operation > > The only errors in /var/log/pki-ca/debug are: > Error: unknown type org.apache.catalina.connector.ResponseFacade > Error: unknown type java.lang.Boolean > Error: unknown type org.apache.catalina.connector.RequestFacade > > Thanks, > > Dan > >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> [root at fileserver4 ~]# >>> >>> I'm running 389-ds-base-1.2.10-0.5.a5.fc16.x86_64, if that helps >>> >>> Can anyone help to fix this? I can send the log file from either >>> attempt to someone if that would help. >>> >>> Thanks, >>> >>> Dan >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Thu Jan 5 20:11:58 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Jan 2012 15:11:58 -0500 Subject: [Freeipa-users] FreeIPA 2.1.4 replication In-Reply-To: References: <4F049F09.8000000@redhat.com> Message-ID: <4F06040E.8030702@redhat.com> Dan Scott wrote: > On Wed, Jan 4, 2012 at 13:48, Rob Crittenden wrote: >> Dan Scott wrote: >>> >>> Hi, >>> >>> Recently I've had some crash/hang problems with my FreeIPA 2 >>> installation which appear solved using the updates-testing version of >>> freeipa-server (2.1.4-2.fc16.x86_64) which I'm currently running on >>> both servers (as a quick aside, does anyone know when 2.1.4 will be >>> released to the main repos?). >>> >>> I'm still having problems creating replicas however. The replication >>> process mostly completes, but fails with: >>> >>> Restarting IPA to initialize updates before performing deletes: >>> [1/2]: stopping directory server >>> [2/2]: starting directory server >>> done configuring dirsrv. >>> creation of replica failed: Command '/bin/systemctl restart >>> krb5kdc.service' returned non-zero exit status 1 >> >> >> You'd need to see why the kdc is failing to start. /var/log/krb5kdc.log is a >> place to start. dmesg/messages may have info, as well as systemctl status >> service.krb5kdc. > > Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): shutdown > signal received > Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 11 > Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 12 > Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 10 > Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 9 > Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): shutting down > krb5kdc: Can't contact LDAP server - while initializing database for > realm EXAMPLE.COM > > Does it mean the new replica's LDAP server, or the existing LDAP server? The new LDAP server. I think Martin was looking at a similar problem where a service restart was returning but it was actually up and available. This might account for it (sort of a timing issue). Is your LDAP server running? > >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> [root at fileserver4 ~]# >>> >>> The replication appears to be working, but I'd like to have the >>> configuration complete successfully to be sure. >>> >>> If I use the --setup-ca option, the process fails even earlier: >>> >>> Configuring certificate server: Estimated time 3 minutes 30 seconds >>> [1/12]: creating certificate server user >>> [2/12]: creating pki-ca instance >>> [3/12]: configuring certificate server instance >>> root : CRITICAL failed to configure ca instance Command >>> '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' >>> 'fileserver4.example.com' '-cs_port' '9445' '-client_certdb_dir' >>> '/tmp/tmp-0h0omd' '-client_certdb_pwd' XXXXXXXX '-preop_pin' >>> 'Vi8OHzzN0yjMDcqMv3aD' '-domain_name' 'IPA' '-admin_user' 'admin' >>> '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX >>> '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' >>> '-agent_key_type' 'rsa' '-agent_cert_subject' >>> 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'fileserver4.example.com' >>> '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' >>> XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' >>> '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' >>> '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' >>> 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA >>> Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP >>> Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name' >>> 'CN=fileserver4.example.com,O=EXAMPLE.COM' >>> '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' >>> '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' >>> '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' >>> '-clone_p12_password' XXXXXXXX '-sd_hostname' >>> 'fileserver1.example.com' '-sd_admin_port' '443' '-sd_admin_name' >>> 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' >>> '-clone_uri' 'https://fileserver1.example.com:443'' returned non-zero >>> exit status 255 >>> creation of replica failed: Configuration of CA failed >> >> >> You need to look in /var/log/pki-ca/debug to determine where it failed. IIRC >> the last time we looked at this there was some issue with the security >> domain. > > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](Error): preauth > pkinit failed to initialize: No realms configured correctly for pkinit > support > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): setting > up network... > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening > on fd 9: udp 0.0.0.0.88 (pktinfo) > krb5kdc: setsockopt(10,IPV6_V6ONLY,1) worked > krb5kdc: No realms configured correctly for pkinit support - Cannot > request packet info for udp socket address :: port 88 > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): skipping > unrecognized local address family 17 > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): skipping > unrecognized local address family 17 > krb5kdc: setsockopt(10,IPV6_V6ONLY,1) worked > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening > on fd 10: udp fe80::a00:27ff:fe5f:27a2%p2p1.88 > krb5kdc: setsockopt(11,IPV6_V6ONLY,1) worked > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening > on fd 12: tcp 0.0.0.0.88 > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening > on fd 11: tcp ::.88 > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): set up 4 sockets > Jan 03 10:48:51 fileserver4.example.com krb5kdc[2568](info): > commencing operation > > The only errors in /var/log/pki-ca/debug are: > Error: unknown type org.apache.catalina.connector.ResponseFacade > Error: unknown type java.lang.Boolean > Error: unknown type org.apache.catalina.connector.RequestFacade dogtag is way more subtle, unfortunately. The installer basically acts as a simple HTTP client, POSTing information to the wizard on the server. So you have to look to see where it is blowing up it is almost never very obvious. If you want to send me the debug log I'll take a look and/or pass it onto the dogtag guys. rob From erinn.looneytriggs at gmail.com Thu Jan 5 20:35:04 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 05 Jan 2012 11:35:04 -0900 Subject: [Freeipa-users] HBAC issues Message-ID: <4F060978.8010303@gmail.com> I am trying to solve an issue that seems like it should be obvious but is not, to me at least. I am trying to allow a user to log into a single host, via GDM. I have configured a HBAC rule that allows access to the host from the host (actually to the group with the host in it from the same group). Unfortunately, logins are failing, what is more sssd is crashing when this is tried (perhaps they didn't design for a monkey like me :). The only way that I can get logins to work is for it to be allowed from any host, not from the host itself. So what, if any, are the tricks here that I am missing? I will send in the sssd crashing bit, abrt doesn't seem to want to list it even though it is is in /var/spool/abrt, so I get to monkey with it some other way. This is on a RHEL 6.2 client, connected to a RHEL 6.2 server. Thanks, -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From sgallagh at redhat.com Thu Jan 5 20:37:16 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 05 Jan 2012 15:37:16 -0500 Subject: [Freeipa-users] HBAC issues In-Reply-To: <4F060978.8010303@gmail.com> References: <4F060978.8010303@gmail.com> Message-ID: <1325795836.2411.3.camel@sgallagh520.sgallagh.bos.redhat.com> On Thu, 2012-01-05 at 11:35 -0900, Erinn Looney-Triggs wrote: > I am trying to solve an issue that seems like it should be obvious but > is not, to me at least. > > I am trying to allow a user to log into a single host, via GDM. I have > configured a HBAC rule that allows access to the host from the host > (actually to the group with the host in it from the same group). > Unfortunately, logins are failing, what is more sssd is crashing when > this is tried (perhaps they didn't design for a monkey like me :). > > The only way that I can get logins to work is for it to be allowed from > any host, not from the host itself. So what, if any, are the tricks here > that I am missing? > > I will send in the sssd crashing bit, abrt doesn't seem to want to list > it even though it is is in /var/spool/abrt, so I get to monkey with it > some other way. > > This is on a RHEL 6.2 client, connected to a RHEL 6.2 server. Any chance you might be hitting https://bugzilla.redhat.com/show_bug.cgi?id=771706 ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From erinn.looneytriggs at gmail.com Thu Jan 5 20:48:20 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 05 Jan 2012 11:48:20 -0900 Subject: [Freeipa-users] HBAC issues In-Reply-To: <1325795836.2411.3.camel@sgallagh520.sgallagh.bos.redhat.com> References: <4F060978.8010303@gmail.com> <1325795836.2411.3.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4F060C94.7020100@gmail.com> On 01/05/2012 11:37 AM, Stephen Gallagher wrote: > On Thu, 2012-01-05 at 11:35 -0900, Erinn Looney-Triggs wrote: >> I am trying to solve an issue that seems like it should be obvious but >> is not, to me at least. >> >> I am trying to allow a user to log into a single host, via GDM. I have >> configured a HBAC rule that allows access to the host from the host >> (actually to the group with the host in it from the same group). >> Unfortunately, logins are failing, what is more sssd is crashing when >> this is tried (perhaps they didn't design for a monkey like me :). >> >> The only way that I can get logins to work is for it to be allowed from >> any host, not from the host itself. So what, if any, are the tricks here >> that I am missing? >> >> I will send in the sssd crashing bit, abrt doesn't seem to want to list >> it even though it is is in /var/spool/abrt, so I get to monkey with it >> some other way. >> >> This is on a RHEL 6.2 client, connected to a RHEL 6.2 server. > > > Any chance you might be hitting > https://bugzilla.redhat.com/show_bug.cgi?id=771706 ? > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Yes that look about right, not able to confirm 100%, but that is probably the issue. Thanks, -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From sgallagh at redhat.com Thu Jan 5 20:54:15 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 05 Jan 2012 15:54:15 -0500 Subject: [Freeipa-users] HBAC issues In-Reply-To: <4F060C94.7020100@gmail.com> References: <4F060978.8010303@gmail.com> <1325795836.2411.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4F060C94.7020100@gmail.com> Message-ID: <1325796855.2411.6.camel@sgallagh520.sgallagh.bos.redhat.com> On Thu, 2012-01-05 at 11:48 -0900, Erinn Looney-Triggs wrote: > Yes that look about right, not able to confirm 100%, but that is > probably the issue. We're looking into it. However, I should point out that using srchost is a very unreliable means of restricting access. There are numerous problems with it, most notably because we have to rely on what PAM sends us in the srchost field, which is not defined in the spec, so different applications such as 'login' and 'sshd' sometimes put different values in those fields. In SSSD upstream, we're defaulting to ignoring srchost rules because they're 1) unreliable and 2) cause significant performance impact on networks with lots of host entries. Our general recommendation is that if you want to restrict access from specific hosts, it's usually a better idea to do this at the firewall level, rather than the HBAC level. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sylvainangers at gmail.com Thu Jan 5 21:20:37 2012 From: sylvainangers at gmail.com (Sylvain Angers) Date: Thu, 5 Jan 2012 16:20:37 -0500 Subject: [Freeipa-users] migration plan from local accounts Message-ID: Hello We have a mixed environment of AIX, and linux servers All our user accounts are still set locally - no NIS, and we do not have unique uid/gid toward our hosts!!! I am evaluating the possibility of using Redhat Identity management in our environment I have to figure out what AIX will be able to support - we would at least want to be able to limit who could access what on aix so if you have dealt with AIX, let me knows but here my main question My question is how do I deal with our current local users? When user DAVE get freeipa id 10000000567, do you have to chown every files he has on a local machine while he might has uid/gid 501 ? I guess we will have to byte the bullet and have a unique id for every users - right? Is there a simple migration plan from local to freeipa? do we have to migrate an account at the time do an account at the time, so if account doe not exist locally, it will check remote? I am missing the big picture thanks in advance -- Sylvain Angers -------------- next part -------------- An HTML attachment was scrubbed... URL: From kollathodi at yahoo.com Thu Jan 5 22:09:41 2012 From: kollathodi at yahoo.com (nasir nasir) Date: Thu, 5 Jan 2012 14:09:41 -0800 (PST) Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <4F05D6E7.7080208@redhat.com> Message-ID: <1325801381.75318.YahooMailClassic@web161302.mail.bf1.yahoo.com> Hi Rob, Added the directive "NSSEnforceValidCerts off" in /etc/httpd/conf.d/nss.conf and restarted httpd. Please find the /var/log/httpd/error_log [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in ignored[Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in ignored[Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in ignored[Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in ignored[Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in ignored[Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in ignored[Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in ignored[Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in ignored[Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in ignored[Fri Jan 06 01:06:29 2012] [error] Exception KeyError: KeyError(-1215723696,) in ignored[Fri Jan 06 01:06:29 2012] [notice] caught SIGTERM, shutting down[Fri Jan 06 01:06:29 2012] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)[Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate has expired[Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [notice] Digest: generating secret for digest authentication ...[Fri Jan 06 01:06:30 2012] [notice] Digest: done[Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Compiled for Python/2.6.2.[Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Runtime using Python/2.6.6.[Fri Jan 06 01:06:30 2012] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations[Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate has expired[Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate has expired[Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate has expired[Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate has expired[Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate has expired[Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate has expired[Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate has expired[Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate has expired[Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: 'Server-Cert'[Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: 'Server-Cert'[Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS START ***[Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS START *** # ipa-getcert listNumber of certificates and requests being tracked: 3.Request ID '20110619112648':? ? ? ? status: CA_UNREACHABLE? ? ? ? ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. ?SSL connect error).? ? ? ? stuck: yes? ? ? ? key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=HUGAYET.COM? ? ? ? subject: CN=openipa.hugayet.com,O=HUGAYET.COM? ? ? ? expires: 20111216112647? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yesRequest ID '20110619112705':? ? ? ? status: CA_UNREACHABLE? ? ? ? ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. ?SSL connect error).? ? ? ? stuck: yes? ? ? ? key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=HUGAYET.COM? ? ? ? subject: CN=openipa.hugayet.com,O=HUGAYET.COM? ? ? ? expires: 20111216112704? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yesRequest ID '20110619112721':? ? ? ? status: CA_UNREACHABLE? ? ? ? ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. ?Peer certificate cannot be authenticated with known CA certificates).? ? ? ? stuck: yes? ? ? ? key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'? ? ? ? certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'? ? ? ? CA: IPA? ? ? ? issuer: CN=Certificate Authority,O=HUGAYET.COM? ? ? ? subject: CN=openipa.hugayet.com,O=HUGAYET.COM? ? ? ? expires: 20111216112720? ? ? ? eku: id-kp-serverAuth? ? ? ? track: yes? ? ? ? auto-renew: yes Do we need to restart /etc/init.d/ipa service for all this to take effect? Nidal. --- On Thu, 1/5/12, Rob Crittenden wrote: From: Rob Crittenden Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: "nasir nasir" Cc: freeipa-users at redhat.com, fasilkaks at gmail.com Date: Thursday, January 5, 2012, 8:59 AM nasir nasir wrote: > Thanks for the input Rob, > > Please find below the /var/log/httpd/error_log > > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: 'Server-Cert' > [Thu Jan 05 19:50:46 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: 'Server-Cert' > [Thu Jan 05 19:50:46 2012] [error] Unable to verify certificate > 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the server > can start until the problem can be resolved. > > Do I need to add "NSSEnforceValidCerts off" in > /etc/httpd/conf.d/nss.conf? Please advice. > That explains why certmonger can't connect. Yes, for now add that directive and restart httpd. Then try the start-tracking again and see if it renews the cert. rob > Nidal. > > > --- On *Thu, 1/5/12, Rob Crittenden //* wrote: > > >? ???From: Rob Crittenden >? ???Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ???To: "nasir nasir" >? ???Cc: freeipa-users at redhat.com, fasilkaks at gmail.com >? ???Date: Thursday, January 5, 2012, 7:38 AM > >? ???nasir nasir wrote: >? ? ? > Thanks for the reply Rob. >? ? ? > >? ? ? > Please find below the output of your guidelines. >? ? ? > >? ? ? > # ipa-getkeytab -s xxxxxxx.xxxxxxx.com -p host/xxxxxx.xxxxxx.com -k >? ? ? > /etc/krb5.keytab >? ? ? > (the command was successful; it din't show any errors in the >? ???krb5kdc.log >? ? ? > or audit.log) >? ? ? > >? ? ? > # kinit -kt /etc/krb5.keytab host/xxxxxx.xxxxxx.com >? ? ? > >? ? ? > krb5kdc.log >? ? ? > ----------------- >? ? ? > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2431](info): AS_REQ (4 >? ???etypes >? ? ? > {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: >? ? ? > host/xxxxxx.xxxxxx.com at xxxxxx.COM >? ??? for >? ???krbtgt/xxxxxx.COM at xxxxxx.COM , >? ? ? > Additional pre-authentication required >? ? ? > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2427](info): AS_REQ (4 >? ???etypes >? ? ? > {18 17 16 23}) 192.168.1.10: ISSUE: authtime 1325766032, etypes >? ???{rep=18 >? ? ? > tkt=18 ses=18}, host/xxxxxx.xxxxxx.com at xxxxxx.COM >? ??? for >? ? ? > krbtgt/xxxxxx.COM at xxxxxx.COM >? ? ? > >? ? ? > # ipa-getcert list >? ? ? > Number of certificates and requests being tracked: 3. >? ? ? > Request ID '20110619112648': >? ? ? > status: CA_UNREACHABLE >? ? ? > ca-error: Server failed request, will retry: -504 (libcurl failed to >? ? ? > execute the HTTP POST transaction. SSL connect error). >? ? ? > stuck: yes >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxxx-COM//pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=xxxxxx.COM >? ? ? > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM >? ? ? > expires: 20111216112647 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > Request ID '20110619112705': >? ? ? > status: CA_UNREACHABLE >? ? ? > ca-error: Server failed request, will retry: -504 (libcurl failed to >? ? ? > execute the HTTP POST transaction. SSL connect error). >? ? ? > stuck: yes >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=xxxxxx.COM >? ? ? > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM >? ? ? > expires: 20111216112704 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > Request ID '20110619112721': >? ? ? > status: CA_UNREACHABLE >? ? ? > ca-error: Server failed request, will retry: -504 (libcurl failed to >? ? ? > execute the HTTP POST transaction. SSL connect error). >? ? ? > stuck: yes >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=xxxxxx.COM >? ? ? > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM >? ? ? > expires: 20111216112720 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > >? ? ? > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert >? ? ? > Request "20110619112721" modified. >? ? ? > >? ? ? > # ipa-getcert list >? ? ? > Number of certificates and requests being tracked: 3. >? ? ? > Request ID '20110619112648': >? ? ? > status: CA_UNREACHABLE >? ? ? > ca-error: Server failed request, will retry: -504 (libcurl failed to >? ? ? > execute the HTTP POST transaction. SSL connect error). >? ? ? > stuck: yes >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > expires: 20111216112647 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > Request ID '20110619112705': >? ? ? > status: CA_UNREACHABLE >? ? ? > ca-error: Server failed request, will retry: -504 (libcurl failed to >? ? ? > execute the HTTP POST transaction. SSL connect error). >? ? ? > stuck: yes >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > expires: 20111216112704 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > Request ID '20110619112721': >? ? ? > status: SUBMITTING >? ? ? > stuck: no >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > expires: 20111216112720 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > >? ? ? > and after few minutes, the status 'SUBMITTING' will be changed as >? ? ? > 'CA_UNREACHABLE' >? ? ? > Do we need to restart the /etc/init.d/ipa service for this? I am >? ???working >? ? ? > remotely. > >? ???It isn't logging enough information to know why it failed. Can you look >? ???in the Apache error log to see why the request failed? > >? ???My first thought was that there was a CA trust issue. I believe that >? ???certmonger uses the NSS database where the certificate is stored so >? ???since it is also doing this against Apache (which in theory trust is ok >? ???for it to start at all) so I'm baffled. Hopefully the httpd logs >? ???will be >? ???enlightening. > >? ? ? > >? ? ? > I need to upgrade my IPA version. Before going for this I need to >? ???have a >? ? ? > replica of the existing one. Is it okay to have the replica while all >? ? ? > these issues exist? > > >? ???Yes, you should be able to create a replica, this shouldn't affect it. > >? ???rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Jan 5 22:21:40 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Jan 2012 17:21:40 -0500 Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <1325801381.75318.YahooMailClassic@web161302.mail.bf1.yahoo.com> References: <1325801381.75318.YahooMailClassic@web161302.mail.bf1.yahoo.com> Message-ID: <4F062274.2050205@redhat.com> nasir nasir wrote: > Hi Rob, > > Added the directive "NSSEnforceValidCerts off" in > /etc/httpd/conf.d/nss.conf and restarted httpd. Please find the > /var/log/httpd/error_log > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [notice] caught SIGTERM, shutting down > [Fri Jan 06 01:06:29 2012] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [notice] Digest: generating secret for digest > authentication ... > [Fri Jan 06 01:06:30 2012] [notice] Digest: done > [Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Compiled for Python/2.6.2. > [Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Runtime using Python/2.6.6. > [Fri Jan 06 01:06:30 2012] [notice] Apache/2.2.15 (Unix) DAV/2 > mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 > configured -- resuming normal operations > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS START *** > [Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS START *** > > # ipa-getcert list > Number of certificates and requests being tracked: 3. > Request ID '20110619112648': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=HUGAYET.COM > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > expires: 20111216112647 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112705': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=HUGAYET.COM > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > expires: 20111216112704 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112721': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. Peer certificate cannot be > authenticated with known CA certificates). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=HUGAYET.COM > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > expires: 20111216112720 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > > Do we need to restart /etc/init.d/ipa service for all this to take effect? No, and be very careful if your 389-ds cert is also expired. This error really does mean that certmonger doesn't trust the SSL cert of your web server. Have you replaced your certs with something else? Does a simple command like: ipa user-show admin work? It may fail too due to the expired cert. You may have to turn time back on this machine, but that won't affect the untrusted CA. From what Nalin said, certmonger users /etc/ipa/ca.crt. This needs to match the CA that issued your Apache cert. rob > > Nidal. > > > --- On *Thu, 1/5/12, Rob Crittenden //* wrote: > > > From: Rob Crittenden > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > To: "nasir nasir" > Cc: freeipa-users at redhat.com, fasilkaks at gmail.com > Date: Thursday, January 5, 2012, 8:59 AM > > nasir nasir wrote: > > Thanks for the input Rob, > > > > Please find below the /var/log/httpd/error_log > > > > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: > 'Server-Cert' > > [Thu Jan 05 19:50:46 2012] [error] SSL Library Error: -8181 > Certificate > > has expired > > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: > 'Server-Cert' > > [Thu Jan 05 19:50:46 2012] [error] Unable to verify certificate > > 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the > server > > can start until the problem can be resolved. > > > > Do I need to add "NSSEnforceValidCerts off" in > > /etc/httpd/conf.d/nss.conf? Please advice. > > > > That explains why certmonger can't connect. Yes, for now add that > directive and restart httpd. Then try the start-tracking again and see > if it renews the cert. > > rob > > > Nidal. > > > > > > --- On *Thu, 1/5/12, Rob Crittenden / >/* wrote: > > > > > > From: Rob Crittenden > > > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > > To: "nasir nasir" > > > Cc: freeipa-users at redhat.com > , fasilkaks at gmail.com > > > Date: Thursday, January 5, 2012, 7:38 AM > > > > nasir nasir wrote: > > > Thanks for the reply Rob. > > > > > > Please find below the output of your guidelines. > > > > > > # ipa-getkeytab -s xxxxxxx.xxxxxxx.com -p host/xxxxxx.xxxxxx.com -k > > > /etc/krb5.keytab > > > (the command was successful; it din't show any errors in the > > krb5kdc.log > > > or audit.log) > > > > > > # kinit -kt /etc/krb5.keytab host/xxxxxx.xxxxxx.com > > > > > > krb5kdc.log > > > ----------------- > > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2431](info): AS_REQ (4 > > etypes > > > {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: > > > host/xxxxxx.xxxxxx.com at xxxxxx.COM > > > > for > > krbtgt/xxxxxx.COM at xxxxxx.COM > > >, > > > Additional pre-authentication required > > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2427](info): AS_REQ (4 > > etypes > > > {18 17 16 23}) 192.168.1.10: ISSUE: authtime 1325766032, etypes > > {rep=18 > > > tkt=18 ses=18}, host/xxxxxx.xxxxxx.com at xxxxxx.COM > > > > for > > > krbtgt/xxxxxx.COM at xxxxxx.COM > > > > > > > > > # ipa-getcert list > > > Number of certificates and requests being tracked: 3. > > > Request ID '20110619112648': > > > status: CA_UNREACHABLE > > > ca-error: Server failed request, will retry: -504 (libcurl > failed to > > > execute the HTTP POST transaction. SSL connect error). > > > stuck: yes > > > key pair storage: > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS > > > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxxx-COM//pwdfile.txt' > > > certificate: > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS > > > Certificate DB' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=xxxxxx.COM > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > > > expires: 20111216112647 > > > eku: id-kp-serverAuth > > > track: yes > > > auto-renew: yes > > > Request ID '20110619112705': > > > status: CA_UNREACHABLE > > > ca-error: Server failed request, will retry: -504 (libcurl > failed to > > > execute the HTTP POST transaction. SSL connect error). > > > stuck: yes > > > key pair storage: > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > > > certificate: > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > Certificate DB' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=xxxxxx.COM > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > > > expires: 20111216112704 > > > eku: id-kp-serverAuth > > > track: yes > > > auto-renew: yes > > > Request ID '20110619112721': > > > status: CA_UNREACHABLE > > > ca-error: Server failed request, will retry: -504 (libcurl > failed to > > > execute the HTTP POST transaction. SSL connect error). > > > stuck: yes > > > key pair storage: > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > certificate: > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > Certificate DB' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=xxxxxx.COM > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > > > expires: 20111216112720 > > > eku: id-kp-serverAuth > > > track: yes > > > auto-renew: yes > > > > > > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert > > > Request "20110619112721" modified. > > > > > > # ipa-getcert list > > > Number of certificates and requests being tracked: 3. > > > Request ID '20110619112648': > > > status: CA_UNREACHABLE > > > ca-error: Server failed request, will retry: -504 (libcurl > failed to > > > execute the HTTP POST transaction. SSL connect error). > > > stuck: yes > > > key pair storage: > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > > > Certificate > DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' > > > certificate: > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > > > Certificate DB' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > > expires: 20111216112647 > > > eku: id-kp-serverAuth > > > track: yes > > > auto-renew: yes > > > Request ID '20110619112705': > > > status: CA_UNREACHABLE > > > ca-error: Server failed request, will retry: -504 (libcurl > failed to > > > execute the HTTP POST transaction. SSL connect error). > > > stuck: yes > > > key pair storage: > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > > > certificate: > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > Certificate DB' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > > expires: 20111216112704 > > > eku: id-kp-serverAuth > > > track: yes > > > auto-renew: yes > > > Request ID '20110619112721': > > > status: SUBMITTING > > > stuck: no > > > key pair storage: > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > certificate: > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > Certificate DB' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > > expires: 20111216112720 > > > eku: id-kp-serverAuth > > > track: yes > > > auto-renew: yes > > > > > > and after few minutes, the status 'SUBMITTING' will be changed as > > > 'CA_UNREACHABLE' > > > Do we need to restart the /etc/init.d/ipa service for this? I am > > working > > > remotely. > > > > It isn't logging enough information to know why it failed. Can > you look > > in the Apache error log to see why the request failed? > > > > My first thought was that there was a CA trust issue. I believe that > > certmonger uses the NSS database where the certificate is stored so > > since it is also doing this against Apache (which in theory trust > is ok > > for it to start at all) so I'm baffled. Hopefully the httpd logs > > will be > > enlightening. > > > > > > > > I need to upgrade my IPA version. Before going for this I need to > > have a > > > replica of the existing one. Is it okay to have the replica > while all > > > these issues exist? > > > > > > Yes, you should be able to create a replica, this shouldn't > affect it. > > > > rob > > > From dpal at redhat.com Thu Jan 5 22:28:46 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Jan 2012 17:28:46 -0500 Subject: [Freeipa-users] migration plan from local accounts In-Reply-To: References: Message-ID: <4F06241E.9040200@redhat.com> On 01/05/2012 04:20 PM, Sylvain Angers wrote: > Hello > > We have a mixed environment of AIX, and linux servers > All our user accounts are still set locally - no NIS, and we do not > have unique uid/gid toward our hosts!!! > I am evaluating the possibility of using Redhat Identity management in > our environment > I have to figure out what AIX will be able to support - we would at > least want to be able to limit who could access what on aix > so if you have dealt with AIX, let me knows > > but here my main question > > My question is how do I deal with our current local users? This is a tough one... The assumption was that some kind of identity system is already in place. > When user DAVE get freeipa id 10000000567, do you have to chown every > files he has on a local machine while he might has uid/gid 501 ? Yes. > > I guess we will have to byte the bullet and have a unique id for every > users - right? Correct > Is there a simple migration plan from local to freeipa? You pretty much outlined it here. There is nothing better I know of. You user IDs are probably low enough that there is no overlap with user IDs from IdM. > do we have to migrate an account at the time do an account at the > time, so if account doe not exist locally, it will check remote? This is usually the case when you use files in the nsswitch.conf first and then ldap or sss. So logic would be: 1) Create a user in IdM with same name as a local user (if it is not already exists) 2) Find all files owned by local user and replace UID/GID with the ones from IPA user with the same name 3) Remove local user 4) Repeat for all local users 5) Repeat on every machine Step 1) might be a challenge from AIX machine so you might consider creating a list of all users first, precreating the users in IdM and then running a script that would do the rest on each of the machines you need to convert. > > I am missing the big picture > > thanks in advance > -- > Sylvain Angers > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From erinn.looneytriggs at gmail.com Thu Jan 5 22:07:59 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 05 Jan 2012 13:07:59 -0900 Subject: [Freeipa-users] HBAC issues In-Reply-To: <1325796855.2411.6.camel@sgallagh520.sgallagh.bos.redhat.com> References: <4F060978.8010303@gmail.com> <1325795836.2411.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4F060C94.7020100@gmail.com> <1325796855.2411.6.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4F061F3F.90008@gmail.com> On 01/05/2012 11:54 AM, Stephen Gallagher wrote: > On Thu, 2012-01-05 at 11:48 -0900, Erinn Looney-Triggs wrote: >> Yes that look about right, not able to confirm 100%, but that is >> probably the issue. > > > We're looking into it. However, I should point out that using srchost is > a very unreliable means of restricting access. There are numerous > problems with it, most notably because we have to rely on what PAM sends > us in the srchost field, which is not defined in the spec, so different > applications such as 'login' and 'sshd' sometimes put different values > in those fields. > > In SSSD upstream, we're defaulting to ignoring srchost rules because > they're 1) unreliable and 2) cause significant performance impact on > networks with lots of host entries. > > Our general recommendation is that if you want to restrict access from > specific hosts, it's usually a better idea to do this at the firewall > level, rather than the HBAC level. Well that kind of puts that whole HBAC thing on the skids doesn't it? Unfortunate that it works that way, and yes firewalling is always a good option. Thanks for the info, -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From kollathodi at yahoo.com Thu Jan 5 23:00:05 2012 From: kollathodi at yahoo.com (nasir nasir) Date: Thu, 5 Jan 2012 15:00:05 -0800 (PST) Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <4F062274.2050205@redhat.com> Message-ID: <1325804405.14753.YahooMailClassic@web161302.mail.bf1.yahoo.com> Rob, # ipa user-show adminipa: ERROR: cert validation failed for "CN=openipa.hugayet.com,O=HUGAYET.COM" ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.)ipa: ERROR: cert validation failed for "CN=openipa.hugayet.com,O=HUGAYET.COM" ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.)ipa: ERROR: cannot connect to 'any of the configured servers': https://openipa.hugayet.com/ipa/xml, https://openipa.hugayet.com/ipa/xml >>>>From what Nalin?said, certmonger users /etc/ipa/ca.crt. This needs to match the CA that?issued your Apache cert.>>>>>> How can we proceed further?? Nidal. --- On Thu, 1/5/12, Rob Crittenden wrote: From: Rob Crittenden Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: "nasir nasir" Cc: freeipa-users at redhat.com, fasilkaks at gmail.com Date: Thursday, January 5, 2012, 2:21 PM nasir nasir wrote: > Hi Rob, > > Added the directive "NSSEnforceValidCerts off" in > /etc/httpd/conf.d/nss.conf and restarted httpd. Please find the > /var/log/httpd/error_log > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > KeyError(-1215723696,) in '/usr/lib/python2.6/threading.pyc'> ignored > [Fri Jan 06 01:06:29 2012] [notice] caught SIGTERM, shutting down > [Fri Jan 06 01:06:29 2012] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [notice] Digest: generating secret for digest > authentication ... > [Fri Jan 06 01:06:30 2012] [notice] Digest: done > [Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Compiled for Python/2.6.2. > [Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Runtime using Python/2.6.6. > [Fri Jan 06 01:06:30 2012] [notice] Apache/2.2.15 (Unix) DAV/2 > mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 > configured -- resuming normal operations > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 Certificate > has expired > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > 'Server-Cert' > [Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS START *** > [Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS START *** > > # ipa-getcert list > Number of certificates and requests being tracked: 3. > Request ID '20110619112648': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=HUGAYET.COM > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > expires: 20111216112647 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112705': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. SSL connect error). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=HUGAYET.COM > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > expires: 20111216112704 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > Request ID '20110619112721': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction. Peer certificate cannot be > authenticated with known CA certificates). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=HUGAYET.COM > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > expires: 20111216112720 > eku: id-kp-serverAuth > track: yes > auto-renew: yes > > Do we need to restart /etc/init.d/ipa service for all this to take effect? No, and be very careful if your 389-ds cert is also expired. This error really does mean that certmonger doesn't trust the SSL cert of your web server. Have you replaced your certs with something else? Does a simple command like: ipa user-show admin work? It may fail too due to the expired cert. You may have to turn time back on this machine, but that won't affect the untrusted CA. From what Nalin said, certmonger users /etc/ipa/ca.crt. This needs to match the CA that issued your Apache cert. rob > > Nidal. > > > --- On *Thu, 1/5/12, Rob Crittenden //* wrote: > > >? ???From: Rob Crittenden >? ???Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ???To: "nasir nasir" >? ???Cc: freeipa-users at redhat.com, fasilkaks at gmail.com >? ???Date: Thursday, January 5, 2012, 8:59 AM > >? ???nasir nasir wrote: >? ? ? > Thanks for the input Rob, >? ? ? > >? ? ? > Please find below the /var/log/httpd/error_log >? ? ? > >? ? ? > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Thu Jan 05 19:50:46 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Thu Jan 05 19:50:46 2012] [error] Unable to verify certificate >? ? ? > 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the >? ???server >? ? ? > can start until the problem can be resolved. >? ? ? > >? ? ? > Do I need to add "NSSEnforceValidCerts off" in >? ? ? > /etc/httpd/conf.d/nss.conf? Please advice. >? ? ? > > >? ???That explains why certmonger can't connect. Yes, for now add that >? ???directive and restart httpd. Then try the start-tracking again and see >? ???if it renews the cert. > >? ???rob > >? ? ? > Nidal. >? ? ? > >? ? ? > >? ? ? > --- On *Thu, 1/5/12, Rob Crittenden /? ???>/* wrote: >? ? ? > >? ? ? > >? ? ? > From: Rob Crittenden ? ???> >? ? ? > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ? ? > To: "nasir nasir" ? ???> >? ? ? > Cc: freeipa-users at redhat.com >? ???, fasilkaks at gmail.com >? ??? >? ? ? > Date: Thursday, January 5, 2012, 7:38 AM >? ? ? > >? ? ? > nasir nasir wrote: >? ? ? > > Thanks for the reply Rob. >? ? ? > > >? ? ? > > Please find below the output of your guidelines. >? ? ? > > >? ? ? > > # ipa-getkeytab -s xxxxxxx.xxxxxxx.com -p host/xxxxxx.xxxxxx.com -k >? ? ? > > /etc/krb5.keytab >? ? ? > > (the command was successful; it din't show any errors in the >? ? ? > krb5kdc.log >? ? ? > > or audit.log) >? ? ? > > >? ? ? > > # kinit -kt /etc/krb5.keytab host/xxxxxx.xxxxxx.com >? ? ? > > >? ? ? > > krb5kdc.log >? ? ? > > ----------------- >? ? ? > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2431](info): AS_REQ (4 >? ? ? > etypes >? ? ? > > {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: >? ? ? > > host/xxxxxx.xxxxxx.com at xxxxxx.COM >? ??? >? ? ? > ? ???> for >? ? ? > krbtgt/xxxxxx.COM at xxxxxx.COM >? ??? >? ???? ???>, >? ? ? > > Additional pre-authentication required >? ? ? > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2427](info): AS_REQ (4 >? ? ? > etypes >? ? ? > > {18 17 16 23}) 192.168.1.10: ISSUE: authtime 1325766032, etypes >? ? ? > {rep=18 >? ? ? > > tkt=18 ses=18}, host/xxxxxx.xxxxxx.com at xxxxxx.COM >? ??? >? ? ? > ? ???> for >? ? ? > > krbtgt/xxxxxx.COM at xxxxxx.COM >? ??? >? ???? ???> >? ? ? > > >? ? ? > > # ipa-getcert list >? ? ? > > Number of certificates and requests being tracked: 3. >? ? ? > > Request ID '20110619112648': >? ? ? > > status: CA_UNREACHABLE >? ? ? > > ca-error: Server failed request, will retry: -504 (libcurl >? ???failed to >? ? ? > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > stuck: yes >? ? ? > > key pair storage: >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS >? ? ? > > Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxxx-COM//pwdfile.txt' >? ? ? > > certificate: >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS >? ? ? > > Certificate DB' >? ? ? > > CA: IPA >? ? ? > > issuer: CN=Certificate Authority,O=xxxxxx.COM >? ? ? > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM >? ? ? > > expires: 20111216112647 >? ? ? > > eku: id-kp-serverAuth >? ? ? > > track: yes >? ? ? > > auto-renew: yes >? ? ? > > Request ID '20110619112705': >? ? ? > > status: CA_UNREACHABLE >? ? ? > > ca-error: Server failed request, will retry: -504 (libcurl >? ???failed to >? ? ? > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > stuck: yes >? ? ? > > key pair storage: >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' >? ? ? > > certificate: >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > > Certificate DB' >? ? ? > > CA: IPA >? ? ? > > issuer: CN=Certificate Authority,O=xxxxxx.COM >? ? ? > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM >? ? ? > > expires: 20111216112704 >? ? ? > > eku: id-kp-serverAuth >? ? ? > > track: yes >? ? ? > > auto-renew: yes >? ? ? > > Request ID '20110619112721': >? ? ? > > status: CA_UNREACHABLE >? ? ? > > ca-error: Server failed request, will retry: -504 (libcurl >? ???failed to >? ? ? > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > stuck: yes >? ? ? > > key pair storage: >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > > certificate: >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > > Certificate DB' >? ? ? > > CA: IPA >? ? ? > > issuer: CN=Certificate Authority,O=xxxxxx.COM >? ? ? > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM >? ? ? > > expires: 20111216112720 >? ? ? > > eku: id-kp-serverAuth >? ? ? > > track: yes >? ? ? > > auto-renew: yes >? ? ? > > >? ? ? > > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert >? ? ? > > Request "20110619112721" modified. >? ? ? > > >? ? ? > > # ipa-getcert list >? ? ? > > Number of certificates and requests being tracked: 3. >? ? ? > > Request ID '20110619112648': >? ? ? > > status: CA_UNREACHABLE >? ? ? > > ca-error: Server failed request, will retry: -504 (libcurl >? ???failed to >? ? ? > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > stuck: yes >? ? ? > > key pair storage: >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS >? ? ? > > Certificate >? ???DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' >? ? ? > > certificate: >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS >? ? ? > > Certificate DB' >? ? ? > > CA: IPA >? ? ? > > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > > expires: 20111216112647 >? ? ? > > eku: id-kp-serverAuth >? ? ? > > track: yes >? ? ? > > auto-renew: yes >? ? ? > > Request ID '20110619112705': >? ? ? > > status: CA_UNREACHABLE >? ? ? > > ca-error: Server failed request, will retry: -504 (libcurl >? ???failed to >? ? ? > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > stuck: yes >? ? ? > > key pair storage: >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' >? ? ? > > certificate: >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > > Certificate DB' >? ? ? > > CA: IPA >? ? ? > > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > > expires: 20111216112704 >? ? ? > > eku: id-kp-serverAuth >? ? ? > > track: yes >? ? ? > > auto-renew: yes >? ? ? > > Request ID '20110619112721': >? ? ? > > status: SUBMITTING >? ? ? > > stuck: no >? ? ? > > key pair storage: >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > > certificate: >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > > Certificate DB' >? ? ? > > CA: IPA >? ? ? > > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > > expires: 20111216112720 >? ? ? > > eku: id-kp-serverAuth >? ? ? > > track: yes >? ? ? > > auto-renew: yes >? ? ? > > >? ? ? > > and after few minutes, the status 'SUBMITTING' will be changed as >? ? ? > > 'CA_UNREACHABLE' >? ? ? > > Do we need to restart the /etc/init.d/ipa service for this? I am >? ? ? > working >? ? ? > > remotely. >? ? ? > >? ? ? > It isn't logging enough information to know why it failed. Can >? ???you look >? ? ? > in the Apache error log to see why the request failed? >? ? ? > >? ? ? > My first thought was that there was a CA trust issue. I believe that >? ? ? > certmonger uses the NSS database where the certificate is stored so >? ? ? > since it is also doing this against Apache (which in theory trust >? ???is ok >? ? ? > for it to start at all) so I'm baffled. Hopefully the httpd logs >? ? ? > will be >? ? ? > enlightening. >? ? ? > >? ? ? > > >? ? ? > > I need to upgrade my IPA version. Before going for this I need to >? ? ? > have a >? ? ? > > replica of the existing one. Is it okay to have the replica >? ???while all >? ? ? > > these issues exist? >? ? ? > >? ? ? > >? ? ? > Yes, you should be able to create a replica, this shouldn't >? ???affect it. >? ? ? > >? ? ? > rob >? ? ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Jan 5 23:09:56 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Jan 2012 18:09:56 -0500 Subject: [Freeipa-users] HBAC issues In-Reply-To: <4F061F3F.90008@gmail.com> References: <4F060978.8010303@gmail.com> <1325795836.2411.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4F060C94.7020100@gmail.com> <1325796855.2411.6.camel@sgallagh520.sgallagh.bos.redhat.com> <4F061F3F.90008@gmail.com> Message-ID: <4F062DC4.6090509@redhat.com> On 01/05/2012 05:07 PM, Erinn Looney-Triggs wrote: > On 01/05/2012 11:54 AM, Stephen Gallagher wrote: >> On Thu, 2012-01-05 at 11:48 -0900, Erinn Looney-Triggs wrote: >>> Yes that look about right, not able to confirm 100%, but that is >>> probably the issue. >> >> We're looking into it. However, I should point out that using srchost is >> a very unreliable means of restricting access. There are numerous >> problems with it, most notably because we have to rely on what PAM sends >> us in the srchost field, which is not defined in the spec, so different >> applications such as 'login' and 'sshd' sometimes put different values >> in those fields. >> >> In SSSD upstream, we're defaulting to ignoring srchost rules because >> they're 1) unreliable and 2) cause significant performance impact on >> networks with lots of host entries. >> >> Our general recommendation is that if you want to restrict access from >> specific hosts, it's usually a better idea to do this at the firewall >> level, rather than the HBAC level. > Well that kind of puts that whole HBAC thing on the skids doesn't it? It still has value as you can define who can authenticate via which services and allow only ssh or physical access but not ftp to one set of users while enable ftp to others. > Unfortunate that it works that way, We tried our best but realized that there is no good way to get source host information reliably and also the performance was awful due to complexity of the searches that need to be conducted in this case. > and yes firewalling is always a good > option. > > Thanks for the info, > -Erinn > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Thu Jan 5 23:13:13 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 05 Jan 2012 18:13:13 -0500 (EST) Subject: [Freeipa-users] HBAC issues In-Reply-To: <4F061F3F.90008@gmail.com> References: <4F060978.8010303@gmail.com> <1325795836.2411.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4F060C94.7020100@gmail.com> <1325796855.2411.6.camel@sgallagh520.sgallagh.bos.redhat.com> <4F061F3F.90008@gmail.com> Message-ID: <57970649-8520-4A2C-B20D-10021496D49B@redhat.com> On Jan 5, 2012, at 5:48 PM, Erinn Looney-Triggs wrote: > On 01/05/2012 11:54 AM, Stephen Gallagher wrote: >> On Thu, 2012-01-05 at 11:48 -0900, Erinn Looney-Triggs wrote: >>> Yes that look about right, not able to confirm 100%, but that is >>> probably the issue. >> >> >> We're looking into it. However, I should point out that using srchost is >> a very unreliable means of restricting access. There are numerous >> problems with it, most notably because we have to rely on what PAM sends >> us in the srchost field, which is not defined in the spec, so different >> applications such as 'login' and 'sshd' sometimes put different values >> in those fields. >> >> In SSSD upstream, we're defaulting to ignoring srchost rules because >> they're 1) unreliable and 2) cause significant performance impact on >> networks with lots of host entries. >> >> Our general recommendation is that if you want to restrict access from >> specific hosts, it's usually a better idea to do this at the firewall >> level, rather than the HBAC level. > > Well that kind of puts that whole HBAC thing on the skids doesn't it? Well, target host works fine. The real problem is with accurately identifying the remote host that the connection originated from. So you can still write rules that say "only these users can log onto these hosts". > Unfortunate that it works that way, and yes firewalling is always a good > option. > > Thanks for the info, > -Erinn > > From sylvainangers at gmail.com Thu Jan 5 23:27:21 2012 From: sylvainangers at gmail.com (Sylvain Angers) Date: Thu, 5 Jan 2012 18:27:21 -0500 Subject: [Freeipa-users] migration plan from local accounts In-Reply-To: <4F06241E.9040200@redhat.com> References: <4F06241E.9040200@redhat.com> Message-ID: Hi again, by moving away from local account, to freeipa do we affect any of these numbers?: -group name length limits -group membership limits or they remain the same / as the under limit of the local os? On linux, I believe there will still be a limitation of 16 id per group, right? If anyone has some past experience with AIX, feel free to share with me I am really interested to ear about it Thank you! Sylvain Angers 2012/1/5 Dmitri Pal > ** > On 01/05/2012 04:20 PM, Sylvain Angers wrote: > > Hello > > We have a mixed environment of AIX, and linux servers > All our user accounts are still set locally - no NIS, and we do not have > unique uid/gid toward our hosts!!! > I am evaluating the possibility of using Redhat Identity management in our > environment > I have to figure out what AIX will be able to support - we would at least > want to be able to limit who could access what on aix > so if you have dealt with AIX, let me knows > > but here my main question > > My question is how do I deal with our current local users? > > > This is a tough one... The assumption was that some kind of identity > system is already in place. > > > When user DAVE get freeipa id 10000000567, do you have to chown every > files he has on a local machine while he might has uid/gid 501 ? > > > > Yes. > > > > I guess we will have to byte the bullet and have a unique id for every > users - right? > > > Correct > > > Is there a simple migration plan from local to freeipa? > > > You pretty much outlined it here. There is nothing better I know of. > You user IDs are probably low enough that there is no overlap with user > IDs from IdM. > > > do we have to migrate an account at the time do an account at the time, > so if account doe not exist locally, it will check remote? > > > This is usually the case when you use files in the nsswitch.conf first and > then ldap or sss. > So logic would be: > 1) Create a user in IdM with same name as a local user (if it is not > already exists) > 2) Find all files owned by local user and replace UID/GID with the ones > from IPA user with the same name > 3) Remove local user > 4) Repeat for all local users > 5) Repeat on every machine > > Step 1) might be a challenge from AIX machine so you might consider > creating a list of all users first, precreating the users in IdM and then > running a script that would do the rest on each of the machines you need to > convert. > > > I am missing the big picture > > thanks in advance > -- > Sylvain Angers > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Sylvain Angers -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Jan 5 23:41:32 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Jan 2012 18:41:32 -0500 Subject: [Freeipa-users] migration plan from local accounts In-Reply-To: References: <4F06241E.9040200@redhat.com> Message-ID: <4F06352C.6060104@redhat.com> On 01/05/2012 06:27 PM, Sylvain Angers wrote: > Hi again, > > by moving away from local account, to freeipa do we affect any of > these numbers?: > > -group name length limits > -group membership limits > > or they remain the same / as the under limit of the local os? > On linux, I believe there will still be a limitation of 16 id per > group, right? This is a very old limitation that is no longer a problem for quite a while. AFAIR starting AIX5.3 AIX has a decent PAM stack and one can use pam_ldap and nss_ldap with it. 5.2 does not have proper capabilities. What version do you use? The limitations you are concerned are really dictated by the capabilities of the OS and client software. AFAIK nss_ldap has no limit on number of the users in a group. IPA assumes that there are no such limitations and allows any number of users in a group. > If anyone has some past experience with AIX, feel free to share with me > > I am really interested to ear about it > > Thank you! > > Sylvain Angers > > 2012/1/5 Dmitri Pal > > > On 01/05/2012 04:20 PM, Sylvain Angers wrote: >> Hello >> >> We have a mixed environment of AIX, and linux servers >> All our user accounts are still set locally - no NIS, and we do >> not have unique uid/gid toward our hosts!!! >> I am evaluating the possibility of using Redhat >> Identity management in our environment >> I have to figure out what AIX will be able to support - we would >> at least want to be able to limit who could access what on aix >> so if you have dealt with AIX, let me knows >> >> but here my main question >> >> My question is how do I deal with our current local users? > > This is a tough one... The assumption was that some kind of > identity system is already in place. > > >> When user DAVE get freeipa id 10000000567, do you have to chown >> every files he has on a local machine while he might has uid/gid >> 501 ? > > > Yes. > > >> >> I guess we will have to byte the bullet and have a unique id for >> every users - right? > > Correct > > >> Is there a simple migration plan from local to freeipa? > > You pretty much outlined it here. There is nothing better I know of. > You user IDs are probably low enough that there is no overlap with > user IDs from IdM. > > >> do we have to migrate an account at the time do an account at the >> time, so if account doe not exist locally, it will check remote? > > This is usually the case when you use files in the nsswitch.conf > first and then ldap or sss. > So logic would be: > 1) Create a user in IdM with same name as a local user (if it is > not already exists) > 2) Find all files owned by local user and replace UID/GID with the > ones from IPA user with the same name > 3) Remove local user > 4) Repeat for all local users > 5) Repeat on every machine > > Step 1) might be a challenge from AIX machine so you might > consider creating a list of all users first, precreating the users > in IdM and then running a script that would do the rest on each of > the machines you need to convert. > >> >> I am missing the big picture >> >> thanks in advance >> -- >> Sylvain Angers >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > Sylvain Angers > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Jan 6 00:44:59 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 05 Jan 2012 19:44:59 -0500 Subject: [Freeipa-users] migration plan from local accounts In-Reply-To: References: Message-ID: <1325810699.30661.161.camel@willson.li.ssimo.org> On Thu, 2012-01-05 at 16:20 -0500, Sylvain Angers wrote: > Hello > > > We have a mixed environment of AIX, and linux servers > All our user accounts are still set locally - no NIS, and we do not > have unique uid/gid toward our hosts!!! > I am evaluating the possibility of using Redhat Identity management in > our environment > I have to figure out what AIX will be able to support - we would at > least want to be able to limit who could access what on aix > so if you have dealt with AIX, let me knows > > > but here my main question > > > My question is how do I deal with our current local users? > When user DAVE get freeipa id 10000000567, do you have to chown every > files he has on a local machine while he might has uid/gid 501 ? Are your usernames aligned ? If so you can do the migration in steps. Start with creating a FreeIPA server with all your users named the same as what you are currently using on your machines. Also if you have a mojority of machines that use the same name<->uid mapping you may think of forcing the same name<->uid mapping in freeipa, but unless you ahev a substantial number of machines that agree on all uid then it is probably much better to have a clean break against all machine so that you are not tricked on machines where only a susbset matches. Once you have the server up you can start unifying just the authentication part by enabling kerberos authentication for your local users on the AIX machine but still using the local accounts for uid/gid purposes. Once login is unified on kerberos you can go and convert one machine at a time to use ldap instead of local file and perform the necessary uid changes on file acls. For groups I'd be more careful, the problem there is that if you have different groupings on different machines just assuming groups are the same because they have the same name may open up security issues. One way to handle that would be to deprecate all old groups and create new groups in freeipa with names that do not match any of the local groups you currently have, then determine a policy to reassign within the next year group permissions on files slowly phasing out local groups. > I guess we will have to byte the bullet and have a unique id for every > users - right? In the long term yes, but above I gave you a way to at least have a migration that you can handle over a period of time instead of having to change all your machines in one night. > Is there a simple migration plan from local to freeipa? UID/GID migrations unfortunately are never simple. I have been involved with this issues for years and there are no magic bullets, but there are ways to mitigate the impact of a migration so that it becomes manageable at least. One more piece of advice, verify if you are using NFS anywhere, because each machine connected to a NFS server becomes part of a "virtual cluster" that needs to either be broken or converted all at the same time, making migrations suddenly a bit more difficult. > do we have to migrate an account at the time do an account at the > time, so if account doe not exist locally, it will check remote? This depdends very much on how AIX manages to discover users. On linux depending on the nsswitch.conf order of database a local user can prevail on a remote one, but I do not recall how that works with AIX, which uses LAM modules (IIRC). > I am missing the big picture HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Jan 6 00:50:51 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 05 Jan 2012 19:50:51 -0500 Subject: [Freeipa-users] migration plan from local accounts In-Reply-To: References: <4F06241E.9040200@redhat.com> Message-ID: <1325811051.30661.165.camel@willson.li.ssimo.org> On Thu, 2012-01-05 at 18:27 -0500, Sylvain Angers wrote: > Hi again, > > > by moving away from local account, to freeipa do we affect any of > these numbers?: > > > -group name length limits > -group membership limits > > > or they remain the same / as the under limit of the local os? > On linux, I believe there will still be a limitation of 16 id per > group, right? Linux has a "limitation" of 65K groups per user, and this has been true for many years now. If you use NFS with sys auth instead of krb5 auth then you have a limitation of 16 groups per user, but this is a protocol limitation valid for all OSs, it is not a limitation of Linux. And using krb5 auth there is no such limitation. > > If anyone has some past experience with AIX, feel free to share with > me We did some qualification/documentation testing on AIX a while back. All I can say is that AIX can work agains FreeIPA just fine, but I am in no way an AIX expert and the docs we have on freeipa.org are all I can tell you to use as I already forgot all the details we dicovered at the time we tested AIX :) > I am really interested to ear about it Let me know if there is anything unclear about AIX clients in the documentation on freeipa.org. Simo. -- Simo Sorce * Red Hat, Inc * New York From JR.Aquino at citrix.com Fri Jan 6 04:22:53 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 6 Jan 2012 04:22:53 +0000 Subject: [Freeipa-users] HBAC issues In-Reply-To: <57970649-8520-4A2C-B20D-10021496D49B@redhat.com> References: <4F060978.8010303@gmail.com> <1325795836.2411.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4F060C94.7020100@gmail.com> <1325796855.2411.6.camel@sgallagh520.sgallagh.bos.redhat.com> <4F061F3F.90008@gmail.com>, <57970649-8520-4A2C-B20D-10021496D49B@redhat.com> Message-ID: On Jan 5, 2012, at 3:14 PM, "Stephen Gallagher" wrote: > > > On Jan 5, 2012, at 5:48 PM, Erinn Looney-Triggs wrote: > >> On 01/05/2012 11:54 AM, Stephen Gallagher wrote: >>> On Thu, 2012-01-05 at 11:48 -0900, Erinn Looney-Triggs wrote: >>>> Yes that look about right, not able to confirm 100%, but that is >>>> probably the issue. >>> >>> >>> We're looking into it. However, I should point out that using srchost is >>> a very unreliable means of restricting access. There are numerous >>> problems with it, most notably because we have to rely on what PAM sends >>> us in the srchost field, which is not defined in the spec, so different >>> applications such as 'login' and 'sshd' sometimes put different values >>> in those fields. >>> >>> In SSSD upstream, we're defaulting to ignoring srchost rules because >>> they're 1) unreliable and 2) cause significant performance impact on >>> networks with lots of host entries. >>> >>> Our general recommendation is that if you want to restrict access from >>> specific hosts, it's usually a better idea to do this at the firewall >>> level, rather than the HBAC level. >> >> Well that kind of puts that whole HBAC thing on the skids doesn't it? > > Well, target host works fine. The real problem is with accurately identifying the remote host that the connection originated from. > > So you can still write rules that say "only these users can log onto these hosts". If you absoluelty must use it I have found that access.conf works well enough to limit srchost ssh access: http://linux.die.net/man/5/access. > >> Unfortunate that it works that way, and yes firewalling is always a good >> option. >> >> Thanks for the info, >> -Erinn >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Fri Jan 6 15:21:11 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Jan 2012 10:21:11 -0500 Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <1325804405.14753.YahooMailClassic@web161302.mail.bf1.yahoo.com> References: <1325804405.14753.YahooMailClassic@web161302.mail.bf1.yahoo.com> Message-ID: <4F071167.70008@redhat.com> nasir nasir wrote: > Rob, > > # ipa user-show admin > ipa: ERROR: cert validation failed for > "CN=openipa.hugayet.com,O=HUGAYET.COM" ((SEC_ERROR_EXPIRED_CERTIFICATE) > Peer's Certificate has expired.) > ipa: ERROR: cert validation failed for > "CN=openipa.hugayet.com,O=HUGAYET.COM" ((SEC_ERROR_EXPIRED_CERTIFICATE) > Peer's Certificate has expired.) > ipa: ERROR: cannot connect to 'any of the configured servers': > https://openipa.hugayet.com/ipa/xml, https://openipa.hugayet.com/ipa/xml > > >>>>From what Nalin said, certmonger users /etc/ipa/ca.crt. This needs > to match the CA that issued your Apache cert.>>>>>> > > How can we proceed further? I think you're going to need to set the system time back to when the certificate is valid to do the renewal. rob > > Nidal. > > > --- On *Thu, 1/5/12, Rob Crittenden //*wrote: > > > From: Rob Crittenden > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > To: "nasir nasir" > Cc: freeipa-users at redhat.com, fasilkaks at gmail.com > Date: Thursday, January 5, 2012, 2:21 PM > > nasir nasir wrote: > > Hi Rob, > > > > Added the directive "NSSEnforceValidCerts off" in > > /etc/httpd/conf.d/nss.conf and restarted httpd. Please find the > > /var/log/httpd/error_log > > > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > KeyError(-1215723696,) in > '/usr/lib/python2.6/threading.pyc'> ignored > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > KeyError(-1215723696,) in > '/usr/lib/python2.6/threading.pyc'> ignored > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > KeyError(-1215723696,) in > '/usr/lib/python2.6/threading.pyc'> ignored > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > KeyError(-1215723696,) in > '/usr/lib/python2.6/threading.pyc'> ignored > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > KeyError(-1215723696,) in > '/usr/lib/python2.6/threading.pyc'> ignored > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > KeyError(-1215723696,) in > '/usr/lib/python2.6/threading.pyc'> ignored > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > KeyError(-1215723696,) in > '/usr/lib/python2.6/threading.pyc'> ignored > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > KeyError(-1215723696,) in > '/usr/lib/python2.6/threading.pyc'> ignored > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > KeyError(-1215723696,) in > '/usr/lib/python2.6/threading.pyc'> ignored > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > KeyError(-1215723696,) in > '/usr/lib/python2.6/threading.pyc'> ignored > > [Fri Jan 06 01:06:29 2012] [notice] caught SIGTERM, shutting down > > [Fri Jan 06 01:06:29 2012] [notice] suEXEC mechanism enabled > (wrapper: > > /usr/sbin/suexec) > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > Certificate > > has expired > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [notice] Digest: generating secret for > digest > > authentication ... > > [Fri Jan 06 01:06:30 2012] [notice] Digest: done > > [Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Compiled for > Python/2.6.2. > > [Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Runtime using > Python/2.6.6. > > [Fri Jan 06 01:06:30 2012] [notice] Apache/2.2.15 (Unix) DAV/2 > > mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 > Python/2.6.6 > > configured -- resuming normal operations > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > Certificate > > has expired > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > Certificate > > has expired > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > Certificate > > has expired > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > Certificate > > has expired > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > Certificate > > has expired > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > Certificate > > has expired > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > Certificate > > has expired > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > Certificate > > has expired > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > > 'Server-Cert' > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: > > 'Server-Cert' > > [Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS START *** > > [Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS START *** > > > > # ipa-getcert list > > Number of certificates and requests being tracked: 3. > > Request ID '20110619112648': > > status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: -504 (libcurl failed to > > execute the HTTP POST transaction. SSL connect error). > > stuck: yes > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > expires: 20111216112647 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > Request ID '20110619112705': > > status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: -504 (libcurl failed to > > execute the HTTP POST transaction. SSL connect error). > > stuck: yes > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > expires: 20111216112704 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > Request ID '20110619112721': > > status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: -504 (libcurl failed to > > execute the HTTP POST transaction. Peer certificate cannot be > > authenticated with known CA certificates). > > stuck: yes > > key pair storage: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > expires: 20111216112720 > > eku: id-kp-serverAuth > > track: yes > > auto-renew: yes > > > > Do we need to restart /etc/init.d/ipa service for all this to > take effect? > > No, and be very careful if your 389-ds cert is also expired. > > This error really does mean that certmonger doesn't trust the SSL cert > of your web server. Have you replaced your certs with something else? > > Does a simple command like: ipa user-show admin work? > > It may fail too due to the expired cert. You may have to turn time back > on this machine, but that won't affect the untrusted CA. From what > Nalin > said, certmonger users /etc/ipa/ca.crt. This needs to match the CA that > issued your Apache cert. > > rob > > > > > Nidal. > > > > > > --- On *Thu, 1/5/12, Rob Crittenden / >/* wrote: > > > > > > From: Rob Crittenden > > > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > > To: "nasir nasir" > > > Cc: freeipa-users at redhat.com > , fasilkaks at gmail.com > > > Date: Thursday, January 5, 2012, 8:59 AM > > > > nasir nasir wrote: > > > Thanks for the input Rob, > > > > > > Please find below the /var/log/httpd/error_log > > > > > > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: > > 'Server-Cert' > > > [Thu Jan 05 19:50:46 2012] [error] SSL Library Error: -8181 > > Certificate > > > has expired > > > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: > > 'Server-Cert' > > > [Thu Jan 05 19:50:46 2012] [error] Unable to verify certificate > > > 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the > > server > > > can start until the problem can be resolved. > > > > > > Do I need to add "NSSEnforceValidCerts off" in > > > /etc/httpd/conf.d/nss.conf? Please advice. > > > > > > > That explains why certmonger can't connect. Yes, for now add that > > directive and restart httpd. Then try the start-tracking again > and see > > if it renews the cert. > > > > rob > > > > > Nidal. > > > > > > > > > --- On *Thu, 1/5/12, Rob Crittenden / > > >>/* wrote: > > > > > > > > > From: Rob Crittenden > > >> > > > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > > > To: "nasir nasir" > > >> > > > Cc: freeipa-users at redhat.com > > > >, fasilkaks at gmail.com > > > > > > > Date: Thursday, January 5, 2012, 7:38 AM > > > > > > nasir nasir wrote: > > > > Thanks for the reply Rob. > > > > > > > > Please find below the output of your guidelines. > > > > > > > > # ipa-getkeytab -s xxxxxxx.xxxxxxx.com -p > host/xxxxxx.xxxxxx.com -k > > > > /etc/krb5.keytab > > > > (the command was successful; it din't show any errors in the > > > krb5kdc.log > > > > or audit.log) > > > > > > > > # kinit -kt /etc/krb5.keytab host/xxxxxx.xxxxxx.com > > > > > > > > krb5kdc.log > > > > ----------------- > > > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2431](info): AS_REQ (4 > > > etypes > > > > {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: > > > > host/xxxxxx.xxxxxx.com at xxxxxx.COM > > > > > > > > > >> for > > > krbtgt/xxxxxx.COM at xxxxxx.COM > > > > > > > >>, > > > > Additional pre-authentication required > > > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2427](info): AS_REQ (4 > > > etypes > > > > {18 17 16 23}) 192.168.1.10: ISSUE: authtime 1325766032, etypes > > > {rep=18 > > > > tkt=18 ses=18}, host/xxxxxx.xxxxxx.com at xxxxxx.COM > > > > > > > > > >> for > > > > krbtgt/xxxxxx.COM at xxxxxx.COM > > > > > > > > >> > > > > > > > > # ipa-getcert list > > > > Number of certificates and requests being tracked: 3. > > > > Request ID '20110619112648': > > > > status: CA_UNREACHABLE > > > > ca-error: Server failed request, will retry: -504 (libcurl > > failed to > > > > execute the HTTP POST transaction. SSL connect error). > > > > stuck: yes > > > > key pair storage: > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS > > > > Certificate > DB',pinfile='/etc/dirsrv/slapd-xxxxxx-COM//pwdfile.txt' > > > > certificate: > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS > > > > Certificate DB' > > > > CA: IPA > > > > issuer: CN=Certificate Authority,O=xxxxxx.COM > > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > > > > expires: 20111216112647 > > > > eku: id-kp-serverAuth > > > > track: yes > > > > auto-renew: yes > > > > Request ID '20110619112705': > > > > status: CA_UNREACHABLE > > > > ca-error: Server failed request, will retry: -504 (libcurl > > failed to > > > > execute the HTTP POST transaction. SSL connect error). > > > > stuck: yes > > > > key pair storage: > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > > > > certificate: > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > > Certificate DB' > > > > CA: IPA > > > > issuer: CN=Certificate Authority,O=xxxxxx.COM > > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > > > > expires: 20111216112704 > > > > eku: id-kp-serverAuth > > > > track: yes > > > > auto-renew: yes > > > > Request ID '20110619112721': > > > > status: CA_UNREACHABLE > > > > ca-error: Server failed request, will retry: -504 (libcurl > > failed to > > > > execute the HTTP POST transaction. SSL connect error). > > > > stuck: yes > > > > key pair storage: > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > > certificate: > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > > Certificate DB' > > > > CA: IPA > > > > issuer: CN=Certificate Authority,O=xxxxxx.COM > > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > > > > expires: 20111216112720 > > > > eku: id-kp-serverAuth > > > > track: yes > > > > auto-renew: yes > > > > > > > > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert > > > > Request "20110619112721" modified. > > > > > > > > # ipa-getcert list > > > > Number of certificates and requests being tracked: 3. > > > > Request ID '20110619112648': > > > > status: CA_UNREACHABLE > > > > ca-error: Server failed request, will retry: -504 (libcurl > > failed to > > > > execute the HTTP POST transaction. SSL connect error). > > > > stuck: yes > > > > key pair storage: > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > > > > Certificate > > DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' > > > > certificate: > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > > > > Certificate DB' > > > > CA: IPA > > > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > > > expires: 20111216112647 > > > > eku: id-kp-serverAuth > > > > track: yes > > > > auto-renew: yes > > > > Request ID '20110619112705': > > > > status: CA_UNREACHABLE > > > > ca-error: Server failed request, will retry: -504 (libcurl > > failed to > > > > execute the HTTP POST transaction. SSL connect error). > > > > stuck: yes > > > > key pair storage: > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > > > > certificate: > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > > Certificate DB' > > > > CA: IPA > > > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > > > expires: 20111216112704 > > > > eku: id-kp-serverAuth > > > > track: yes > > > > auto-renew: yes > > > > Request ID '20110619112721': > > > > status: SUBMITTING > > > > stuck: no > > > > key pair storage: > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > > certificate: > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > > Certificate DB' > > > > CA: IPA > > > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > > > expires: 20111216112720 > > > > eku: id-kp-serverAuth > > > > track: yes > > > > auto-renew: yes > > > > > > > > and after few minutes, the status 'SUBMITTING' will be changed as > > > > 'CA_UNREACHABLE' > > > > Do we need to restart the /etc/init.d/ipa service for this? I am > > > working > > > > remotely. > > > > > > It isn't logging enough information to know why it failed. Can > > you look > > > in the Apache error log to see why the request failed? > > > > > > My first thought was that there was a CA trust issue. I believe > that > > > certmonger uses the NSS database where the certificate is stored so > > > since it is also doing this against Apache (which in theory trust > > is ok > > > for it to start at all) so I'm baffled. Hopefully the httpd logs > > > will be > > > enlightening. > > > > > > > > > > > I need to upgrade my IPA version. Before going for this I need to > > > have a > > > > replica of the existing one. Is it okay to have the replica > > while all > > > > these issues exist? > > > > > > > > > Yes, you should be able to create a replica, this shouldn't > > affect it. > > > > > > rob > > > > > > From kollathodi at yahoo.com Fri Jan 6 17:12:16 2012 From: kollathodi at yahoo.com (nasir nasir) Date: Fri, 6 Jan 2012 09:12:16 -0800 (PST) Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <4F071167.70008@redhat.com> Message-ID: <1325869936.25354.YahooMailClassic@web161301.mail.bf1.yahoo.com> Thanks for the input Rob, We have already did it with your previous input and everything got normal. But the ipa user-show admin command gave the following errors.# ipa user-show adminipa: ERROR: cert validation failed for "CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.)ipa: ERROR: cert validation failed for "CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.)ipa: ERROR: cannot connect to 'any of the configured servers': https://xxxxxx.xxxxxx.com/ipa/xml, https://xxxxxx.xxxxxx.com/ipa/xml Regardless of the above error, everything seems to be working fine.Now we need to have the replica of the server before going for an upgrade of IPA.? Thank you all for the wonderful support during our hard times.? Nidal. --- On Fri, 1/6/12, Rob Crittenden wrote: From: Rob Crittenden Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: "nasir nasir" Cc: freeipa-users at redhat.com, fasilkaks at gmail.com Date: Friday, January 6, 2012, 7:21 AM nasir nasir wrote: > Rob, > > # ipa user-show admin > ipa: ERROR: cert validation failed for > "CN=openipa.hugayet.com,O=HUGAYET.COM" ((SEC_ERROR_EXPIRED_CERTIFICATE) > Peer's Certificate has expired.) > ipa: ERROR: cert validation failed for > "CN=openipa.hugayet.com,O=HUGAYET.COM" ((SEC_ERROR_EXPIRED_CERTIFICATE) > Peer's Certificate has expired.) > ipa: ERROR: cannot connect to 'any of the configured servers': > https://openipa.hugayet.com/ipa/xml, https://openipa.hugayet.com/ipa/xml > >? >>>>From what Nalin said, certmonger users /etc/ipa/ca.crt. This needs > to match the CA that issued your Apache cert.>>>>>> > > How can we proceed further? I think you're going to need to set the system time back to when the certificate is valid to do the renewal. rob > > Nidal. > > > --- On *Thu, 1/5/12, Rob Crittenden //*wrote: > > >? ???From: Rob Crittenden >? ???Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ???To: "nasir nasir" >? ???Cc: freeipa-users at redhat.com, fasilkaks at gmail.com >? ???Date: Thursday, January 5, 2012, 2:21 PM > >? ???nasir nasir wrote: >? ? ? > Hi Rob, >? ? ? > >? ? ? > Added the directive "NSSEnforceValidCerts off" in >? ? ? > /etc/httpd/conf.d/nss.conf and restarted httpd. Please find the >? ? ? > /var/log/httpd/error_log >? ? ? > >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [notice] caught SIGTERM, shutting down >? ? ? > [Fri Jan 06 01:06:29 2012] [notice] suEXEC mechanism enabled >? ???(wrapper: >? ? ? > /usr/sbin/suexec) >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [notice] Digest: generating secret for >? ???digest >? ? ? > authentication ... >? ? ? > [Fri Jan 06 01:06:30 2012] [notice] Digest: done >? ? ? > [Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Compiled for >? ???Python/2.6.2. >? ? ? > [Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Runtime using >? ???Python/2.6.6. >? ? ? > [Fri Jan 06 01:06:30 2012] [notice] Apache/2.2.15 (Unix) DAV/2 >? ? ? > mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 >? ???Python/2.6.6 >? ? ? > configured -- resuming normal operations >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS START *** >? ? ? > [Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS START *** >? ? ? > >? ? ? > # ipa-getcert list >? ? ? > Number of certificates and requests being tracked: 3. >? ? ? > Request ID '20110619112648': >? ? ? > status: CA_UNREACHABLE >? ? ? > ca-error: Server failed request, will retry: -504 (libcurl failed to >? ? ? > execute the HTTP POST transaction. SSL connect error). >? ? ? > stuck: yes >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > expires: 20111216112647 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > Request ID '20110619112705': >? ? ? > status: CA_UNREACHABLE >? ? ? > ca-error: Server failed request, will retry: -504 (libcurl failed to >? ? ? > execute the HTTP POST transaction. SSL connect error). >? ? ? > stuck: yes >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > expires: 20111216112704 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > Request ID '20110619112721': >? ? ? > status: CA_UNREACHABLE >? ? ? > ca-error: Server failed request, will retry: -504 (libcurl failed to >? ? ? > execute the HTTP POST transaction. Peer certificate cannot be >? ? ? > authenticated with known CA certificates). >? ? ? > stuck: yes >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > expires: 20111216112720 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > >? ? ? > Do we need to restart /etc/init.d/ipa service for all this to >? ???take effect? > >? ???No, and be very careful if your 389-ds cert is also expired. > >? ???This error really does mean that certmonger doesn't trust the SSL cert >? ???of your web server. Have you replaced your certs with something else? > >? ???Does a simple command like: ipa user-show admin work? > >? ???It may fail too due to the expired cert. You may have to turn time back >? ???on this machine, but that won't affect the untrusted CA. From what >? ???Nalin >? ???said, certmonger users /etc/ipa/ca.crt. This needs to match the CA that >? ???issued your Apache cert. > >? ???rob > >? ? ? > >? ? ? > Nidal. >? ? ? > >? ? ? > >? ? ? > --- On *Thu, 1/5/12, Rob Crittenden /? ???>/* wrote: >? ? ? > >? ? ? > >? ? ? > From: Rob Crittenden ? ???> >? ? ? > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ? ? > To: "nasir nasir" ? ???> >? ? ? > Cc: freeipa-users at redhat.com >? ???, fasilkaks at gmail.com >? ??? >? ? ? > Date: Thursday, January 5, 2012, 8:59 AM >? ? ? > >? ? ? > nasir nasir wrote: >? ? ? > > Thanks for the input Rob, >? ? ? > > >? ? ? > > Please find below the /var/log/httpd/error_log >? ? ? > > >? ? ? > > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: >? ? ? > 'Server-Cert' >? ? ? > > [Thu Jan 05 19:50:46 2012] [error] SSL Library Error: -8181 >? ? ? > Certificate >? ? ? > > has expired >? ? ? > > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: >? ? ? > 'Server-Cert' >? ? ? > > [Thu Jan 05 19:50:46 2012] [error] Unable to verify certificate >? ? ? > > 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the >? ? ? > server >? ? ? > > can start until the problem can be resolved. >? ? ? > > >? ? ? > > Do I need to add "NSSEnforceValidCerts off" in >? ? ? > > /etc/httpd/conf.d/nss.conf? Please advice. >? ? ? > > >? ? ? > >? ? ? > That explains why certmonger can't connect. Yes, for now add that >? ? ? > directive and restart httpd. Then try the start-tracking again >? ???and see >? ? ? > if it renews the cert. >? ? ? > >? ? ? > rob >? ? ? > >? ? ? > > Nidal. >? ? ? > > >? ? ? > > >? ? ? > > --- On *Thu, 1/5/12, Rob Crittenden /? ??? >? ? ? > ? ???>>/* wrote: >? ? ? > > >? ? ? > > >? ? ? > > From: Rob Crittenden ? ??? >? ? ? > ? ???>> >? ? ? > > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ? ? > > To: "nasir nasir" ? ??? >? ? ? > ? ???>> >? ? ? > > Cc: freeipa-users at redhat.com >? ??? >? ? ? > ? ???>, fasilkaks at gmail.com >? ??? >? ? ? > ? ???> >? ? ? > > Date: Thursday, January 5, 2012, 7:38 AM >? ? ? > > >? ? ? > > nasir nasir wrote: >? ? ? > > > Thanks for the reply Rob. >? ? ? > > > >? ? ? > > > Please find below the output of your guidelines. >? ? ? > > > >? ? ? > > > # ipa-getkeytab -s xxxxxxx.xxxxxxx.com -p >? ???host/xxxxxx.xxxxxx.com -k >? ? ? > > > /etc/krb5.keytab >? ? ? > > > (the command was successful; it din't show any errors in the >? ? ? > > krb5kdc.log >? ? ? > > > or audit.log) >? ? ? > > > >? ? ? > > > # kinit -kt /etc/krb5.keytab host/xxxxxx.xxxxxx.com >? ? ? > > > >? ? ? > > > krb5kdc.log >? ? ? > > > ----------------- >? ? ? > > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2431](info): AS_REQ (4 >? ? ? > > etypes >? ? ? > > > {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: >? ? ? > > > host/xxxxxx.xxxxxx.com at xxxxxx.COM >? ??? >? ? ? > ? ???> >? ? ? > > ? ??? >? ? ? > ? ???>> for >? ? ? > > krbtgt/xxxxxx.COM at xxxxxx.COM >? ? ? > ? ???> >? ? ? > ? ??? >? ? ? > ? ???>>, >? ? ? > > > Additional pre-authentication required >? ? ? > > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2427](info): AS_REQ (4 >? ? ? > > etypes >? ? ? > > > {18 17 16 23}) 192.168.1.10: ISSUE: authtime 1325766032, etypes >? ? ? > > {rep=18 >? ? ? > > > tkt=18 ses=18}, host/xxxxxx.xxxxxx.com at xxxxxx.COM >? ??? >? ? ? > ? ???> >? ? ? > > ? ??? >? ? ? > ? ???>> for >? ? ? > > > krbtgt/xxxxxx.COM at xxxxxx.COM >? ??? >? ? ? > ? ???> >? ? ? > ? ??? >? ? ? > ? ???>> >? ? ? > > > >? ? ? > > > # ipa-getcert list >? ? ? > > > Number of certificates and requests being tracked: 3. >? ? ? > > > Request ID '20110619112648': >? ? ? > > > status: CA_UNREACHABLE >? ? ? > > > ca-error: Server failed request, will retry: -504 (libcurl >? ? ? > failed to >? ? ? > > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > > stuck: yes >? ? ? > > > key pair storage: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate >? ???DB',pinfile='/etc/dirsrv/slapd-xxxxxx-COM//pwdfile.txt' >? ? ? > > > certificate: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB' >? ? ? > > > CA: IPA >? ? ? > > > issuer: CN=Certificate Authority,O=xxxxxx.COM >? ? ? > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM >? ? ? > > > expires: 20111216112647 >? ? ? > > > eku: id-kp-serverAuth >? ? ? > > > track: yes >? ? ? > > > auto-renew: yes >? ? ? > > > Request ID '20110619112705': >? ? ? > > > status: CA_UNREACHABLE >? ? ? > > > ca-error: Server failed request, will retry: -504 (libcurl >? ? ? > failed to >? ? ? > > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > > stuck: yes >? ? ? > > > key pair storage: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' >? ? ? > > > certificate: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB' >? ? ? > > > CA: IPA >? ? ? > > > issuer: CN=Certificate Authority,O=xxxxxx.COM >? ? ? > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM >? ? ? > > > expires: 20111216112704 >? ? ? > > > eku: id-kp-serverAuth >? ? ? > > > track: yes >? ? ? > > > auto-renew: yes >? ? ? > > > Request ID '20110619112721': >? ? ? > > > status: CA_UNREACHABLE >? ? ? > > > ca-error: Server failed request, will retry: -504 (libcurl >? ? ? > failed to >? ? ? > > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > > stuck: yes >? ? ? > > > key pair storage: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > > > certificate: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB' >? ? ? > > > CA: IPA >? ? ? > > > issuer: CN=Certificate Authority,O=xxxxxx.COM >? ? ? > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM >? ? ? > > > expires: 20111216112720 >? ? ? > > > eku: id-kp-serverAuth >? ? ? > > > track: yes >? ? ? > > > auto-renew: yes >? ? ? > > > >? ? ? > > > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert >? ? ? > > > Request "20110619112721" modified. >? ? ? > > > >? ? ? > > > # ipa-getcert list >? ? ? > > > Number of certificates and requests being tracked: 3. >? ? ? > > > Request ID '20110619112648': >? ? ? > > > status: CA_UNREACHABLE >? ? ? > > > ca-error: Server failed request, will retry: -504 (libcurl >? ? ? > failed to >? ? ? > > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > > stuck: yes >? ? ? > > > key pair storage: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate >? ? ? > DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' >? ? ? > > > certificate: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB' >? ? ? > > > CA: IPA >? ? ? > > > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > > > expires: 20111216112647 >? ? ? > > > eku: id-kp-serverAuth >? ? ? > > > track: yes >? ? ? > > > auto-renew: yes >? ? ? > > > Request ID '20110619112705': >? ? ? > > > status: CA_UNREACHABLE >? ? ? > > > ca-error: Server failed request, will retry: -504 (libcurl >? ? ? > failed to >? ? ? > > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > > stuck: yes >? ? ? > > > key pair storage: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' >? ? ? > > > certificate: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB' >? ? ? > > > CA: IPA >? ? ? > > > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > > > expires: 20111216112704 >? ? ? > > > eku: id-kp-serverAuth >? ? ? > > > track: yes >? ? ? > > > auto-renew: yes >? ? ? > > > Request ID '20110619112721': >? ? ? > > > status: SUBMITTING >? ? ? > > > stuck: no >? ? ? > > > key pair storage: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > > > certificate: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB' >? ? ? > > > CA: IPA >? ? ? > > > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > > > expires: 20111216112720 >? ? ? > > > eku: id-kp-serverAuth >? ? ? > > > track: yes >? ? ? > > > auto-renew: yes >? ? ? > > > >? ? ? > > > and after few minutes, the status 'SUBMITTING' will be changed as >? ? ? > > > 'CA_UNREACHABLE' >? ? ? > > > Do we need to restart the /etc/init.d/ipa service for this? I am >? ? ? > > working >? ? ? > > > remotely. >? ? ? > > >? ? ? > > It isn't logging enough information to know why it failed. Can >? ? ? > you look >? ? ? > > in the Apache error log to see why the request failed? >? ? ? > > >? ? ? > > My first thought was that there was a CA trust issue. I believe >? ???that >? ? ? > > certmonger uses the NSS database where the certificate is stored so >? ? ? > > since it is also doing this against Apache (which in theory trust >? ? ? > is ok >? ? ? > > for it to start at all) so I'm baffled. Hopefully the httpd logs >? ? ? > > will be >? ? ? > > enlightening. >? ? ? > > >? ? ? > > > >? ? ? > > > I need to upgrade my IPA version. Before going for this I need to >? ? ? > > have a >? ? ? > > > replica of the existing one. Is it okay to have the replica >? ? ? > while all >? ? ? > > > these issues exist? >? ? ? > > >? ? ? > > >? ? ? > > Yes, you should be able to create a replica, this shouldn't >? ? ? > affect it. >? ? ? > > >? ? ? > > rob >? ? ? > > >? ? ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbingram at gmail.com Fri Jan 6 21:45:07 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 6 Jan 2012 13:45:07 -0800 Subject: [Freeipa-users] PEM and DER certificate formats Message-ID: I noticed a message on here some time ago about changing IPA to output certificates in PEM format instead of DER. I see that in version 2.1.4, the UI does indeed output in PEM format. It appears as though the CLI still outputs in DER. Is this the case? I agree that PEM is certainly more typical, however, when working with the Java keystore, it asks for DER format. Should I still be able to get that from IPA or should I just use openssl to convert it? Steve From rcritten at redhat.com Fri Jan 6 21:55:54 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Jan 2012 16:55:54 -0500 Subject: [Freeipa-users] PEM and DER certificate formats In-Reply-To: References: Message-ID: <4F076DEA.5060702@redhat.com> Stephen Ingram wrote: > I noticed a message on here some time ago about changing IPA to output > certificates in PEM format instead of DER. I see that in version > 2.1.4, the UI does indeed output in PEM format. It appears as though > the CLI still outputs in DER. Is this the case? I agree that PEM is > certainly more typical, however, when working with the Java keystore, > it asks for DER format. Should I still be able to get that from IPA or > should I just use openssl to convert it? The cli outputs a base64 blob of data. If you took that and ran it through a base64 decoder you'd have DER format. You can't get DER directly right now. We could probably add an option to write a file in DER format if you wanted to open an RFE on our trac instance. rob From jdennis at redhat.com Fri Jan 6 21:58:53 2012 From: jdennis at redhat.com (John Dennis) Date: Fri, 06 Jan 2012 16:58:53 -0500 Subject: [Freeipa-users] PEM and DER certificate formats In-Reply-To: References: Message-ID: <4F076E9D.6000308@redhat.com> On 01/06/2012 04:45 PM, Stephen Ingram wrote: > I noticed a message on here some time ago about changing IPA to output > certificates in PEM format instead of DER. I see that in version > 2.1.4, the UI does indeed output in PEM format. It appears as though > the CLI still outputs in DER. Is this the case? I agree that PEM is > certainly more typical, however, when working with the Java keystore, > it asks for DER format. Should I still be able to get that from IPA or > should I just use openssl to convert it? It's much better to use PEM format, it's portable and accepted by all PKI software. The --out option of cert_show command line writes the cert in PEM format to a file. Thus both the web UI and the command line both now support PEM. Not sure about the Java keystore, I would expect it should accept either DER or PEM but if indeed it only support DER then it's trival to convert PEM to DER. There should be an existing utility to do it. If not it's as simple as taking the text between the PEM delimiters and base-64 decoding it. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sbingram at gmail.com Fri Jan 6 22:07:54 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 6 Jan 2012 14:07:54 -0800 Subject: [Freeipa-users] PEM and DER certificate formats In-Reply-To: <4F076E9D.6000308@redhat.com> References: <4F076E9D.6000308@redhat.com> Message-ID: Yes, the Java keystore appears only to accept DER, but I agree, it's the exception rather than the rule. And, yes, a simple command: openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER does the trick--I just confirmed that it works. As I had seen quite a bit of discussion regarding this on the list, I was more curious than anything as to whether IPA would output directly in DER. I was also coming more from the point of training people to perform this function. Steve On Fri, Jan 6, 2012 at 1:58 PM, John Dennis wrote: > On 01/06/2012 04:45 PM, Stephen Ingram wrote: >> >> I noticed a message on here some time ago about changing IPA to output >> certificates in PEM format instead of DER. I see that in version >> 2.1.4, the UI does indeed output in PEM format. It appears as though >> the CLI still outputs in DER. Is this the case? I agree that PEM is >> certainly more typical, however, when working with the Java keystore, >> it asks for DER format. Should I still be able to get that from IPA or >> should I just use openssl to convert it? > > > It's much better to use PEM format, it's portable and accepted by all PKI > software. > > The --out option of cert_show command line writes the cert in PEM format to > a file. > > Thus both the web UI and the command line both now support PEM. > > Not sure about the Java keystore, I would expect it should accept either DER > or PEM but if indeed it only support DER then it's trival to convert PEM to > DER. There should be an existing utility to do it. If not it's as simple as > taking the text between the PEM delimiters and base-64 decoding it. > > > -- > John Dennis > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ From jdennis at redhat.com Fri Jan 6 22:08:14 2012 From: jdennis at redhat.com (John Dennis) Date: Fri, 06 Jan 2012 17:08:14 -0500 Subject: [Freeipa-users] PEM and DER certificate formats In-Reply-To: <4F076DEA.5060702@redhat.com> References: <4F076DEA.5060702@redhat.com> Message-ID: <4F0770CE.1080107@redhat.com> On 01/06/2012 04:55 PM, Rob Crittenden wrote: > The cli outputs a base64 blob of data. Yes, it output a base64 blob to stdout. But that base64 blob is completely non-standard as an exchange format, it's just a textual encoding of the binary DER data. However the cli can write PEM format to a file using the --out option. PEM is standard and you should have no problems finding code that accepts PEM. I would strongly suggest you stick to standard PEM and use utilities to convert it to DER only if the software you're importing it is borked and can't accept PEM. > If you took that and ran it through a base64 decoder you'd have DER > format. You can't get DER directly right now. We could probably add > an option to write a file in DER format if you wanted to open an RFE > on our trac instance. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ranger at opennms.org Sat Jan 7 18:52:36 2012 From: ranger at opennms.org (Benjamin Reed) Date: Sat, 07 Jan 2012 13:52:36 -0500 Subject: [Freeipa-users] anonymous bind + ipa-install-client failure In-Reply-To: <4EF4F4E0.2060708@opennms.org> References: <4EF3EB90.9060003@opennms.org> <4EF3FB82.1010800@opennms.org> <1324659737.28622.202.camel@willson.li.ssimo.org> <4EF4F4E0.2060708@opennms.org> Message-ID: <4F089474.2070408@opennms.org> On 12/23/11 4:38 PM, Benjamin Reed wrote: > > On 12/23/11 12:02 PM, Simo Sorce wrote: > > One thing you can test is if the ca.crt exposed via http is the same > > that is stored on the server in /etc/ipa/ca.crt > > they are identical, I did find that the errors file is complaining about > this: > > [22/Dec/2011:21:31:15 -0600] attrcrypt - attrcrypt_unwrap_key: failed to > unwrap key for cipher AES > [22/Dec/2011:21:31:15 -0600] attrcrypt - attrcrypt_cipher_init: > symmetric key failed to unwrap with the private key; Cert might have > been renewed since the key is wrapped. To recover the encrypted > contents, keep the wrapped symmetric key value. > [22/Dec/2011:21:31:15 -0600] attrcrypt - attrcrypt_unwrap_key: failed to > unwrap key for cipher 3DES > [22/Dec/2011:21:31:15 -0600] attrcrypt - attrcrypt_cipher_init: > symmetric key failed to unwrap with the private key; Cert might have > been renewed since the key is wrapped. To recover the encrypted > contents, keep the wrapped symmetric key value. > [22/Dec/2011:21:31:16 -0600] attrcrypt - All prepared ciphers are not > available. Please disable attribute encryption. > > So the ultimate problem is that the LDAP and HTTP certs got replaced with a geotrust public cert, and the configuration client didn't like that. Now, I have a new problem. I didn't think anything has changed, but the server had a reboot and now I get this on startup, and the directory server is just plain dead: [root at connect slapd-OPENNMS-COM]# /etc/init.d/dirsrv start Starting dirsrv: OPENNMS-COM...[07/Jan/2012:12:35:34 -0600] - SSL alert: Security Initialization: Can't find certificate (connect.opennms.com) for family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - security library: bad database.) [07/Jan/2012:12:35:34 -0600] - SSL alert: Security Initialization: Unable to retrieve private key for cert connect.opennms.com of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - security library: bad database.) [07/Jan/2012:12:35:34 -0600] - SSL failure: None of the cipher are valid [07/Jan/2012:12:35:34 -0600] - ERROR: SSL Initialization phase 2 Failed. [FAILED] At this point, I will do whatever is the fastest way to get things back online. I do want to keep my user schema if possible, even if I have to make them reset their passwords. Is it possible to recover that if I just blow my config away and start fresh? -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ranger at opennms.org Sat Jan 7 20:06:15 2012 From: ranger at opennms.org (Benjamin Reed) Date: Sat, 07 Jan 2012 15:06:15 -0500 Subject: [Freeipa-users] anonymous bind + ipa-install-client failure In-Reply-To: <4F089474.2070408@opennms.org> References: <4EF3EB90.9060003@opennms.org> <4EF3FB82.1010800@opennms.org> <1324659737.28622.202.camel@willson.li.ssimo.org> <4EF4F4E0.2060708@opennms.org> <4F089474.2070408@opennms.org> Message-ID: <4F08A5B7.6050105@opennms.org> On 1/7/12 1:52 PM, Benjamin Reed wrote: > At this point, I will do whatever is the fastest way to get things back online. I do want to keep my user schema if possible, even if I have to make them reset their passwords. Is it possible to recover that if I just blow my config away and start fresh? I gave up, I ipa-server-install --uninstall'd. Then I reran the install: Applying LDAP updates Restarting IPA to initialize updates before performing deletes: [1/2]: stopping directory server [2/2]: starting directory server done configuring dirsrv. Restarting the directory server Restarting the KDC Restarting the web server Sample zone file for bind has been created in /tmp/sample.zone._TBKwb.db Configuration of client side components failed! ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master --unattended --domain opennms.com --server connect.opennms.com --realm OPENNMS.COM --hostname connect.opennms.com' returned non-zero exit status 1 I tried running the client install from another machine, and it agrees. What's going wrong here? How do I fix this? Did the uninstall fail to clean something out, so now the new install is corrupt in some way? -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Sat Jan 7 22:22:03 2012 From: simo at redhat.com (Simo Sorce) Date: Sat, 07 Jan 2012 17:22:03 -0500 Subject: [Freeipa-users] anonymous bind + ipa-install-client failure In-Reply-To: <4F08A5B7.6050105@opennms.org> References: <4EF3EB90.9060003@opennms.org> <4EF3FB82.1010800@opennms.org> <1324659737.28622.202.camel@willson.li.ssimo.org> <4EF4F4E0.2060708@opennms.org> <4F089474.2070408@opennms.org> <4F08A5B7.6050105@opennms.org> Message-ID: <1325974923.30661.181.camel@willson.li.ssimo.org> On Sat, 2012-01-07 at 15:06 -0500, Benjamin Reed wrote: > On 1/7/12 1:52 PM, Benjamin Reed wrote: > > At this point, I will do whatever is the fastest way to get things > back online. I do want to keep my user schema if possible, even if I > have to make them reset their passwords. Is it possible to recover > that if I just blow my config away and start fresh? > > I gave up, I ipa-server-install --uninstall'd. > > Then I reran the install: > > Applying LDAP updates > Restarting IPA to initialize updates before performing deletes: > [1/2]: stopping directory server > [2/2]: starting directory server > done configuring dirsrv. > Restarting the directory server > Restarting the KDC > Restarting the web server > Sample zone file for bind has been created > in /tmp/sample.zone._TBKwb.db > Configuration of client side components failed! > ipa-client-install returned: Command '/usr/sbin/ipa-client-install > --on-master --unattended --domain opennms.com --server > connect.opennms.com --realm OPENNMS.COM --hostname > connect.opennms.com' returned non-zero exit status 1 > > > I tried running the client install from another machine, and it > agrees. What's going wrong here? How do I fix this? Did the > uninstall fail to clean something out, so now the new install is > corrupt in some way? Please send me your new ipaserver-install.log file. Meanwhile can you check that dirsrv, krb5kdc and apache are runnig ? A failed install may have left them down. You can use 'service ipa status' and 'service ipa restart' to see if any component is failing to start. Simo. -- Simo Sorce * Red Hat, Inc * New York From ranger at opennms.org Sat Jan 7 23:03:06 2012 From: ranger at opennms.org (Benjamin Reed) Date: Sat, 07 Jan 2012 18:03:06 -0500 Subject: [Freeipa-users] anonymous bind + ipa-install-client failure In-Reply-To: <4F08A5B7.6050105@opennms.org> References: <4EF3EB90.9060003@opennms.org> <4EF3FB82.1010800@opennms.org> <1324659737.28622.202.camel@willson.li.ssimo.org> <4EF4F4E0.2060708@opennms.org> <4F089474.2070408@opennms.org> <4F08A5B7.6050105@opennms.org> Message-ID: <4F08CF2A.60806@opennms.org> On 1/7/12 3:06 PM, Benjamin Reed wrote: > Configuration of client side components failed! > ipa-client-install returned: Command '/usr/sbin/ipa-client-install > --on-master --unattended --domain opennms.com --server > connect.opennms.com --realm OPENNMS.COM --hostname > connect.opennms.com' returned non-zero exit status 1 It turns out the issue for this showed in the ipa-client-install.log -- I had set up my HTTP server to redirect to HTTPS automatically, and that was messing up the round-trip of the configuration: 2012-01-07 14:04:22,653 DEBUG args=/usr/bin/wget -O /tmp/tmptzxcFF/ca.crt -T 15 -t 2 http://connect.opennms.com/ipa/config/ca.crt 2012-01-07 14:04:22,653 DEBUG stdout= 2012-01-07 14:04:22,653 DEBUG stderr=--2012-01-07 14:04:22-- http://connect.opennms.com/ipa/config/ca.crt Resolving connect.opennms.com... 66.135.60.215 Connecting to connect.opennms.com|66.135.60.215|:80... connected. HTTP request sent, awaiting response... 302 Found Location: https://connect.opennms.com/ipa/config/ca.crt [following] --2012-01-07 14:04:22-- https://connect.opennms.com/ipa/config/ca.crt Connecting to connect.opennms.com|66.135.60.215|:443... connected. ERROR: cannot verify connect.opennms.com?s certificate, issued by ?/O=OPENNMS.COM/CN=Certificate Authority?: Self-signed certificate encountered. To connect to connect.opennms.com insecurely, use ?--no-check-certificate?. 2012-01-07 14:04:22,653 DEBUG Retrieving CA from connect.opennms.com failed. -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ From Ivan.Ferreira at personal.com.py Sun Jan 8 06:41:58 2012 From: Ivan.Ferreira at personal.com.py (Ivan Ferreira) Date: Sun, 8 Jan 2012 03:41:58 -0300 Subject: [Freeipa-users] Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute Message-ID: <1880421964A72B44804F0F42CD92008A2311BAB96B@ASUSIS-EXCHMBX1.personal.com.py> Hi everybody. I'm testing ipa-server 2.1.3. I'm trying to create a Certificate for vsftpd. I can successfully create the certificate with the following command: # ipa cert-request --add --principal=FTP/ftp.linux.com.py ftp.csr But I want to create certificates with subjectAltName DNS extensions, and it seems that is not possible through an openSSL CRS and dogtag. So I deleted the service entry, then I created again using: # ipa service-add FTP/ftp.linux.com.py Then, I try to create the certificate using the following command: # ipa-getcert request -k /etc/vsftpd/private/ftp.key -f /etc/vsftpd/certs/ftp.crt -N "cn=ftp.linux.com.py" -D "cn=le-303.linux.com.py" -D "cn=ftp" -D "cn=le-303" -K FTP/ftp.linux.com.py But I have the following error: Request ID '20120108062420': status: CA_REJECTED ca-error: Server denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry 'krbprincipalname=ftp/ftp.linux.com.py at linux.com.py,cn=services,cn=accounts,dc=linux,dc=com,dc=py'.). stuck: yes key pair storage: type=FILE,location='/etc/vsftpd/private/ftp.key' certificate: type=FILE,location='/etc/vsftpd/certs/ftp.crt' CA: IPA issuer: subject: expires: unknown track: yes auto-renew: yes It looks like there is a problem with an ACI, or admin principal is not having enough privileges. ?Anyone gime me some hints? Thanks in advance. ________________________________ AVISO LEGAL: Esta informaci?n es privada y confidencial y est? dirigida ?nicamente a su destinatario. Si usted no es el destinatario original de este mensaje y por este medio pudo acceder a dicha informaci?n por favor elimine el mensaje. La distribuci?n o copia de este mensaje est? estrictamente prohibida. Esta comunicaci?n es s?lo para prop?sitos de informaci?n y no debe ser considerada como propuesta, aceptaci?n ni como una declaraci?n de voluntad oficial de NUCLEO S.A. La transmisi?n de e-mails no garantiza que el correo electr?nico sea seguro o libre de error. Por consiguiente, no manifestamos que esta informaci?n sea completa o precisa. Toda informaci?n est? sujeta a alterarse sin previo aviso. This information is private and confidential and intended for the recipient only. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and shall not be regarded neither as a proposal, acceptance nor as a statement of will or official statement from NUCLEO S.A. . Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kollathodi at yahoo.com Sun Jan 8 08:30:07 2012 From: kollathodi at yahoo.com (nasir nasir) Date: Sun, 8 Jan 2012 00:30:07 -0800 (PST) Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <1325869936.25354.YahooMailClassic@web161301.mail.bf1.yahoo.com> Message-ID: <1326011407.28242.YahooMailClassic@web161302.mail.bf1.yahoo.com> Hi, Would the below error cause any issues during replica and upgrade? # ipa user-show adminipa: ERROR: cert validation failed for "CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.)ipa: ERROR: cert validation failed for "CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.)ipa: ERROR: cannot connect to 'any of the configured servers': https://xxxxxx.xxxxxx.com/ipa/xml, https://xxxxxx.xxxxxx.com/ipa/xml Nidal. --- On Fri, 1/6/12, nasir nasir wrote: From: nasir nasir Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: "Rob Crittenden" Cc: freeipa-users at redhat.com, fasilkaks at gmail.com Date: Friday, January 6, 2012, 9:12 AM Thanks for the input Rob, We have already did it with your previous input and everything got normal. But the ipa user-show admin command gave the following errors.# ipa user-show adminipa: ERROR: cert validation failed for "CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.)ipa: ERROR: cert validation failed for "CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.)ipa: ERROR: cannot connect to 'any of the configured servers': https://xxxxxx.xxxxxx.com/ipa/xml, https://xxxxxx.xxxxxx.com/ipa/xml Regardless of the above error, everything seems to be working fine.Now we need to have the replica of the server before going for an upgrade of IPA.? Thank you all for the wonderful support during our hard times.? Nidal. --- On Fri, 1/6/12, Rob Crittenden wrote: From: Rob Crittenden Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA To: "nasir nasir" Cc: freeipa-users at redhat.com, fasilkaks at gmail.com Date: Friday, January 6, 2012, 7:21 AM nasir nasir wrote: > Rob, > > # ipa user-show admin > ipa: ERROR: cert validation failed for > "CN=openipa.hugayet.com,O=HUGAYET.COM" ((SEC_ERROR_EXPIRED_CERTIFICATE) > Peer's Certificate has expired.) > ipa: ERROR: cert validation failed for > "CN=openipa.hugayet.com,O=HUGAYET.COM" ((SEC_ERROR_EXPIRED_CERTIFICATE) > Peer's Certificate has expired.) > ipa: ERROR: cannot connect to 'any of the configured servers': > https://openipa.hugayet.com/ipa/xml, https://openipa.hugayet.com/ipa/xml > >? >>>>From what Nalin said, certmonger users /etc/ipa/ca.crt. This needs > to match the CA that issued your Apache cert.>>>>>> > > How can we proceed further? I think you're going to need to set the system time back to when the certificate is valid to do the renewal. rob > > Nidal. > > > --- On *Thu, 1/5/12, Rob Crittenden //*wrote: > > >? ???From: Rob Crittenden >? ???Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ???To: "nasir nasir" >? ???Cc: freeipa-users at redhat.com, fasilkaks at gmail.com >? ???Date: Thursday, January 5, 2012, 2:21 PM > >? ???nasir nasir wrote: >? ? ? > Hi Rob, >? ? ? > >? ? ? > Added the directive "NSSEnforceValidCerts off" in >? ? ? > /etc/httpd/conf.d/nss.conf and restarted httpd. Please find the >? ? ? > /var/log/httpd/error_log >? ? ? > >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: >? ? ? > KeyError(-1215723696,) in ? ? ? > '/usr/lib/python2.6/threading.pyc'> ignored >? ? ? > [Fri Jan 06 01:06:29 2012] [notice] caught SIGTERM, shutting down >? ? ? > [Fri Jan 06 01:06:29 2012] [notice] suEXEC mechanism enabled >? ???(wrapper: >? ? ? > /usr/sbin/suexec) >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [notice] Digest: generating secret for >? ???digest >? ? ? > authentication ... >? ? ? > [Fri Jan 06 01:06:30 2012] [notice] Digest: done >? ? ? > [Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Compiled for >? ???Python/2.6.2. >? ? ? > [Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Runtime using >? ???Python/2.6.6. >? ? ? > [Fri Jan 06 01:06:30 2012] [notice] Apache/2.2.15 (Unix) DAV/2 >? ? ? > mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 >? ???Python/2.6.6 >? ? ? > configured -- resuming normal operations >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: >? ???'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 >? ???Certificate >? ? ? > has expired >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:30 2012] [error] Server certificate is expired: >? ? ? > 'Server-Cert' >? ? ? > [Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS START *** >? ? ? > [Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS START *** >? ? ? > >? ? ? > # ipa-getcert list >? ? ? > Number of certificates and requests being tracked: 3. >? ? ? > Request ID '20110619112648': >? ? ? > status: CA_UNREACHABLE >? ? ? > ca-error: Server failed request, will retry: -504 (libcurl failed to >? ? ? > execute the HTTP POST transaction. SSL connect error). >? ? ? > stuck: yes >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > expires: 20111216112647 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > Request ID '20110619112705': >? ? ? > status: CA_UNREACHABLE >? ? ? > ca-error: Server failed request, will retry: -504 (libcurl failed to >? ? ? > execute the HTTP POST transaction. SSL connect error). >? ? ? > stuck: yes >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > expires: 20111216112704 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > Request ID '20110619112721': >? ? ? > status: CA_UNREACHABLE >? ? ? > ca-error: Server failed request, will retry: -504 (libcurl failed to >? ? ? > execute the HTTP POST transaction. Peer certificate cannot be >? ? ? > authenticated with known CA certificates). >? ? ? > stuck: yes >? ? ? > key pair storage: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > certificate: >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > Certificate DB' >? ? ? > CA: IPA >? ? ? > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > expires: 20111216112720 >? ? ? > eku: id-kp-serverAuth >? ? ? > track: yes >? ? ? > auto-renew: yes >? ? ? > >? ? ? > Do we need to restart /etc/init.d/ipa service for all this to >? ???take effect? > >? ???No, and be very careful if your 389-ds cert is also expired. > >? ???This error really does mean that certmonger doesn't trust the SSL cert >? ???of your web server. Have you replaced your certs with something else? > >? ???Does a simple command like: ipa user-show admin work? > >? ???It may fail too due to the expired cert. You may have to turn time back >? ???on this machine, but that won't affect the untrusted CA. From what >? ???Nalin >? ???said, certmonger users /etc/ipa/ca.crt. This needs to match the CA that >? ???issued your Apache cert. > >? ???rob > >? ? ? > >? ? ? > Nidal. >? ? ? > >? ? ? > >? ? ? > --- On *Thu, 1/5/12, Rob Crittenden /? ???>/* wrote: >? ? ? > >? ? ? > >? ? ? > From: Rob Crittenden ? ???> >? ? ? > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ? ? > To: "nasir nasir" ? ???> >? ? ? > Cc: freeipa-users at redhat.com >? ???, fasilkaks at gmail.com >? ??? >? ? ? > Date: Thursday, January 5, 2012, 8:59 AM >? ? ? > >? ? ? > nasir nasir wrote: >? ? ? > > Thanks for the input Rob, >? ? ? > > >? ? ? > > Please find below the /var/log/httpd/error_log >? ? ? > > >? ? ? > > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: >? ? ? > 'Server-Cert' >? ? ? > > [Thu Jan 05 19:50:46 2012] [error] SSL Library Error: -8181 >? ? ? > Certificate >? ? ? > > has expired >? ? ? > > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: >? ? ? > 'Server-Cert' >? ? ? > > [Thu Jan 05 19:50:46 2012] [error] Unable to verify certificate >? ? ? > > 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the >? ? ? > server >? ? ? > > can start until the problem can be resolved. >? ? ? > > >? ? ? > > Do I need to add "NSSEnforceValidCerts off" in >? ? ? > > /etc/httpd/conf.d/nss.conf? Please advice. >? ? ? > > >? ? ? > >? ? ? > That explains why certmonger can't connect. Yes, for now add that >? ? ? > directive and restart httpd. Then try the start-tracking again >? ???and see >? ? ? > if it renews the cert. >? ? ? > >? ? ? > rob >? ? ? > >? ? ? > > Nidal. >? ? ? > > >? ? ? > > >? ? ? > > --- On *Thu, 1/5/12, Rob Crittenden /? ??? >? ? ? > ? ???>>/* wrote: >? ? ? > > >? ? ? > > >? ? ? > > From: Rob Crittenden ? ??? >? ? ? > ? ???>> >? ? ? > > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA >? ? ? > > To: "nasir nasir" ? ??? >? ? ? > ? ???>> >? ? ? > > Cc: freeipa-users at redhat.com >? ??? >? ? ? > ? ???>, fasilkaks at gmail.com >? ??? >? ? ? > ? ???> >? ? ? > > Date: Thursday, January 5, 2012, 7:38 AM >? ? ? > > >? ? ? > > nasir nasir wrote: >? ? ? > > > Thanks for the reply Rob. >? ? ? > > > >? ? ? > > > Please find below the output of your guidelines. >? ? ? > > > >? ? ? > > > # ipa-getkeytab -s xxxxxxx.xxxxxxx.com -p >? ???host/xxxxxx.xxxxxx.com -k >? ? ? > > > /etc/krb5.keytab >? ? ? > > > (the command was successful; it din't show any errors in the >? ? ? > > krb5kdc.log >? ? ? > > > or audit.log) >? ? ? > > > >? ? ? > > > # kinit -kt /etc/krb5.keytab host/xxxxxx.xxxxxx.com >? ? ? > > > >? ? ? > > > krb5kdc.log >? ? ? > > > ----------------- >? ? ? > > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2431](info): AS_REQ (4 >? ? ? > > etypes >? ? ? > > > {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: >? ? ? > > > host/xxxxxx.xxxxxx.com at xxxxxx.COM >? ??? >? ? ? > ? ???> >? ? ? > > ? ??? >? ? ? > ? ???>> for >? ? ? > > krbtgt/xxxxxx.COM at xxxxxx.COM >? ? ? > ? ???> >? ? ? > ? ??? >? ? ? > ? ???>>, >? ? ? > > > Additional pre-authentication required >? ? ? > > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2427](info): AS_REQ (4 >? ? ? > > etypes >? ? ? > > > {18 17 16 23}) 192.168.1.10: ISSUE: authtime 1325766032, etypes >? ? ? > > {rep=18 >? ? ? > > > tkt=18 ses=18}, host/xxxxxx.xxxxxx.com at xxxxxx.COM >? ??? >? ? ? > ? ???> >? ? ? > > ? ??? >? ? ? > ? ???>> for >? ? ? > > > krbtgt/xxxxxx.COM at xxxxxx.COM >? ??? >? ? ? > ? ???> >? ? ? > ? ??? >? ? ? > ? ???>> >? ? ? > > > >? ? ? > > > # ipa-getcert list >? ? ? > > > Number of certificates and requests being tracked: 3. >? ? ? > > > Request ID '20110619112648': >? ? ? > > > status: CA_UNREACHABLE >? ? ? > > > ca-error: Server failed request, will retry: -504 (libcurl >? ? ? > failed to >? ? ? > > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > > stuck: yes >? ? ? > > > key pair storage: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate >? ???DB',pinfile='/etc/dirsrv/slapd-xxxxxx-COM//pwdfile.txt' >? ? ? > > > certificate: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB' >? ? ? > > > CA: IPA >? ? ? > > > issuer: CN=Certificate Authority,O=xxxxxx.COM >? ? ? > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM >? ? ? > > > expires: 20111216112647 >? ? ? > > > eku: id-kp-serverAuth >? ? ? > > > track: yes >? ? ? > > > auto-renew: yes >? ? ? > > > Request ID '20110619112705': >? ? ? > > > status: CA_UNREACHABLE >? ? ? > > > ca-error: Server failed request, will retry: -504 (libcurl >? ? ? > failed to >? ? ? > > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > > stuck: yes >? ? ? > > > key pair storage: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' >? ? ? > > > certificate: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB' >? ? ? > > > CA: IPA >? ? ? > > > issuer: CN=Certificate Authority,O=xxxxxx.COM >? ? ? > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM >? ? ? > > > expires: 20111216112704 >? ? ? > > > eku: id-kp-serverAuth >? ? ? > > > track: yes >? ? ? > > > auto-renew: yes >? ? ? > > > Request ID '20110619112721': >? ? ? > > > status: CA_UNREACHABLE >? ? ? > > > ca-error: Server failed request, will retry: -504 (libcurl >? ? ? > failed to >? ? ? > > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > > stuck: yes >? ? ? > > > key pair storage: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > > > certificate: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB' >? ? ? > > > CA: IPA >? ? ? > > > issuer: CN=Certificate Authority,O=xxxxxx.COM >? ? ? > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM >? ? ? > > > expires: 20111216112720 >? ? ? > > > eku: id-kp-serverAuth >? ? ? > > > track: yes >? ? ? > > > auto-renew: yes >? ? ? > > > >? ? ? > > > # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert >? ? ? > > > Request "20110619112721" modified. >? ? ? > > > >? ? ? > > > # ipa-getcert list >? ? ? > > > Number of certificates and requests being tracked: 3. >? ? ? > > > Request ID '20110619112648': >? ? ? > > > status: CA_UNREACHABLE >? ? ? > > > ca-error: Server failed request, will retry: -504 (libcurl >? ? ? > failed to >? ? ? > > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > > stuck: yes >? ? ? > > > key pair storage: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate >? ? ? > DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' >? ? ? > > > certificate: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB' >? ? ? > > > CA: IPA >? ? ? > > > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > > > expires: 20111216112647 >? ? ? > > > eku: id-kp-serverAuth >? ? ? > > > track: yes >? ? ? > > > auto-renew: yes >? ? ? > > > Request ID '20110619112705': >? ? ? > > > status: CA_UNREACHABLE >? ? ? > > > ca-error: Server failed request, will retry: -504 (libcurl >? ? ? > failed to >? ? ? > > > execute the HTTP POST transaction. SSL connect error). >? ? ? > > > stuck: yes >? ? ? > > > key pair storage: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' >? ? ? > > > certificate: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB' >? ? ? > > > CA: IPA >? ? ? > > > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > > > expires: 20111216112704 >? ? ? > > > eku: id-kp-serverAuth >? ? ? > > > track: yes >? ? ? > > > auto-renew: yes >? ? ? > > > Request ID '20110619112721': >? ? ? > > > status: SUBMITTING >? ? ? > > > stuck: no >? ? ? > > > key pair storage: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? ? ? > > > certificate: >? ? ? > > > >? ? ? > > >? ? ? > >? ???type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >? ? ? > > > Certificate DB' >? ? ? > > > CA: IPA >? ? ? > > > issuer: CN=Certificate Authority,O=HUGAYET.COM >? ? ? > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM >? ? ? > > > expires: 20111216112720 >? ? ? > > > eku: id-kp-serverAuth >? ? ? > > > track: yes >? ? ? > > > auto-renew: yes >? ? ? > > > >? ? ? > > > and after few minutes, the status 'SUBMITTING' will be changed as >? ? ? > > > 'CA_UNREACHABLE' >? ? ? > > > Do we need to restart the /etc/init.d/ipa service for this? I am >? ? ? > > working >? ? ? > > > remotely. >? ? ? > > >? ? ? > > It isn't logging enough information to know why it failed. Can >? ? ? > you look >? ? ? > > in the Apache error log to see why the request failed? >? ? ? > > >? ? ? > > My first thought was that there was a CA trust issue. I believe >? ???that >? ? ? > > certmonger uses the NSS database where the certificate is stored so >? ? ? > > since it is also doing this against Apache (which in theory trust >? ? ? > is ok >? ? ? > > for it to start at all) so I'm baffled. Hopefully the httpd logs >? ? ? > > will be >? ? ? > > enlightening. >? ? ? > > >? ? ? > > > >? ? ? > > > I need to upgrade my IPA version. Before going for this I need to >? ? ? > > have a >? ? ? > > > replica of the existing one. Is it okay to have the replica >? ? ? > while all >? ? ? > > > these issues exist? >? ? ? > > >? ? ? > > >? ? ? > > Yes, you should be able to create a replica, this shouldn't >? ? ? > affect it. >? ? ? > > >? ? ? > > rob >? ? ? > > >? ? ? > > -----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: From rcritten at redhat.com Mon Jan 9 14:52:02 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Jan 2012 09:52:02 -0500 Subject: [Freeipa-users] Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute In-Reply-To: <1880421964A72B44804F0F42CD92008A2311BAB96B@ASUSIS-EXCHMBX1.personal.com.py> References: <1880421964A72B44804F0F42CD92008A2311BAB96B@ASUSIS-EXCHMBX1.personal.com.py> Message-ID: <4F0AFF12.6050600@redhat.com> Ivan Ferreira wrote: > Hi everybody. I?m testing ipa-server 2.1.3. I?m trying to create a > Certificate for vsftpd. > > I can successfully create the certificate with the following command: > > # ipa cert-request --add --principal=FTP/ftp.linux.com.py ftp.csr > > But I want to create certificates with subjectAltName DNS extensions, > and it seems that is not possible through an openSSL CRS and dogtag. > > So I deleted the service entry, then I created again using: > > # ipa service-add FTP/ftp.linux.com.py > > Then, I try to create the certificate using the following command: > > # ipa-getcert request -k /etc/vsftpd/private/ftp.key -f > /etc/vsftpd/certs/ftp.crt -N "cn=ftp.linux.com.py" -D > "cn=le-303.linux.com.py" -D "cn=ftp" -D "cn=le-303" -K FTP/ftp.linux.com.py > > But I have the following error: > > Request ID '20120108062420': > > status: CA_REJECTED > > ca-error: Server denied our request, giving up: 2100 (RPC failed at > server. Insufficient access: Insufficient 'write' privilege to the > 'userCertificate' attribute of entry > 'krbprincipalname=ftp/ftp.linux.com.py at linux.com.py,cn=services,cn=accounts,dc=linux,dc=com,dc=py'.). > > stuck: yes > > key pair storage: type=FILE,location='/etc/vsftpd/private/ftp.key' > > certificate: type=FILE,location='/etc/vsftpd/certs/ftp.crt' > > CA: IPA > > issuer: > > subject: > > expires: unknown > > track: yes > > auto-renew: yes > > It looks like there is a problem with an ACI, or admin principal is not > having enough privileges. > > ?Anyone gime me some hints? ipa-getcert executes using the host principal of the machine it is running on. If you really want this machine to do the request you can add it as a manager to the service: # ipa service-add-host --hosts= FTP/ftp.linux.com.py # ipa resubmit -i 20120108062420 If you don't want certmonger tracking this forever you can tell it to stop once the cert is generated with: # ipa-getcert stop-tracking -i 20120108062420 rob From rcritten at redhat.com Mon Jan 9 14:52:47 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Jan 2012 09:52:47 -0500 Subject: [Freeipa-users] Expired SSL certificate issue with IPA In-Reply-To: <1326011407.28242.YahooMailClassic@web161302.mail.bf1.yahoo.com> References: <1326011407.28242.YahooMailClassic@web161302.mail.bf1.yahoo.com> Message-ID: <4F0AFF3F.2050302@redhat.com> nasir nasir wrote: > Hi, > > Would the below error cause any issues during replica and upgrade? > > # ipa user-show admin > ipa: ERROR: cert validation failed for > "CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's > certificate issuer has been marked as not trusted by the user.) > ipa: ERROR: cert validation failed for > "CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's > certificate issuer has been marked as not trusted by the user.) > ipa: ERROR: cannot connect to 'any of the configured servers': > https://xxxxxx.xxxxxx.com/ipa/xml, https://xxxxxx.xxxxxx.com/ipa/xml I don't think so but the problem will exist until addressed. In other words upgrading and/or creating a replica won't change things for this server. rob > > Nidal. > > --- On *Fri, 1/6/12, nasir nasir //* wrote: > > > From: nasir nasir > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > To: "Rob Crittenden" > Cc: freeipa-users at redhat.com, fasilkaks at gmail.com > Date: Friday, January 6, 2012, 9:12 AM > > Thanks for the input Rob, > > We have already did it with your previous input and everything got > normal. > > But the ipa user-show admin command gave the following errors. > # ipa user-show admin > ipa: ERROR: cert validation failed for > "CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) > Peer's certificate issuer has been marked as not trusted by the user.) > ipa: ERROR: cert validation failed for > "CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) > Peer's certificate issuer has been marked as not trusted by the user.) > ipa: ERROR: cannot connect to 'any of the configured servers': > https://xxxxxx.xxxxxx.com/ipa/xml, https://xxxxxx.xxxxxx.com/ipa/xml > > Regardless of the above error, everything seems to be working fine. > Now we need to have the replica of the server before going for an > upgrade of IPA. > > Thank you all for the wonderful support during our hard times. > > Nidal. > > > --- On *Fri, 1/6/12, Rob Crittenden //* wrote: > > > From: Rob Crittenden > Subject: Re: [Freeipa-users] Expired SSL certificate issue with IPA > To: "nasir nasir" > Cc: freeipa-users at redhat.com, fasilkaks at gmail.com > Date: Friday, January 6, 2012, 7:21 AM > > nasir nasir wrote: > > Rob, > > > > # ipa user-show admin > > ipa: ERROR: cert validation failed for > > "CN=openipa.hugayet.com,O=HUGAYET.COM" > ((SEC_ERROR_EXPIRED_CERTIFICATE) > > Peer's Certificate has expired.) > > ipa: ERROR: cert validation failed for > > "CN=openipa.hugayet.com,O=HUGAYET.COM" > ((SEC_ERROR_EXPIRED_CERTIFICATE) > > Peer's Certificate has expired.) > > ipa: ERROR: cannot connect to 'any of the configured servers': > > https://openipa.hugayet.com/ipa/xml, > https://openipa.hugayet.com/ipa/xml > > > > >>>>From what Nalin said, certmonger users /etc/ipa/ca.crt. > This needs > > to match the CA that issued your Apache cert.>>>>>> > > > > How can we proceed further? > > I think you're going to need to set the system time back to when > the > certificate is valid to do the renewal. > > rob > > > > > Nidal. > > > > > > --- On *Thu, 1/5/12, Rob Crittenden > //*wrote: > > > > > > From: Rob Crittenden > > Subject: Re: [Freeipa-users] Expired SSL certificate issue > with IPA > > To: "nasir nasir" > > Cc: freeipa-users at redhat.com, fasilkaks at gmail.com > > Date: Thursday, January 5, 2012, 2:21 PM > > > > nasir nasir wrote: > > > Hi Rob, > > > > > > Added the directive "NSSEnforceValidCerts off" in > > > /etc/httpd/conf.d/nss.conf and restarted httpd. Please find the > > > /var/log/httpd/error_log > > > > > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > > KeyError(-1215723696,) in > > '/usr/lib/python2.6/threading.pyc'> ignored > > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > > KeyError(-1215723696,) in > > '/usr/lib/python2.6/threading.pyc'> ignored > > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > > KeyError(-1215723696,) in > > '/usr/lib/python2.6/threading.pyc'> ignored > > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > > KeyError(-1215723696,) in > > '/usr/lib/python2.6/threading.pyc'> ignored > > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > > KeyError(-1215723696,) in > > '/usr/lib/python2.6/threading.pyc'> ignored > > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > > KeyError(-1215723696,) in > > '/usr/lib/python2.6/threading.pyc'> ignored > > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > > KeyError(-1215723696,) in > > '/usr/lib/python2.6/threading.pyc'> ignored > > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > > KeyError(-1215723696,) in > > '/usr/lib/python2.6/threading.pyc'> ignored > > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > > KeyError(-1215723696,) in > > '/usr/lib/python2.6/threading.pyc'> ignored > > > [Fri Jan 06 01:06:29 2012] [error] Exception KeyError: > > > KeyError(-1215723696,) in > > '/usr/lib/python2.6/threading.pyc'> ignored > > > [Fri Jan 06 01:06:29 2012] [notice] caught SIGTERM, > shutting down > > > [Fri Jan 06 01:06:29 2012] [notice] suEXEC mechanism enabled > > (wrapper: > > > /usr/sbin/suexec) > > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > > Certificate > > > has expired > > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is > expired: > > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [notice] Digest: generating > secret for > > digest > > > authentication ... > > > [Fri Jan 06 01:06:30 2012] [notice] Digest: done > > > [Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Compiled for > > Python/2.6.2. > > > [Fri Jan 06 01:06:30 2012] [warn] mod_wsgi: Runtime using > > Python/2.6.6. > > > [Fri Jan 06 01:06:30 2012] [notice] Apache/2.2.15 (Unix) DAV/2 > > > mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 > > Python/2.6.6 > > > configured -- resuming normal operations > > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > > Certificate > > > has expired > > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is > expired: > > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > > Certificate > > > has expired > > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is > expired: > > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > > Certificate > > > has expired > > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is > expired: > > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > > Certificate > > > has expired > > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is > expired: > > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > > Certificate > > > has expired > > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > > Certificate > > > has expired > > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > > Certificate > > > has expired > > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is > expired: > > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is > expired: > > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] Certificate not verified: > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] SSL Library Error: -8181 > > Certificate > > > has expired > > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is > expired: > > > 'Server-Cert' > > > [Fri Jan 06 01:06:30 2012] [error] Server certificate is > expired: > > > 'Server-Cert' > > > [Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS > START *** > > > [Fri Jan 06 01:06:32 2012] [error] ipa: INFO: *** PROCESS > START *** > > > > > > # ipa-getcert list > > > Number of certificates and requests being tracked: 3. > > > Request ID '20110619112648': > > > status: CA_UNREACHABLE > > > ca-error: Server failed request, will retry: -504 (libcurl > failed to > > > execute the HTTP POST transaction. SSL connect error). > > > stuck: yes > > > key pair storage: > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > > > Certificate > DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' > > > certificate: > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > > > Certificate DB' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > > expires: 20111216112647 > > > eku: id-kp-serverAuth > > > track: yes > > > auto-renew: yes > > > Request ID '20110619112705': > > > status: CA_UNREACHABLE > > > ca-error: Server failed request, will retry: -504 (libcurl > failed to > > > execute the HTTP POST transaction. SSL connect error). > > > stuck: yes > > > key pair storage: > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > Certificate > DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > > > certificate: > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > Certificate DB' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > > expires: 20111216112704 > > > eku: id-kp-serverAuth > > > track: yes > > > auto-renew: yes > > > Request ID '20110619112721': > > > status: CA_UNREACHABLE > > > ca-error: Server failed request, will retry: -504 (libcurl > failed to > > > execute the HTTP POST transaction. Peer certificate cannot be > > > authenticated with known CA certificates). > > > stuck: yes > > > key pair storage: > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > certificate: > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > Certificate DB' > > > CA: IPA > > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > > expires: 20111216112720 > > > eku: id-kp-serverAuth > > > track: yes > > > auto-renew: yes > > > > > > Do we need to restart /etc/init.d/ipa service for all this to > > take effect? > > > > No, and be very careful if your 389-ds cert is also expired. > > > > This error really does mean that certmonger doesn't trust the > SSL cert > > of your web server. Have you replaced your certs with > something else? > > > > Does a simple command like: ipa user-show admin work? > > > > It may fail too due to the expired cert. You may have to turn > time back > > on this machine, but that won't affect the untrusted CA. From > what > > Nalin > > said, certmonger users /etc/ipa/ca.crt. This needs to match > the CA that > > issued your Apache cert. > > > > rob > > > > > > > > Nidal. > > > > > > > > > --- On *Thu, 1/5/12, Rob Crittenden / > >/* wrote: > > > > > > > > > From: Rob Crittenden > > > > > Subject: Re: [Freeipa-users] Expired SSL certificate issue > with IPA > > > To: "nasir nasir" > > > > > Cc: freeipa-users at redhat.com > > , fasilkaks at gmail.com > > > > > Date: Thursday, January 5, 2012, 8:59 AM > > > > > > nasir nasir wrote: > > > > Thanks for the input Rob, > > > > > > > > Please find below the /var/log/httpd/error_log > > > > > > > > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: > > > 'Server-Cert' > > > > [Thu Jan 05 19:50:46 2012] [error] SSL Library Error: -8181 > > > Certificate > > > > has expired > > > > [Thu Jan 05 19:50:46 2012] [error] Certificate not verified: > > > 'Server-Cert' > > > > [Thu Jan 05 19:50:46 2012] [error] Unable to verify > certificate > > > > 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf > so the > > > server > > > > can start until the problem can be resolved. > > > > > > > > Do I need to add "NSSEnforceValidCerts off" in > > > > /etc/httpd/conf.d/nss.conf? Please advice. > > > > > > > > > > That explains why certmonger can't connect. Yes, for now > add that > > > directive and restart httpd. Then try the start-tracking again > > and see > > > if it renews the cert. > > > > > > rob > > > > > > > Nidal. > > > > > > > > > > > > --- On *Thu, 1/5/12, Rob Crittenden / > > > > > >>/* wrote: > > > > > > > > > > > > From: Rob Crittenden > > > > > >> > > > > Subject: Re: [Freeipa-users] Expired SSL certificate > issue with IPA > > > > To: "nasir nasir" > > > > > >> > > > > Cc: freeipa-users at redhat.com > > > > > > >, fasilkaks at gmail.com > > > > > > > > > > > Date: Thursday, January 5, 2012, 7:38 AM > > > > > > > > nasir nasir wrote: > > > > > Thanks for the reply Rob. > > > > > > > > > > Please find below the output of your guidelines. > > > > > > > > > > # ipa-getkeytab -s xxxxxxx.xxxxxxx.com -p > > host/xxxxxx.xxxxxx.com -k > > > > > /etc/krb5.keytab > > > > > (the command was successful; it din't show any errors > in the > > > > krb5kdc.log > > > > > or audit.log) > > > > > > > > > > # kinit -kt /etc/krb5.keytab host/xxxxxx.xxxxxx.com > > > > > > > > > > krb5kdc.log > > > > > ----------------- > > > > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2431](info): > AS_REQ (4 > > > > etypes > > > > > {18 17 16 23}) 192.168.1.10: NEEDED_PREAUTH: > > > > > host/xxxxxx.xxxxxx.com at xxxxxx.COM > > > > > > > > > > > > > > > > >> for > > > > krbtgt/xxxxxx.COM at xxxxxx.COM > > > > > > > > > > > > > > >>, > > > > > Additional pre-authentication required > > > > > Jan 05 15:20:32 xxxxxx.xxxxxx.com krb5kdc[2427](info): > AS_REQ (4 > > > > etypes > > > > > {18 17 16 23}) 192.168.1.10: ISSUE: authtime > 1325766032, etypes > > > > {rep=18 > > > > > tkt=18 ses=18}, host/xxxxxx.xxxxxx.com at xxxxxx.COM > > > > > > > > > > > > > > > > >> for > > > > > krbtgt/xxxxxx.COM at xxxxxx.COM > > > > > > > > > > > > > > > >> > > > > > > > > > > # ipa-getcert list > > > > > Number of certificates and requests being tracked: 3. > > > > > Request ID '20110619112648': > > > > > status: CA_UNREACHABLE > > > > > ca-error: Server failed request, will retry: -504 (libcurl > > > failed to > > > > > execute the HTTP POST transaction. SSL connect error). > > > > > stuck: yes > > > > > key pair storage: > > > > > > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS > > > > > Certificate > > DB',pinfile='/etc/dirsrv/slapd-xxxxxx-COM//pwdfile.txt' > > > > > certificate: > > > > > > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-xxxxxx-COM',nickname='Server-Cert',token='NSS > > > > > Certificate DB' > > > > > CA: IPA > > > > > issuer: CN=Certificate Authority,O=xxxxxx.COM > > > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > > > > > expires: 20111216112647 > > > > > eku: id-kp-serverAuth > > > > > track: yes > > > > > auto-renew: yes > > > > > Request ID '20110619112705': > > > > > status: CA_UNREACHABLE > > > > > ca-error: Server failed request, will retry: -504 (libcurl > > > failed to > > > > > execute the HTTP POST transaction. SSL connect error). > > > > > stuck: yes > > > > > key pair storage: > > > > > > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > > > Certificate > DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > > > > > certificate: > > > > > > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > > > Certificate DB' > > > > > CA: IPA > > > > > issuer: CN=Certificate Authority,O=xxxxxx.COM > > > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > > > > > expires: 20111216112704 > > > > > eku: id-kp-serverAuth > > > > > track: yes > > > > > auto-renew: yes > > > > > Request ID '20110619112721': > > > > > status: CA_UNREACHABLE > > > > > ca-error: Server failed request, will retry: -504 (libcurl > > > failed to > > > > > execute the HTTP POST transaction. SSL connect error). > > > > > stuck: yes > > > > > key pair storage: > > > > > > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > > > certificate: > > > > > > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > > > Certificate DB' > > > > > CA: IPA > > > > > issuer: CN=Certificate Authority,O=xxxxxx.COM > > > > > subject: CN=xxxxxx.xxxxxx.com,O=xxxxxx.COM > > > > > expires: 20111216112720 > > > > > eku: id-kp-serverAuth > > > > > track: yes > > > > > auto-renew: yes > > > > > > > > > > # ipa-getcert start-tracking -d /etc/httpd/alias -n > Server-Cert > > > > > Request "20110619112721" modified. > > > > > > > > > > # ipa-getcert list > > > > > Number of certificates and requests being tracked: 3. > > > > > Request ID '20110619112648': > > > > > status: CA_UNREACHABLE > > > > > ca-error: Server failed request, will retry: -504 (libcurl > > > failed to > > > > > execute the HTTP POST transaction. SSL connect error). > > > > > stuck: yes > > > > > key pair storage: > > > > > > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > > > > > Certificate > > > DB',pinfile='/etc/dirsrv/slapd-HUGAYET-COM//pwdfile.txt' > > > > > certificate: > > > > > > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-HUGAYET-COM',nickname='Server-Cert',token='NSS > > > > > Certificate DB' > > > > > CA: IPA > > > > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > > > > expires: 20111216112647 > > > > > eku: id-kp-serverAuth > > > > > track: yes > > > > > auto-renew: yes > > > > > Request ID '20110619112705': > > > > > status: CA_UNREACHABLE > > > > > ca-error: Server failed request, will retry: -504 (libcurl > > > failed to > > > > > execute the HTTP POST transaction. SSL connect error). > > > > > stuck: yes > > > > > key pair storage: > > > > > > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > > > Certificate > DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > > > > > certificate: > > > > > > > > > > > > > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > > > > Certificate DB' > > > > > CA: IPA > > > > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > > > > expires: 20111216112704 > > > > > eku: id-kp-serverAuth > > > > > track: yes > > > > > auto-renew: yes > > > > > Request ID '20110619112721': > > > > > status: SUBMITTING > > > > > stuck: no > > > > > key pair storage: > > > > > > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > > > certificate: > > > > > > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > > > > Certificate DB' > > > > > CA: IPA > > > > > issuer: CN=Certificate Authority,O=HUGAYET.COM > > > > > subject: CN=openipa.hugayet.com,O=HUGAYET.COM > > > > > expires: 20111216112720 > > > > > eku: id-kp-serverAuth > > > > > track: yes > > > > > auto-renew: yes > > > > > > > > > > and after few minutes, the status 'SUBMITTING' will be > changed as > > > > > 'CA_UNREACHABLE' > > > > > Do we need to restart the /etc/init.d/ipa service for > this? I am > > > > working > > > > > remotely. > > > > > > > > It isn't logging enough information to know why it > failed. Can > > > you look > > > > in the Apache error log to see why the request failed? > > > > > > > > My first thought was that there was a CA trust issue. I > believe > > that > > > > certmonger uses the NSS database where the certificate is > stored so > > > > since it is also doing this against Apache (which in > theory trust > > > is ok > > > > for it to start at all) so I'm baffled. Hopefully the > httpd logs > > > > will be > > > > enlightening. > > > > > > > > > > > > > > I need to upgrade my IPA version. Before going for this > I need to > > > > have a > > > > > replica of the existing one. Is it okay to have the replica > > > while all > > > > > these issues exist? > > > > > > > > > > > > Yes, you should be able to create a replica, this shouldn't > > > affect it. > > > > > > > > rob > > > > > > > > > > > > -----Inline Attachment Follows----- > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From Ivan.Ferreira at personal.com.py Mon Jan 9 15:39:02 2012 From: Ivan.Ferreira at personal.com.py (Ivan Ferreira) Date: Mon, 9 Jan 2012 12:39:02 -0300 Subject: [Freeipa-users] Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute In-Reply-To: <4F0AFF12.6050600@redhat.com> References: <1880421964A72B44804F0F42CD92008A2311BAB96B@ASUSIS-EXCHMBX1.personal.com.py> <4F0AFF12.6050600@redhat.com> Message-ID: <1880421964A72B44804F0F42CD92008A2311BABB3E@ASUSIS-EXCHMBX1.personal.com.py> Thank you very much Rob for your time. The problem is solved. -----Mensaje original----- De: Rob Crittenden [mailto:rcritten at redhat.com] Enviado el: lunes, 09 de enero de 2012 11:52 a.m. Para: Ivan Ferreira CC: freeipa-users at redhat.com Asunto: Re: [Freeipa-users] Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute Ivan Ferreira wrote: > Hi everybody. I'm testing ipa-server 2.1.3. I'm trying to create a > Certificate for vsftpd. > > I can successfully create the certificate with the following command: > > # ipa cert-request --add --principal=FTP/ftp.linux.com.py ftp.csr > > But I want to create certificates with subjectAltName DNS extensions, > and it seems that is not possible through an openSSL CRS and dogtag. > > So I deleted the service entry, then I created again using: > > # ipa service-add FTP/ftp.linux.com.py > > Then, I try to create the certificate using the following command: > > # ipa-getcert request -k /etc/vsftpd/private/ftp.key -f > /etc/vsftpd/certs/ftp.crt -N "cn=ftp.linux.com.py" -D > "cn=le-303.linux.com.py" -D "cn=ftp" -D "cn=le-303" -K > FTP/ftp.linux.com.py > > But I have the following error: > > Request ID '20120108062420': > > status: CA_REJECTED > > ca-error: Server denied our request, giving up: 2100 (RPC failed at > server. Insufficient access: Insufficient 'write' privilege to the > 'userCertificate' attribute of entry > 'krbprincipalname=ftp/ftp.linux.com.py at linux.com.py,cn=services,cn=accounts,dc=linux,dc=com,dc=py'.). > > stuck: yes > > key pair storage: type=FILE,location='/etc/vsftpd/private/ftp.key' > > certificate: type=FILE,location='/etc/vsftpd/certs/ftp.crt' > > CA: IPA > > issuer: > > subject: > > expires: unknown > > track: yes > > auto-renew: yes > > It looks like there is a problem with an ACI, or admin principal is > not having enough privileges. > > ?Anyone gime me some hints? ipa-getcert executes using the host principal of the machine it is running on. If you really want this machine to do the request you can add it as a manager to the service: # ipa service-add-host --hosts= FTP/ftp.linux.com.py # ipa resubmit -i 20120108062420 If you don't want certmonger tracking this forever you can tell it to stop once the cert is generated with: # ipa-getcert stop-tracking -i 20120108062420 rob AVISO LEGAL: Esta informaci?n es privada y confidencial y est? dirigida ?nicamente a su destinatario. Si usted no es el destinatario original de este mensaje y por este medio pudo acceder a dicha informaci?n por favor elimine el mensaje. La distribuci?n o copia de este mensaje est? estrictamente prohibida. Esta comunicaci?n es s?lo para prop?sitos de informaci?n y no debe ser considerada como propuesta, aceptaci?n ni como una declaraci?n de voluntad oficial de NUCLEO S.A. La transmisi?n de e-mails no garantiza que el correo electr?nico sea seguro o libre de error. Por consiguiente, no manifestamos que esta informaci?n sea completa o precisa. Toda informaci?n est? sujeta a alterarse sin previo aviso. This information is private and confidential and intended for the recipient only. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and shall not be regarded neither as a proposal, acceptance nor as a statement of will or official statement from NUCLEO S.A. . Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. From erinn.looneytriggs at gmail.com Mon Jan 9 19:16:01 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 09 Jan 2012 10:16:01 -0900 Subject: [Freeipa-users] Initial login on RHEL 6 fails Message-ID: <4F0B3CF1.4040703@gmail.com> For a users very first, (as in never logged in before and will have to set new password), login attempt via GDM, the password change will fail and the user will be unable to log in. Now if the user has already set a password the login works fine. I haven't tested after the password expires but I suspect it will be the same as above. The salient errors (I believe) in the logs are the following: Jan 9 18:33:34 host.name pam: gdm-password[5056]: pam_unix(gdm-password:auth): authe ntication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=user_name Jan 9 18:33:34 host.name pam: gdm-password[5056]: pam_sss(gdm-password:auth): system info: [Password has expired] Jan 9 18:33:34 host.name pam: gdm-password[5056]: pam_sss(gdm-password:auth): authen tication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=user_name Jan 9 18:33:34 host.name pam: gdm-password[5056]: pam_sss(gdm-password:auth): receiv ed for user user_name: 12 (Authentication token is no longer valid; new one r equired) Jan 9 18:33:35 host.name pam: gdm-password[5056]: pam_sss(gdm-password:account): Use r info message: Password expired. Change your password now. Jan 9 18:33:35 host.name pam: gdm-password[5056]: pam_unix(gdm-password:chauthtok): user "user_name" does not exist in /etc/passwd Jan 9 18:33:51 host.name pam: gdm-password[5056]: pam_unix(gdm-password:chauthtok): user "user_name" does not exist in /etc/passwd Jan 9 18:33:52 host.name pam: gdm-password[5056]: pam_sss(gdm-password:chauthtok): system info: [Generic error (see e-text)] Jan 9 18:33:52 host.name pam: gdm-password[5056]: pam_sss(gdm-password:chauthtok): User info message: Password change failed. Server message: Failed to decrypt password Jan 9 18:33:52 host.name pam: gdm-password[5056]: pam_sss(gdm-password:chauthtok): Password change failed for user user_name: 20 (Authentication token manipulation error) The KDC logs, don't shed a huge amount of light: Jan 09 18:33:34 ipa.server krb5kdc[2379](info): AS_REQ (4 etypes {18 17 16 23}) 74.93.225.129: CLIENT KEY EXPIRED: user_name at REALM.COM for krbtgt/REALM.COM at REALM.COM, Password has expired Jan 09 18:33:34 ipa.server krb5kdc[2377](info): AS_REQ (4 etypes {18 17 16 23}) 74.93.225.129: NEEDED_PREAUTH: user_name at REALM.COM for kadmin/changepw@ REALM.COM, Additional pre-authentication required Jan 09 18:33:34 ipa.server krb5kdc[2375](info): AS_REQ (4 etypes {18 17 16 23}) 74.93.225.129: ISSUE: authtime 1326134014, etypes {rep=18 tkt=18 ses=18}, user_name at REALM.COM for kadmin/changepw at REALM.COM Jan 09 18:33:39 ipa.server krb5kdc[2375](info): AS_REQ (4 etypes {18 17 16 23}) 74.93.225.129: NEEDED_PREAUTH: user_name at REALM.COM for kadmin/changepw@ REALM.COM, Additional pre-authentication required Jan 09 18:33:39 ipa.server krb5kdc[2382](info): AS_REQ (4 etypes {18 17 16 23}) 74.93.225.129: ISSUE: authtime 1326134019, etypes {rep=18 tkt=18 ses=18}, user_name at REALM.COM for kadmin/changepw at REALM.COM Jan 09 18:33:51 ipa.server krb5kdc[2382](info): AS_REQ (4 etypes {18 17 16 23}) 74.93.225.129: NEEDED_PREAUTH: user_name at REALM.COM for kadmin/changepw@ REALM.COM, Additional pre-authentication required After doing some testing while writing this message it appears that kpasswd and even the sshd login fail as well in the same way. A copy of /etc/pam.d/system-auth for completeness: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=0 password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok remember=12 password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so session optional pam_motd.so motd=/etc/motd Let me know any thoughts on the matter, -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From g17jimmy at gmail.com Mon Jan 9 20:30:17 2012 From: g17jimmy at gmail.com (Jimmy) Date: Mon, 9 Jan 2012 15:30:17 -0500 Subject: [Freeipa-users] consulting? Message-ID: Just wondering if there was anyone listening on the list that might be available for little work integrating FreeIPA with Active Directory (preferrably in the south east US.) I hope this isn't against the list rules, I just thought one of you guys could help or point me in the right direction. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Jan 9 20:33:30 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 09 Jan 2012 15:33:30 -0500 Subject: [Freeipa-users] Initial login on RHEL 6 fails In-Reply-To: <4F0B3CF1.4040703@gmail.com> References: <4F0B3CF1.4040703@gmail.com> Message-ID: <4F0B4F1A.2090103@redhat.com> On 01/09/2012 02:16 PM, Erinn Looney-Triggs wrote: > For a users very first, (as in never logged in before and will have to > set new password), login attempt via GDM, the password change will fail > and the user will be unable to log in. > > Now if the user has already set a password the login works fine. I > haven't tested after the password expires but I suspect it will be the > same as above. > > The salient errors (I believe) in the logs are the following: > > Jan 9 18:33:34 host.name pam: gdm-password[5056]: > pam_unix(gdm-password:auth): authe > ntication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= > user=user_name > Jan 9 18:33:34 host.name pam: gdm-password[5056]: > pam_sss(gdm-password:auth): system > info: [Password has expired] > Jan 9 18:33:34 host.name pam: gdm-password[5056]: > pam_sss(gdm-password:auth): authen > tication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=user_name > Jan 9 18:33:34 host.name pam: gdm-password[5056]: > pam_sss(gdm-password:auth): receiv > ed for user user_name: 12 (Authentication token is no longer valid; new > one r > equired) > Jan 9 18:33:35 host.name pam: gdm-password[5056]: > pam_sss(gdm-password:account): Use > r info message: Password expired. Change your password now. > Jan 9 18:33:35 host.name pam: gdm-password[5056]: > pam_unix(gdm-password:chauthtok): user "user_name" does not exist in > /etc/passwd > Jan 9 18:33:51 host.name pam: gdm-password[5056]: > pam_unix(gdm-password:chauthtok): user "user_name" does not exist in > /etc/passwd > Jan 9 18:33:52 host.name pam: gdm-password[5056]: > pam_sss(gdm-password:chauthtok): system info: [Generic error (see e-text)] > Jan 9 18:33:52 host.name pam: gdm-password[5056]: > pam_sss(gdm-password:chauthtok): User info message: Password change > failed. Server message: Failed to decrypt password > Jan 9 18:33:52 host.name pam: gdm-password[5056]: > pam_sss(gdm-password:chauthtok): Password change failed for user > user_name: 20 (Authentication token manipulation error) > > The KDC logs, don't shed a huge amount of light: > Jan 09 18:33:34 ipa.server krb5kdc[2379](info): AS_REQ (4 etypes {18 17 16 > 23}) 74.93.225.129: CLIENT KEY EXPIRED: user_name at REALM.COM for > krbtgt/REALM.COM at REALM.COM, Password has expired > Jan 09 18:33:34 ipa.server krb5kdc[2377](info): AS_REQ (4 etypes {18 17 16 > 23}) 74.93.225.129: NEEDED_PREAUTH: user_name at REALM.COM for kadmin/changepw@ > REALM.COM, Additional pre-authentication required > Jan 09 18:33:34 ipa.server krb5kdc[2375](info): AS_REQ (4 etypes {18 17 16 > 23}) 74.93.225.129: ISSUE: authtime 1326134014, etypes {rep=18 tkt=18 > ses=18}, user_name at REALM.COM for kadmin/changepw at REALM.COM > Jan 09 18:33:39 ipa.server krb5kdc[2375](info): AS_REQ (4 etypes {18 17 16 > 23}) 74.93.225.129: NEEDED_PREAUTH: user_name at REALM.COM for kadmin/changepw@ > REALM.COM, Additional pre-authentication required > Jan 09 18:33:39 ipa.server krb5kdc[2382](info): AS_REQ (4 etypes {18 17 16 > 23}) 74.93.225.129: ISSUE: authtime 1326134019, etypes {rep=18 tkt=18 > ses=18}, user_name at REALM.COM for kadmin/changepw at REALM.COM > Jan 09 18:33:51 ipa.server krb5kdc[2382](info): AS_REQ (4 etypes {18 17 16 > 23}) 74.93.225.129: NEEDED_PREAUTH: user_name at REALM.COM for kadmin/changepw@ > REALM.COM, Additional pre-authentication required > > After doing some testing while writing this message it appears that > kpasswd and even the sshd login fail as well in the same way. > > A copy of /etc/pam.d/system-auth for completeness: > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > auth required pam_env.so > auth sufficient pam_fprintd.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth sufficient pam_sss.so use_first_pass > auth required pam_deny.so > > account required pam_unix.so > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > > password requisite pam_cracklib.so try_first_pass retry=3 type= > minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=0 > password sufficient pam_unix.so sha512 shadow nullok > try_first_pass use_authtok remember=12 > password sufficient pam_sss.so use_authtok > password required pam_deny.so > > session optional pam_keyinit.so revoke > session required pam_limits.so > session optional pam_oddjob_mkhomedir.so > session [success=1 default=ignore] pam_succeed_if.so service in > crond quiet use_uid > session required pam_unix.so > session optional pam_sss.so > session optional pam_motd.so motd=/etc/motd > > Let me know any thoughts on the matter, > > -Erinn > > Did you create a user and added a password for him? ipa user-add ... ipa passwd ... Can you please provide the output of the: ipa user-show --raw --all before and after you try? > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From erinn.looneytriggs at gmail.com Mon Jan 9 21:28:55 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 09 Jan 2012 12:28:55 -0900 Subject: [Freeipa-users] Initial login on RHEL 6 fails In-Reply-To: <4F0B4F1A.2090103@redhat.com> References: <4F0B3CF1.4040703@gmail.com> <4F0B4F1A.2090103@redhat.com> Message-ID: <4F0B5C17.9030102@gmail.com> On 01/09/2012 11:33 AM, Dmitri Pal wrote: > On 01/09/2012 02:16 PM, Erinn Looney-Triggs wrote: >> For a users very first, (as in never logged in before and will have to >> set new password), login attempt via GDM, the password change will fail >> and the user will be unable to log in. >> >> Now if the user has already set a password the login works fine. I >> haven't tested after the password expires but I suspect it will be the >> same as above. >> >> The salient errors (I believe) in the logs are the following: >> >> Jan 9 18:33:34 host.name pam: gdm-password[5056]: >> pam_unix(gdm-password:auth): authe >> ntication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= >> user=user_name >> Jan 9 18:33:34 host.name pam: gdm-password[5056]: >> pam_sss(gdm-password:auth): system >> info: [Password has expired] >> Jan 9 18:33:34 host.name pam: gdm-password[5056]: >> pam_sss(gdm-password:auth): authen >> tication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=user_name >> Jan 9 18:33:34 host.name pam: gdm-password[5056]: >> pam_sss(gdm-password:auth): receiv >> ed for user user_name: 12 (Authentication token is no longer valid; new >> one r >> equired) >> Jan 9 18:33:35 host.name pam: gdm-password[5056]: >> pam_sss(gdm-password:account): Use >> r info message: Password expired. Change your password now. >> Jan 9 18:33:35 host.name pam: gdm-password[5056]: >> pam_unix(gdm-password:chauthtok): user "user_name" does not exist in >> /etc/passwd >> Jan 9 18:33:51 host.name pam: gdm-password[5056]: >> pam_unix(gdm-password:chauthtok): user "user_name" does not exist in >> /etc/passwd >> Jan 9 18:33:52 host.name pam: gdm-password[5056]: >> pam_sss(gdm-password:chauthtok): system info: [Generic error (see e-text)] >> Jan 9 18:33:52 host.name pam: gdm-password[5056]: >> pam_sss(gdm-password:chauthtok): User info message: Password change >> failed. Server message: Failed to decrypt password >> Jan 9 18:33:52 host.name pam: gdm-password[5056]: >> pam_sss(gdm-password:chauthtok): Password change failed for user >> user_name: 20 (Authentication token manipulation error) >> >> The KDC logs, don't shed a huge amount of light: >> Jan 09 18:33:34 ipa.server krb5kdc[2379](info): AS_REQ (4 etypes {18 17 16 >> 23}) 74.93.225.129: CLIENT KEY EXPIRED: user_name at REALM.COM for >> krbtgt/REALM.COM at REALM.COM , Password has expired >> Jan 09 18:33:34 ipa.server krb5kdc[2377](info): AS_REQ (4 etypes {18 17 16 >> 23}) 74.93.225.129: NEEDED_PREAUTH: user_name at REALM.COM for kadmin/changepw@ >> REALM.COM, Additional pre-authentication required >> Jan 09 18:33:34 ipa.server krb5kdc[2375](info): AS_REQ (4 etypes {18 17 16 >> 23}) 74.93.225.129: ISSUE: authtime 1326134014, etypes {rep=18 tkt=18 >> ses=18}, user_name at REALM.COM for kadmin/changepw at REALM.COM >> Jan 09 18:33:39 ipa.server krb5kdc[2375](info): AS_REQ (4 etypes {18 17 16 >> 23}) 74.93.225.129: NEEDED_PREAUTH: user_name at REALM.COM for kadmin/changepw@ >> REALM.COM, Additional pre-authentication required >> Jan 09 18:33:39 ipa.server krb5kdc[2382](info): AS_REQ (4 etypes {18 17 16 >> 23}) 74.93.225.129: ISSUE: authtime 1326134019, etypes {rep=18 tkt=18 >> ses=18}, user_name at REALM.COM for kadmin/changepw at REALM.COM >> Jan 09 18:33:51 ipa.server krb5kdc[2382](info): AS_REQ (4 etypes {18 17 16 >> 23}) 74.93.225.129: NEEDED_PREAUTH: user_name at REALM.COM for kadmin/changepw@ >> REALM.COM, Additional pre-authentication required >> >> After doing some testing while writing this message it appears that >> kpasswd and even the sshd login fail as well in the same way. >> >> A copy of /etc/pam.d/system-auth for completeness: >> #%PAM-1.0 >> # This file is auto-generated. >> # User changes will be destroyed the next time authconfig is run. >> auth required pam_env.so >> auth sufficient pam_fprintd.so >> auth sufficient pam_unix.so nullok try_first_pass >> auth requisite pam_succeed_if.so uid >= 500 quiet >> auth sufficient pam_sss.so use_first_pass >> auth required pam_deny.so >> >> account required pam_unix.so >> account sufficient pam_localuser.so >> account sufficient pam_succeed_if.so uid < 500 quiet >> account [default=bad success=ok user_unknown=ignore] pam_sss.so >> account required pam_permit.so >> >> password requisite pam_cracklib.so try_first_pass retry=3 type= >> minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=0 >> password sufficient pam_unix.so sha512 shadow nullok >> try_first_pass use_authtok remember=12 >> password sufficient pam_sss.so use_authtok >> password required pam_deny.so >> >> session optional pam_keyinit.so revoke >> session required pam_limits.so >> session optional pam_oddjob_mkhomedir.so >> session [success=1 default=ignore] pam_succeed_if.so service in >> crond quiet use_uid >> session required pam_unix.so >> session optional pam_sss.so >> session optional pam_motd.so motd=/etc/motd >> >> Let me know any thoughts on the matter, >> >> -Erinn >> >> > > Did you create a user and added a password for him? > ipa user-add ... > ipa passwd ... > > Can you please provide the output of the: > > ipa user-show --raw --all > > before and after you try? > > >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users I didn't do it via the CLI, but rather the webui. Other than that yes. For this run I did it via the CLI:: erinn at ipa ~ $ ipa user-add dev-test First name: Dev Last name: Test --------------------- Added user "dev-test" --------------------- User login: dev-test First name: Dev Last name: Test Full name: Dev Test Display name: Dev Test Initials: DT Home directory: /home/dev-test GECOS field: Dev Test Login shell: /bin/bash Kerberos principal: dev-test at example.COM UID: 1607600013 GID: 1607600013 Keytab: False Password: False erinn at ipa ~ $ ipa passwd dev-test New Password: Enter New Password again to verify: ------------------------------------------ Changed password for "dev-test at example.COM" ------------------------------------------ erinn at ipa ~ $ ipa user-show dev-test --raw --all dn: uid=dev-test,cn=users,cn=accounts,dc=example,dc=com uid: dev-test givenname: Dev sn: Test cn: Dev Test displayname: Dev Test initials: DT homedirectory: /home/dev-test gecos: Dev Test loginshell: /bin/bash krbprincipalname: dev-test at example.COM uidnumber: 1607600013 gidnumber: 1607600013 nsaccountlock: False has_keytab: True has_password: True ipauniqueid: 190c6a96-3b07-11e1-8f2b-f04da2090ae0 krbextradata: AAgBAA== krbextradata: AAIeWQtPcm9vdC9hZG1pbkBBQkFRSVMuQ09NAA== krblastpwdchange: 20120109211614Z krbloginfailedcount: 0 krbpasswordexpiration: 20120109211614Z krbpwdpolicyreference: cn=global_policy,cn=example.COM,cn=kerberos,dc=example,dc=com memberof: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com mepmanagedentry: cn=dev-test,cn=groups,cn=accounts,dc=example,dc=com objectclass: top objectclass: person objectclass: organizationalperson objectclass: inetorgperson objectclass: inetuser objectclass: posixaccount objectclass: krbprincipalaux objectclass: krbticketpolicyaux objectclass: ipaobject objectclass: mepOriginEntry After the attempt: dn: uid=dev-test,cn=users,cn=accounts,dc=example,dc=com uid: dev-test givenname: Dev sn: Test cn: Dev Test displayname: Dev Test initials: DT homedirectory: /home/dev-test gecos: Dev Test loginshell: /bin/bash krbprincipalname: dev-test at example.COM uidnumber: 1607600013 gidnumber: 1607600013 nsaccountlock: False has_keytab: True has_password: True ipauniqueid: 190c6a96-3b07-11e1-8f2b-f04da2090ae0 krbextradata: AAIeWQtPcm9vdC9hZG1pbkBBQkFRSVMuQ09NAA== krbextradata: AAgBAA== krblastpwdchange: 20120109211614Z krblastsuccessfulauth: 20120109212104Z krbloginfailedcount: 0 krbpasswordexpiration: 20120109211614Z krbpwdpolicyreference: cn=global_policy,cn=example.COM,cn=kerberos,dc=example,dc=com memberof: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com memberof: cn=desktop,cn=groups,cn=accounts,dc=example,dc=com memberofindirect: ipauniqueid=a212d7e0-3250-11e1-8dcb-f04da2090ae0,cn=hbac,dc=example,dc=com mepmanagedentry: cn=dev-test,cn=groups,cn=accounts,dc=example,dc=com objectclass: top objectclass: person objectclass: organizationalperson objectclass: inetorgperson objectclass: inetuser objectclass: posixaccount objectclass: krbprincipalaux objectclass: krbticketpolicyaux objectclass: ipaobject objectclass: mepOriginEntry A couple of additional notes that may be important. The system to which I am attempting to authenticate lives in private IP space whereas the IPA server is on a public IP. Second HBAC is in effect on the host so the user must be a member of the desktop group in order to authenticate. These may not have any bearing, or they may who knows. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From sylvainangers at gmail.com Mon Jan 9 21:59:02 2012 From: sylvainangers at gmail.com (Sylvain Angers) Date: Mon, 9 Jan 2012 16:59:02 -0500 Subject: [Freeipa-users] migration plan from local accounts In-Reply-To: <1325811051.30661.165.camel@willson.li.ssimo.org> References: <4F06241E.9040200@redhat.com> <1325811051.30661.165.camel@willson.li.ssimo.org> Message-ID: >Let me know if there is anything unclear about AIX clients in the documentation on freeipa.org. May I ask why there is a krb5 server as a requirement on a client? Thanks Le 5 janv. 2012 19:50, "Simo Sorce" a ?crit : > > On Thu, 2012-01-05 at 18:27 -0500, Sylvain Angers wrote: > > Hi again, > > > > > > by moving away from local account, to freeipa do we affect any of > > these numbers?: > > > > > > -group name length limits > > -group membership limits > > > > > > or they remain the same / as the under limit of the local os? > > On linux, I believe there will still be a limitation of 16 id per > > group, right? > > Linux has a "limitation" of 65K groups per user, and this has been true > for many years now. > > If you use NFS with sys auth instead of krb5 auth then you have a > lim > On Thu, 2012-01-05 at 18:27 -0500, Sylvain Angers wrote: > > Hi again, > > > > > > by moving away from local account, to freeipa do we affect any of > > these numbers?: > > > > > > -group name length limits > > -group membership limits > > > > > > or they remain the same / as the under limit of the local os? > > On linux, I believe there will still be a limitation of 16 id per > > group, right? > > Linux has a "limitation" of 65K groups per user, and this has been true > for many years now. > > If you use NFS with sys auth instead of krb5 auth then you have a > limitation of 16 groups per user, but this is a protocol limitation > valid for all OSs, it is not a limitation of Linux. And using krb5 auth > there is no such limitation. > > > > If anyone has some past experience with AIX, feel free to share with > > me > > We did some qualification/documentation testing on AIX a while back. All > I can say is that AIX can work agains FreeIPA just fine, but I am in no > way an AIX expert and the docs we have on freeipa.org are all I can tell > you to use as I already forgot all the details we dicovered at the time > we tested AIX :) > > > I am really interested to ear about it > > Let me know if there is anything unclear about AIX clients in the > documentation on freeipa.org. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Jan 9 22:31:52 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 09 Jan 2012 17:31:52 -0500 Subject: [Freeipa-users] Initial login on RHEL 6 fails In-Reply-To: <4F0B5C17.9030102@gmail.com> References: <4F0B3CF1.4040703@gmail.com> <4F0B4F1A.2090103@redhat.com> <4F0B5C17.9030102@gmail.com> Message-ID: <1326148312.30661.260.camel@willson.li.ssimo.org> On Mon, 2012-01-09 at 12:28 -0900, Erinn Looney-Triggs wrote: > [snip] Looks like the expiration is not updated, I suspect the password change actually failed. > A couple of additional notes that may be important. The system to > which > I am attempting to authenticate lives in private IP space whereas the > IPA server is on a public IP. Does it mean the client system is NATed wrt IPA ? I think that could make kpasswd fail. I need to check if this has been addressed in MIT libraries but IIRC it is a known limitation so far. The kpasswd binary I think specifies the IP address in mk_priv and fails verification from behind a NAT. > Second HBAC is in effect on the host so > the user must be a member of the desktop group in order to > authenticate. HBAC is not involved in any way with password changes, so I am confident you can exclude any correlation. > These may not have any bearing, or they may who knows. Yes the NAT part may be your issue. Simo. -- Simo Sorce * Red Hat, Inc * New York From erinn.looneytriggs at gmail.com Mon Jan 9 22:42:52 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 09 Jan 2012 13:42:52 -0900 Subject: [Freeipa-users] Initial login on RHEL 6 fails In-Reply-To: <1326148312.30661.260.camel@willson.li.ssimo.org> References: <4F0B3CF1.4040703@gmail.com> <4F0B4F1A.2090103@redhat.com> <4F0B5C17.9030102@gmail.com> <1326148312.30661.260.camel@willson.li.ssimo.org> Message-ID: <4F0B6D6C.2090502@gmail.com> On 01/09/2012 01:31 PM, Simo Sorce wrote: > On Mon, 2012-01-09 at 12:28 -0900, Erinn Looney-Triggs wrote: >> > [snip] > > > Looks like the expiration is not updated, I suspect the password change > actually failed. > >> A couple of additional notes that may be important. The system to >> which >> I am attempting to authenticate lives in private IP space whereas the >> IPA server is on a public IP. > > Does it mean the client system is NATed wrt IPA ? That is correct. > > I think that could make kpasswd fail. I need to check if this has been > addressed in MIT libraries but IIRC it is a known limitation so far. > The kpasswd binary I think specifies the IP address in mk_priv and fails > verification from behind a NAT. > >> Second HBAC is in effect on the host so >> the user must be a member of the desktop group in order to >> authenticate. > > HBAC is not involved in any way with password changes, so I am confident > you can exclude any correlation. > >> These may not have any bearing, or they may who knows. > > Yes the NAT part may be your issue. Yeah my kerb foo is a little rusty but the whole NAT/kerb thing causing issues does ring a bell with me too. I will continue to research. Thanks for the info, -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From dpal at redhat.com Mon Jan 9 22:50:14 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 09 Jan 2012 17:50:14 -0500 Subject: [Freeipa-users] migration plan from local accounts In-Reply-To: References: <4F06241E.9040200@redhat.com> <1325811051.30661.165.camel@willson.li.ssimo.org> Message-ID: <4F0B6F26.3020407@redhat.com> On 01/09/2012 04:59 PM, Sylvain Angers wrote: > > >Let me know if there is anything unclear about AIX clients in > the documentation on freeipa.org . > > May I ask why there is a krb5 server as a requirement on a client? > > Thanks > > Server is not a requirement on the client. And kerberos client is optional too. It is not a requirement but rather recommended for the best security and SSO purposes this is why we recommend and use by default configuration. But you can configure client to use LDAP only for authentication and identity lookups. It would work too. > Le 5 janv. 2012 19:50, "Simo Sorce" > a ?crit : > > > > On Thu, 2012-01-05 at 18:27 -0500, Sylvain Angers wrote: > > > Hi again, > > > > > > > > > by moving away from local account, to freeipa do we affect any of > > > these numbers?: > > > > > > > > > -group name length limits > > > -group membership limits > > > > > > > > > or they remain the same / as the under limit of the local os? > > > On linux, I believe there will still be a limitation of 16 id per > > > group, right? > > > > Linux has a "limitation" of 65K groups per user, and this has been true > > for many years now. > > > > If you use NFS with sys auth instead of krb5 auth then you have a > > lim > > On Thu, 2012-01-05 at 18:27 -0500, Sylvain Angers wrote: > > Hi again, > > > > > > by moving away from local account, to freeipa do we affect any of > > these numbers?: > > > > > > -group name length limits > > -group membership limits > > > > > > or they remain the same / as the under limit of the local os? > > On linux, I believe there will still be a limitation of 16 id per > > group, right? > > Linux has a "limitation" of 65K groups per user, and this has been > true > for many years now. > > If you use NFS with sys auth instead of krb5 auth then you have a > limitation of 16 groups per user, but this is a protocol limitation > valid for all OSs, it is not a limitation of Linux. And using krb5 > auth > there is no such limitation. > > > > If anyone has some past experience with AIX, feel free to share with > > me > > We did some qualification/documentation testing on AIX a while > back. All > I can say is that AIX can work agains FreeIPA just fine, but I am > in no > way an AIX expert and the docs we have on freeipa.org > are all I can tell > you to use as I already forgot all the details we dicovered at the > time > we tested AIX :) > > > I am really interested to ear about it > > Let me know if there is anything unclear about AIX clients in the > documentation on freeipa.org . > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jzeleny at redhat.com Tue Jan 10 08:03:18 2012 From: jzeleny at redhat.com (Jan =?iso-8859-1?q?Zelen=FD?=) Date: Tue, 10 Jan 2012 09:03:18 +0100 Subject: [Freeipa-users] consulting? In-Reply-To: References: Message-ID: <201201100903.22597.jzeleny@redhat.com> > Just wondering if there was anyone listening on the list that might be > available for little work integrating FreeIPA with Active Directory > (preferrably in the south east US.) I hope this isn't against the list > rules, I just thought one of you guys could help or point me in the right > direction. If you want some help, it is certainly not against list rules ;-) But in that case, it would be much better if you asked what exactly do you need. I'm not an AD expert, but a couple tips: If you are looking for cross-domain (cross-realm) trust, then you might be a bit disappointed, it is still in development, so it probably won't be 100% functional at this moment. If you are looking for something else, could you be a little more specific what it is? I also recommend starting with reading some doc: http://freeipa.org/page/DocumentationPortal Thanks Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From packages at amiga-hardware.com Tue Jan 10 14:46:31 2012 From: packages at amiga-hardware.com (Ian Chapman) Date: Tue, 10 Jan 2012 22:46:31 +0800 Subject: [Freeipa-users] Solaris 11 client Message-ID: <4F0C4F47.60300@amiga-hardware.com> Hi, Has anybody successfully setup up a Solaris 11 client (SunOS solaris 5.11 11.0 i86pc i386 i86pc Solaris) with FreeIPA? I have FreeIPA 2.4.1 running on Fedora 16. I've successfully configured Fedora, Ubuntu, Mint and FreeBSD clients but for some reason Solaris 11 isn't working. The Solaris 11 box correctly 'sees' user details for example: --- root at solaris:~# id exampleuser uid=2001(exampleuser) gid=2001(exampleuser) groups=2001(exampleuser),199000001(ipausers) root at solaris:~# finger exampleuser Login name: exampleuser In real life: Example User Directory: /home/exampleuser Shell: /bin/bash Never logged in. No unread mail No Plan. --- I can successfully obtain a Kerberos ticket for the user. Eg: --- root at solaris:~# kinit exampleuser Password for exampleuser at HOME.LAN: root at solaris:~# --- And PAM is configured (in /etc/pam.conf) to use Kerberos for authentication. The Keytab looks normal to me: --- 1 host/solaris.home.lan at HOME.LAN (AES-256 CTS mode with 96-bit SHA-1 HMAC) 1 host/solaris.home.lan at HOME.LAN (AES-128 CTS mode with 96-bit SHA-1 HMAC) 1 host/solaris.home.lan at HOME.LAN (Triple DES cbc mode with HMAC/sha1) 1 host/solaris.home.lan at HOME.LAN (ArcFour with HMAC/md5) 1 nfs/solaris.home.lan at HOME.LAN (AES-256 CTS mode with 96-bit SHA-1 HMAC) 1 nfs/solaris.home.lan at HOME.LAN (AES-128 CTS mode with 96-bit SHA-1 HMAC) 1 nfs/solaris.home.lan at HOME.LAN (Triple DES cbc mode with HMAC/sha1) 1 nfs/solaris.home.lan at HOME.LAN (ArcFour with HMAC/md5) --- Looking at the server logs I see the following. This looks normal to me, when running kinit exampleuser --- Jan 10 22:38:56 rex.home.lan krb5kdc[12595](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.1.56: NEEDED_PREAUTH: exampleuser at HOME.LAN for krbtgt/HOME.LAN at HOME.LAN, Additional pre-authentication required Jan 10 22:39:03 rex.home.lan krb5kdc[12591](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.1.56: ISSUE: authtime 1326206343, etypes {rep=18 tkt=18 ses=18}, exampleuser at HOME.LAN for krbtgt/HOME.LAN at HOME.LAN --- When attempting to authenticate (through the PAM stack) as exampleuser with the same password I see: --- Jan 10 22:41:21 rex.home.lan krb5kdc[12592](info): preauth (timestamp) verify failure: Decrypt integrity check failed Jan 10 22:41:21 rex.home.lan krb5kdc[12592](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.1.56: PREAUTH_FAILED: exampleuser at HOME.LAN for krbtgt/HOME.LAN at HOME.LAN, Decrypt integrity check failed --- This seems to suggest that either the password is wrong, but I know I'm typing the right password or there is a decryption error. I'm confused by the fact that kinit works but PAM doesn't. Any ideas? -- Ian Chapman. From sgallagh at redhat.com Tue Jan 10 19:31:51 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 10 Jan 2012 14:31:51 -0500 Subject: [Freeipa-users] New SSSD FAQ page in the works Message-ID: <1326223911.10196.13.camel@sgallagh520.sgallagh.bos.redhat.com> It's come up more than once that SSSD needs a Frequently Asked Questions page to field some of our more common questions. I'm reaching out to the SSSD and FreeIPA user and developer communities to help us flesh out this page. I've begun it with the two most common questions I've received lately, as well as a basic primer on enabling debug logging to help identify issues. I'd like some additional suggestions on what questions should be answered on that page, as well as opening the page to volunteer-edits to add answers to any questions they may have had and solved (or enlisted aid in solving) in the past. The page is available at https://fedorahosted.org/sssd/wiki/FAQ and can be edited by anyone with a free Fedora account. If you don't have one, you can register quickly and easily at https://admin.fedorahosted.org/accounts Thank you very much for your contributions. Once this page has some meat, I will also be looking for interested translators to take a stab at making it accessible to non-English-native users. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From erinn.looneytriggs at gmail.com Wed Jan 11 16:41:39 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 11 Jan 2012 07:41:39 -0900 Subject: [Freeipa-users] Allowing nisdomainname to survive reboots Message-ID: <4F0DBBC3.5050803@gmail.com> Apologies in advance for my lack of understanding of NIS, I think I started my career a bit late for that particular product. Anyway, the sudo rules require the nisdomainname to be set on the server. The documentation states using nisdomainame CL tool, however, this does not appear to survive reboots. I have found that you can set NISDOMAINNAME in /etc/sysconfig/network, however, this too, at least on RHEL 5 systems (haven't been able to test 6 yet) does not seem to actually set the nisdomainname. Trouble is of course, without the nisdomainname being set, sudo won't work. This of course causes all kinds of excitement. So anyone know how to set this properly, or is there something wrong with my setup? -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From dpal at redhat.com Wed Jan 11 17:56:46 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Jan 2012 12:56:46 -0500 Subject: [Freeipa-users] New SSSD FAQ page in the works In-Reply-To: <1326223911.10196.13.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1326223911.10196.13.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4F0DCD5E.3050800@redhat.com> On 01/10/2012 02:31 PM, Stephen Gallagher wrote: > It's come up more than once that SSSD needs a Frequently Asked Questions > page to field some of our more common questions. I'm reaching out to the > SSSD and FreeIPA user and developer communities to help us flesh out > this page. > > I've begun it with the two most common questions I've received lately, > as well as a basic primer on enabling debug logging to help identify > issues. > > I'd like some additional suggestions on what questions should be > answered on that page, as well as opening the page to volunteer-edits to > add answers to any questions they may have had and solved (or enlisted > aid in solving) in the past. > > The page is available at https://fedorahosted.org/sssd/wiki/FAQ and can > be edited by anyone with a free Fedora account. If you don't have one, > you can register quickly and easily at > https://admin.fedorahosted.org/accounts > > Thank you very much for your contributions. > > Once this page has some meat, I will also be looking for interested > translators to take a stab at making it accessible to non-English-native > users. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users 1) What platforms SSSD is supported on? 2) Is there an API to configure it? 3) What are the valid combinations of identity+password+authentication+authorization data providers - should be pointer to a page that contains a matrix 4) When should I use enumeration=true ? Just came to mind... -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Wed Jan 11 19:22:10 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 11 Jan 2012 14:22:10 -0500 Subject: [Freeipa-users] New SSSD FAQ page in the works In-Reply-To: <4F0DCD5E.3050800@redhat.com> References: <1326223911.10196.13.camel@sgallagh520.sgallagh.bos.redhat.com> <4F0DCD5E.3050800@redhat.com> Message-ID: <1326309730.655.3.camel@sgallagh520.sgallagh.bos.redhat.com> On Wed, 2012-01-11 at 12:56 -0500, Dmitri Pal wrote: > On 01/10/2012 02:31 PM, Stephen Gallagher wrote: > > It's come up more than once that SSSD needs a Frequently Asked Questions > > page to field some of our more common questions. I'm reaching out to the > > SSSD and FreeIPA user and developer communities to help us flesh out > > this page. > > > > I've begun it with the two most common questions I've received lately, > > as well as a basic primer on enabling debug logging to help identify > > issues. > > > > I'd like some additional suggestions on what questions should be > > answered on that page, as well as opening the page to volunteer-edits to > > add answers to any questions they may have had and solved (or enlisted > > aid in solving) in the past. > > > > The page is available at https://fedorahosted.org/sssd/wiki/FAQ and can > > be edited by anyone with a free Fedora account. If you don't have one, > > you can register quickly and easily at > > https://admin.fedorahosted.org/accounts > > > > Thank you very much for your contributions. > > > > Once this page has some meat, I will also be looking for interested > > translators to take a stab at making it accessible to non-English-native > > users. > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > 1) What platforms SSSD is supported on? Added to the FAQ > 2) Is there an API to configure it? I think this is more suitable for a separate porting/packaging page, which we should probably also start writing. > 3) What are the valid combinations of identity+password+authentication > +authorization data providers - should be pointer to a page that > contains a matrix I agree we should describe this somehow, but I'm not sure what mechanism to use. A matrix doesn't really work because we have four providers (ID, AUTH, ACCESS and CHPASS) that need to interact. It's hard to create a four-dimensional matrix on a two-dimensional surface. > 4) When should I use enumeration=true ? Added to the FAQ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From g17jimmy at gmail.com Wed Jan 11 18:22:14 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 11 Jan 2012 13:22:14 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <201201100903.22597.jzeleny@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> Message-ID: We need to be able to replicate user/pass between Windows 2008 AD and FreeIPA. I have followed many different documents and posted here about it and from what I've read and procedures I've followed we are unable to accomplish this. It doesn't need to be a full trust. Thanks On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: > > Just wondering if there was anyone listening on the list that might be > > available for little work integrating FreeIPA with Active Directory > > (preferrably in the south east US.) I hope this isn't against the list > > rules, I just thought one of you guys could help or point me in the right > > direction. > > If you want some help, it is certainly not against list rules ;-) But in > that > case, it would be much better if you asked what exactly do you need. > > I'm not an AD expert, but a couple tips: If you are looking for > cross-domain > (cross-realm) trust, then you might be a bit disappointed, it is still in > development, so it probably won't be 100% functional at this moment. > > If you are looking for something else, could you be a little more specific > what > it is? > > I also recommend starting with reading some doc: > http://freeipa.org/page/DocumentationPortal > > Thanks > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Jan 11 20:32:03 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 11 Jan 2012 13:32:03 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <201201100903.22597.jzeleny@redhat.com> Message-ID: <4F0DF1C3.2020506@redhat.com> On 01/11/2012 11:22 AM, Jimmy wrote: > We need to be able to replicate user/pass between Windows 2008 AD and > FreeIPA. That's what IPA Windows Sync is supposed to do. > I have followed many different documents and posted here about it and > from what I've read and procedures I've followed we are unable to > accomplish this. What have you tried, and what problems have you run into? > It doesn't need to be a full trust. > > Thanks > > On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? > wrote: > > > Just wondering if there was anyone listening on the list that > might be > > available for little work integrating FreeIPA with Active Directory > > (preferrably in the south east US.) I hope this isn't against > the list > > rules, I just thought one of you guys could help or point me in > the right > > direction. > > If you want some help, it is certainly not against list rules ;-) > But in that > case, it would be much better if you asked what exactly do you need. > > I'm not an AD expert, but a couple tips: If you are looking for > cross-domain > (cross-realm) trust, then you might be a bit disappointed, it is > still in > development, so it probably won't be 100% functional at this moment. > > If you are looking for something else, could you be a little more > specific what > it is? > > I also recommend starting with reading some doc: > http://freeipa.org/page/DocumentationPortal > > Thanks > Jan > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Jan 12 01:24:16 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jan 2012 20:24:16 -0500 Subject: [Freeipa-users] Initial login on RHEL 6 fails In-Reply-To: <4F0B6D6C.2090502@gmail.com> References: <4F0B3CF1.4040703@gmail.com> <4F0B4F1A.2090103@redhat.com> <4F0B5C17.9030102@gmail.com> <1326148312.30661.260.camel@willson.li.ssimo.org> <4F0B6D6C.2090502@gmail.com> Message-ID: <1326331456.30661.384.camel@willson.li.ssimo.org> On Mon, 2012-01-09 at 13:42 -0900, Erinn Looney-Triggs wrote: > On 01/09/2012 01:31 PM, Simo Sorce wrote: > > On Mon, 2012-01-09 at 12:28 -0900, Erinn Looney-Triggs wrote: > >> > > [snip] > > > > > > Looks like the expiration is not updated, I suspect the password change > > actually failed. > > > >> A couple of additional notes that may be important. The system to > >> which > >> I am attempting to authenticate lives in private IP space whereas the > >> IPA server is on a public IP. > > > > Does it mean the client system is NATed wrt IPA ? > > That is correct. > > > > > I think that could make kpasswd fail. I need to check if this has been > > addressed in MIT libraries but IIRC it is a known limitation so far. > > The kpasswd binary I think specifies the IP address in mk_priv and fails > > verification from behind a NAT. > > > >> Second HBAC is in effect on the host so > >> the user must be a member of the desktop group in order to > >> authenticate. > > > > HBAC is not involved in any way with password changes, so I am confident > > you can exclude any correlation. > > > >> These may not have any bearing, or they may who knows. > > > > Yes the NAT part may be your issue. > > Yeah my kerb foo is a little rusty but the whole NAT/kerb thing causing > issues does ring a bell with me too. I will continue to research. For the MIT 1.10beta1 announcement[1]: * Allow password changes to work over NATs. So we will have that working in freeipa 2.2.0/3.0 when used with 1.10 once it is final. Simo [1] http://web.mit.edu/kerberos/krb5-1.10/krb5-1.10.html -- Simo Sorce * Red Hat, Inc * New York From erinn.looneytriggs at gmail.com Thu Jan 12 07:43:10 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 11 Jan 2012 22:43:10 -0900 Subject: [Freeipa-users] Initial login on RHEL 6 fails In-Reply-To: <1326331456.30661.384.camel@willson.li.ssimo.org> References: <4F0B3CF1.4040703@gmail.com> <4F0B4F1A.2090103@redhat.com> <4F0B5C17.9030102@gmail.com> <1326148312.30661.260.camel@willson.li.ssimo.org> <4F0B6D6C.2090502@gmail.com> <1326331456.30661.384.camel@willson.li.ssimo.org> Message-ID: <4F0E8F0E.2020209@gmail.com> On 01/11/2012 04:24 PM, Simo Sorce wrote: > On Mon, 2012-01-09 at 13:42 -0900, Erinn Looney-Triggs wrote: >> On 01/09/2012 01:31 PM, Simo Sorce wrote: >>> On Mon, 2012-01-09 at 12:28 -0900, Erinn Looney-Triggs wrote: >>>> >>> [snip] >>> >>> >>> Looks like the expiration is not updated, I suspect the password change >>> actually failed. >>> >>>> A couple of additional notes that may be important. The system to >>>> which >>>> I am attempting to authenticate lives in private IP space whereas the >>>> IPA server is on a public IP. >>> >>> Does it mean the client system is NATed wrt IPA ? >> >> That is correct. >> >>> >>> I think that could make kpasswd fail. I need to check if this has been >>> addressed in MIT libraries but IIRC it is a known limitation so far. >>> The kpasswd binary I think specifies the IP address in mk_priv and fails >>> verification from behind a NAT. >>> >>>> Second HBAC is in effect on the host so >>>> the user must be a member of the desktop group in order to >>>> authenticate. >>> >>> HBAC is not involved in any way with password changes, so I am confident >>> you can exclude any correlation. >>> >>>> These may not have any bearing, or they may who knows. >>> >>> Yes the NAT part may be your issue. >> >> Yeah my kerb foo is a little rusty but the whole NAT/kerb thing causing >> issues does ring a bell with me too. I will continue to research. > > For the MIT 1.10beta1 announcement[1]: > > * Allow password changes to work over NATs. > > > So we will have that working in freeipa 2.2.0/3.0 when used with 1.10 > once it is final. > > Simo > > [1] http://web.mit.edu/kerberos/krb5-1.10/krb5-1.10.html > Ah well that is quite nice. From my reading it looks like the kpasswd over nat bit has been on a standard track to allow this to happen for the last 8 years or so, so I wasn't holding out a lot of hope. Thanks for pointing this out, -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From jwhite at corp.acesse.com Thu Jan 12 16:28:56 2012 From: jwhite at corp.acesse.com (Jeff White) Date: Thu, 12 Jan 2012 10:28:56 -0600 Subject: [Freeipa-users] Using FreeIPA with AWS EC2 Message-ID: I'd like to use FreeIPA with Amazon's EC2 virtual machines. I'm seeing a number of barriers, mostly around DNS. An elastic IP address looks like it would solve the issues, but I'm not sure that will. And I'm wondering if there are any more barriers to making it work. Does anyone have experience with FreeIPA on EC2 or any thoughts about it? Thanks. -- Jeff White Acesse.com Technical Operations Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From i.am.stack at gmail.com Thu Jan 12 17:19:38 2012 From: i.am.stack at gmail.com (=?UTF-8?Q?Stack_Koror=C4=81?=) Date: Thu, 12 Jan 2012 11:19:38 -0600 Subject: [Freeipa-users] FreeIPA and DNSMasq vs BIND Message-ID: Hello, I am trying to better understand the --setup-dns option and I am going through the Red Hat documentation on IPA as my source[1]. This script generates a bunch of DNS redirects for the named server. I don't quite understand everything it does, but I am curious because I would prefer to use DNSMasq over named/dhcpd/tftpd. I am struggling trying to get named/dhcpd/tftpd to work anywhere close to the level that DNSMasq works for me. [1] http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#Preparing_for_an_IPA_Installation-DNS The exact problem I am working with is this: If I setup DNSMasq and follow the Red Hat documentation for 6.2 but I do not pass the --setup-dns option then when I try to install the clients they fail because they can't find the services on the network even when I try to force point them to the server. However, if I follow the guide step by step it turns out differently; it works. I disabled DNSMasq, installed named, and passed the --setup-dns option. The clients were then able to autodetect the server without problems. So then IPA works as expected but nothing else on the network does. Obviously the bind configuration is the designed implementation for IPA but I am spending far more of my time trying to get named/dhcpd/tftpd working acceptably then I have available. DNSMasq works great for me if I could figure out how to replicate the --setup-dns option in it. I am really hoping someone might be able to give me a few pointers in replicating the IPA named configuration in DNSMasq. Thank you! PS. I originally sent to the wrong list (devel). I greatly apologize. I was looking at the devel list doing research and grabbed the wrong email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Jan 12 18:46:06 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Jan 2012 13:46:06 -0500 Subject: [Freeipa-users] Using FreeIPA with AWS EC2 In-Reply-To: References: Message-ID: <1326393966.4737.11.camel@willson.li.ssimo.org> On Thu, 2012-01-12 at 10:28 -0600, Jeff White wrote: > I'd like to use FreeIPA with Amazon's EC2 virtual machines. I'm > seeing a number of barriers, mostly around DNS. An elastic IP address > looks like it would solve the issues, but I'm not sure that will. And > I'm wondering if there are any more barriers to making it work. Can you elaborate on the DNS issues ? Simo. -- Simo Sorce * Red Hat, Inc * New York From jwhite at corp.acesse.com Thu Jan 12 18:50:53 2012 From: jwhite at corp.acesse.com (Jeff White) Date: Thu, 12 Jan 2012 12:50:53 -0600 Subject: [Freeipa-users] Using FreeIPA with AWS EC2 In-Reply-To: <1326393966.4737.11.camel@willson.li.ssimo.org> References: <1326393966.4737.11.camel@willson.li.ssimo.org> Message-ID: It is with the hostname requirements. AWS EC2 normally gives you a dynamic IP address, which then you can update DNS records with. The reverse lookup on the IP is still the aws IP address in a text form, not the proper reverse. The documentation says: The reverse of the address that the hostname resolves to must match the hostname. Now I can get a nailed up elastic IP address which does not change, and if I put in a request I can get the reverse IP to map. The problem with that is there is a finite number of elastic IP addresses you can request - 5 - without begging for more. I'd rather not use them up. Can I get around this issue if I have my own DNS server running on the same machine? On Thu, Jan 12, 2012 at 12:46 PM, Simo Sorce wrote: > On Thu, 2012-01-12 at 10:28 -0600, Jeff White wrote: > > I'd like to use FreeIPA with Amazon's EC2 virtual machines. I'm > > seeing a number of barriers, mostly around DNS. An elastic IP address > > looks like it would solve the issues, but I'm not sure that will. And > > I'm wondering if there are any more barriers to making it work. > > Can you elaborate on the DNS issues ? > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- Jeff White Acesse.com Technical Operations Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Jan 12 18:51:25 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Jan 2012 13:51:25 -0500 Subject: [Freeipa-users] FreeIPA and DNSMasq vs BIND In-Reply-To: References: Message-ID: <1326394285.4737.15.camel@willson.li.ssimo.org> On Thu, 2012-01-12 at 11:19 -0600, Stack Koror? wrote: > Hello, > > I am trying to better understand the --setup-dns option and I am going > through the Red Hat documentation on IPA as my source[1]. This script > generates a bunch of DNS redirects for the named server. I don't quite > understand everything it does, but I am curious because I would prefer > to use DNSMasq over named/dhcpd/tftpd. I am struggling trying to get > named/dhcpd/tftpd to work anywhere close to the level that DNSMasq > works for me. > > [1] > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#Preparing_for_an_IPA_Installation-DNS > > The exact problem I am working with is this: If I setup DNSMasq and > follow the Red Hat documentation for 6.2 but I do not pass the > --setup-dns option then when I try to install the clients they fail > because they can't find the services on the network even when I try to > force point them to the server. However, if I follow the guide step by > step it turns out differently; it works. I disabled DNSMasq, installed > named, and passed the --setup-dns option. The clients were then able > to autodetect the server without problems. So then IPA works as > expected but nothing else on the network does. > > Obviously the bind configuration is the designed implementation for > IPA but I am spending far more of my time trying to get > named/dhcpd/tftpd working acceptably then I have available. DNSMasq > works great for me if I could figure out how to replicate the > --setup-dns option in it. Unfortunately it is not possible to use DNSMasq as a backend for the --setup-dns option. This option depends on a bind specific LDAP backend (bind-dyndb-ldap) and there is no equivalent plugin for DNSMasq. > I am really hoping someone might be able to give me a few pointers in > replicating the IPA named configuration in DNSMasq. If you want to use DNSMasq you will have to create an appropriate zone and fill it with the necessary SRV, TXT and A records. When you do not use --setup-dns the FreeIPA install script generates an example zone file. You can use that file to configure DNSMasq. Keep in mind this will also mean no Dynamic DNS updates nor LDAP updates are possible so you will have to manually mange your DNS for each replica and client you add to the FreeIPA domain. Another alternative is to use bind for DNS and keep using DNSMasq for the other services. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From sbingram at gmail.com Thu Jan 12 18:56:07 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Thu, 12 Jan 2012 10:56:07 -0800 Subject: [Freeipa-users] Using FreeIPA with AWS EC2 In-Reply-To: References: Message-ID: On Thu, Jan 12, 2012 at 8:28 AM, Jeff White wrote: > I'd like to use FreeIPA with Amazon's EC2 virtual machines. ?I'm seeing a > number of barriers, mostly around DNS. ?An elastic IP address looks like it > would solve the issues, but I'm not sure that will. ?And I'm wondering if > there are any more barriers to making it work. > Does anyone have experience with FreeIPA on EC2 or any thoughts about it? I'm running on KVM now, but I have successfully setup FreeIPA in an OpenVZ container. Of course, there is no SELinux (the reason I switched), but as long as you give it enough memory (I went around 2GB for the setup), it works great. I understand about the IP address though. You definitely want to use an elastic IP and adjust your /etc/hosts file accordingly so the host knows its public IP without any doubt. Steve From simo at redhat.com Thu Jan 12 18:59:34 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Jan 2012 13:59:34 -0500 Subject: [Freeipa-users] Using FreeIPA with AWS EC2 In-Reply-To: References: <1326393966.4737.11.camel@willson.li.ssimo.org> Message-ID: <1326394774.4737.19.camel@willson.li.ssimo.org> On Thu, 2012-01-12 at 12:50 -0600, Jeff White wrote: > It is with the hostname requirements. AWS EC2 normally gives you a > dynamic IP address, which then you can update DNS records with. The > reverse lookup on the IP is still the aws IP address in a text form, > not the proper reverse. The documentation says: > > > The reverse of the address that the hostname resolves to must > match the hostname. Nod. > Now I can get a nailed up elastic IP address which does not change, > and if I put in a request I can get the reverse IP to map. The > problem with that is there is a finite number of elastic IP addresses > you can request - 5 - without begging for more. I'd rather not use > them up. It is indeed recommended for the freeipa server to have a fixed IP address with proper A/AAAA and PTR records set. > > Can I get around this issue if I have my own DNS server running on the > same machine? Yes, if you use the --setup-dns switch the install script will set up a DNs server for you. There you can mamage both direct and reverse zones if you wish. All you need to do is to make sure forwarders redirect to the amazon provided DNSs so you can resolve other domain names and then point all your clients at your own DNS server on the freeipa server. This should make it easier to handle the requirements. Simo. -- Simo Sorce * Red Hat, Inc * New York From i.am.stack at gmail.com Fri Jan 13 04:45:35 2012 From: i.am.stack at gmail.com (~Stack~) Date: Thu, 12 Jan 2012 22:45:35 -0600 Subject: [Freeipa-users] FreeIPA and DNSMasq vs BIND In-Reply-To: <1326394285.4737.15.camel@willson.li.ssimo.org> References: <1326394285.4737.15.camel@willson.li.ssimo.org> Message-ID: <4F0FB6EF.2040505@gmail.com> On 01/12/2012 12:51 PM, Simo Sorce wrote: > If you want to use DNSMasq you will have to create an appropriate zone > and fill it with the necessary SRV, TXT and A records. When you do not > use --setup-dns the FreeIPA install script generates an example zone > file. You can use that file to configure DNSMasq. > > Keep in mind this will also mean no Dynamic DNS updates nor LDAP updates > are possible so you will have to manually mange your DNS for each > replica and client you add to the FreeIPA domain. Darn... > Another alternative is to use bind for DNS and keep using DNSMasq for > the other services. I will try this. Thank you for replying! ~Stack~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From g17jimmy at gmail.com Fri Jan 13 16:15:45 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 13 Jan 2012 11:15:45 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F0DF1C3.2020506@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> Message-ID: Just popping up to let y'all know I haven't dropped this, just got tied up working on OpenCA and PacketFence. I'll answer Rich's question by Monday and hopefully get this thing going. On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson wrote: > ** > On 01/11/2012 11:22 AM, Jimmy wrote: > > We need to be able to replicate user/pass between Windows 2008 AD and > FreeIPA. > > > That's what IPA Windows Sync is supposed to do. > > > I have followed many different documents and posted here about it and from > what I've read and procedures I've followed we are unable to accomplish > this. > > > What have you tried, and what problems have you run into? > > It doesn't need to be a full trust. > > Thanks > > On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: > >> > Just wondering if there was anyone listening on the list that might be >> > available for little work integrating FreeIPA with Active Directory >> > (preferrably in the south east US.) I hope this isn't against the list >> > rules, I just thought one of you guys could help or point me in the >> right >> > direction. >> >> If you want some help, it is certainly not against list rules ;-) But >> in that >> case, it would be much better if you asked what exactly do you need. >> >> I'm not an AD expert, but a couple tips: If you are looking for >> cross-domain >> (cross-realm) trust, then you might be a bit disappointed, it is still in >> development, so it probably won't be 100% functional at this moment. >> >> If you are looking for something else, could you be a little more >> specific what >> it is? >> >> I also recommend starting with reading some doc: >> http://freeipa.org/page/DocumentationPortal >> >> Thanks >> Jan >> > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelltoesuperstar at gmail.com Wed Jan 18 03:02:24 2012 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Wed, 18 Jan 2012 03:02:24 +0000 Subject: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers Message-ID: Hi I've got 5 different IPA servers at 5 differents labs around the country that are all replicas of one another. In order to keep the the cross-site network traffic to a minimum I want the IPA clients at Site "A" to only communicate to IPA Server "A", "B" to "B", "C" to "C" etc. except in the case of the failure of one of the servers. I originally assumed that making the IPA client to connect to a specific IPA server with "ipa-client-install --server=IPA_server_fqdn" would suffice but I very quickly found out this wasn't the case with the client going to multiple servers just to complete the installation process. Then I found out about modifying the DNS SRV records priority and weight however, please correct me if I'm wrong, these wouldn't these changes replicate and be enacted gloablly. (i.e. all clients at any site would prioritise IPA "A" over IPA "B"). Is there any way to get the functionality I desire? Thanks, Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Wed Jan 18 03:19:54 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 17 Jan 2012 22:19:54 -0500 Subject: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers In-Reply-To: References: Message-ID: <1326856794.21682.70.camel@sgallagh520.sgallagh.bos.redhat.com> On Wed, 2012-01-18 at 03:02 +0000, Charlie Derwent wrote: > Hi > > I've got 5 different IPA servers at 5 differents labs around the > country that are all replicas of one another. In order to keep the the > cross-site network traffic to a minimum I want the IPA clients at Site > "A" to only communicate to IPA Server "A", "B" to "B", "C" to "C" etc. > except in the case of the failure of one of the servers. > > I originally assumed that making the IPA client to connect to a > specific IPA server with "ipa-client-install --server=IPA_server_fqdn" > would suffice but I very quickly found out this wasn't the case with > the client going to multiple servers just to complete the installation > process. Then I found out about modifying the DNS SRV records priority > and weight however, please correct me if I'm wrong, these wouldn't > these changes replicate and be enacted gloablly. (i.e. all clients at > any site would prioritise IPA "A" over IPA "B"). > > Is there any way to get the functionality I desire? > We're looking at ways to implement a concept of client location into the connection logic. At the moment, however, the only way to do this is manually on the client. You can make the following change in the clients' /etc/sssd/sssd.conf files: In the [domain/your.domain.com] section there is an option "ipa_server". By default, this is configured to be: ipa_server = __srv__, x.x.x.x (Where x.x.x.x is the server you were originally talking to when you ran ipa-client-install, as a backup in case DNS is not working). You can manually change this to be: ipa_server = nearest.server.com, further.server.com, only-in-emergencies.server.com, ... With this manual setup, SSSD (the daemon that manages the client-side portion) will always attempt to connect to nearest.server.com unless it is unavailable, after which time it will fail over to the next in the list, and so on.* * If all of them are unavailable, SSSD switches to offline operation, where it will try to reconnect every couple of minutes, but will serve requests from its cache in the meantime. When it reconnects from an offline state, it will start retrying from the first server in the list (aka the nearest one). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From dpal at redhat.com Wed Jan 18 15:33:26 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 18 Jan 2012 10:33:26 -0500 Subject: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers In-Reply-To: <1326856794.21682.70.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1326856794.21682.70.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4F16E646.1000400@redhat.com> On 01/17/2012 10:19 PM, Stephen Gallagher wrote: > On Wed, 2012-01-18 at 03:02 +0000, Charlie Derwent wrote: >> Hi >> >> I've got 5 different IPA servers at 5 differents labs around the >> country that are all replicas of one another. In order to keep the the >> cross-site network traffic to a minimum I want the IPA clients at Site >> "A" to only communicate to IPA Server "A", "B" to "B", "C" to "C" etc. >> except in the case of the failure of one of the servers. >> >> I originally assumed that making the IPA client to connect to a >> specific IPA server with "ipa-client-install --server=IPA_server_fqdn" >> would suffice but I very quickly found out this wasn't the case with >> the client going to multiple servers just to complete the installation >> process. Then I found out about modifying the DNS SRV records priority >> and weight however, please correct me if I'm wrong, these wouldn't >> these changes replicate and be enacted gloablly. (i.e. all clients at >> any site would prioritise IPA "A" over IPA "B"). >> >> Is there any way to get the functionality I desire? >> > We're looking at ways to implement a concept of client location into the > connection logic. At the moment, however, the only way to do this is > manually on the client. > > You can make the following change in the clients' /etc/sssd/sssd.conf > files: > > In the [domain/your.domain.com] section there is an option "ipa_server". > > By default, this is configured to be: > ipa_server = __srv__, x.x.x.x > > (Where x.x.x.x is the server you were originally talking to when you ran > ipa-client-install, as a backup in case DNS is not working). > > You can manually change this to be: > ipa_server = nearest.server.com, further.server.com, > only-in-emergencies.server.com, ... > > With this manual setup, SSSD (the daemon that manages the client-side > portion) will always attempt to connect to nearest.server.com unless it > is unavailable, after which time it will fail over to the next in the > list, and so on.* > > > * If all of them are unavailable, SSSD switches to offline operation, > where it will try to reconnect every couple of minutes, but will serve > requests from its cache in the meantime. When it reconnects from an > offline state, it will start retrying from the first server in the list > (aka the nearest one). > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users We are tracking this requirement with the following ticket: https://fedorahosted.org/freeipa/ticket/122 It is currently Deferred is we do not have time to look at it yet but any help is always appreciated. It seems that the page that the ticket is pointing actually changed since we last looked at it. May be based on the ideas expressed in this page the changes can be made in IPA storage or LDAP driver without the need to touch BIND. If something like this is possible it would be much easier to implement. But still we have a full plate now and will for quite some time so help would be definitely needed. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at crystal.harvard.edu Wed Jan 18 17:17:12 2012 From: ian at crystal.harvard.edu (Ian Levesque) Date: Wed, 18 Jan 2012 12:17:12 -0500 Subject: [Freeipa-users] Replication for sites not using FreeIPA for DNS? Message-ID: Hello, I'm running IPA version 2.1.3-9 on RHEL 6.2 and just configured master/master replication. From what I can tell in the documentation [1], all of the client-discovering-a-replica magic happens via SRV records in DNS. This is quite different from what I'm used to, coming from managing an Open Directory service in which the replicated server's FQDN is passed on to the client through LDAP as an additional LDAP/KDC server to add to the client's local config. My question is how can I take advantage of replication if we're not using the FreeIPA-blessed DNS server? Do I need to manually tweak the SSSD config to make it aware of a second LDAP/KDC server? Is there a hidden flag I can pass ipa-client-install to do this for me? Thanks for any insight! Ian -- [1] http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#ipa-servers-replicas From dpal at redhat.com Wed Jan 18 17:30:30 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 18 Jan 2012 12:30:30 -0500 Subject: [Freeipa-users] Replication for sites not using FreeIPA for DNS? In-Reply-To: References: Message-ID: <4F1701B6.5060606@redhat.com> On 01/18/2012 12:17 PM, Ian Levesque wrote: > Hello, > > I'm running IPA version 2.1.3-9 on RHEL 6.2 and just configured master/master replication. From what I can tell in the documentation [1], all of the client-discovering-a-replica magic happens via SRV records in DNS. This is quite different from what I'm used to, coming from managing an Open Directory service in which the replicated server's FQDN is passed on to the client through LDAP as an additional LDAP/KDC server to add to the client's local config. > > My question is how can I take advantage of replication if we're not using the FreeIPA-blessed DNS server? Do I need to manually tweak the SSSD config to make it aware of a second LDAP/KDC server? Is there a hidden flag I can pass ipa-client-install to do this for me? > The answer is in the today thread called "Forcing IPA clients to prioritise different IPA Servers". See comment from Stephen Gallagher. He describes what to set in the SSSD config explicitly to identify the servers that will be used. > Thanks for any insight! > Ian > > > -- > [1] http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#ipa-servers-replicas > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From nsollars at gmail.com Wed Jan 18 17:30:51 2012 From: nsollars at gmail.com (Nigel Sollars) Date: Wed, 18 Jan 2012 12:30:51 -0500 Subject: [Freeipa-users] installation hickup Message-ID: Hi all, Ive been trying to install freeipa on centos 6.2. all packages are installed and DNS etc etc all straitened up. the hick up arises on the running of setup-ds.pl from the install log: 2012-01-18 12:13:40,007 DEBUG calling setup-ds.pl 2012-01-18 12:23:44,640 DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpBJYIDo 2012-01-18 12:23:44,640 DEBUG stdout=Server failed to start !!! Please check errors log for problems Possible timeout starting server: timeout=1326907423 now=1326907424 [12/01/18:12:23:44] - [Setup] Info Could not start the directory server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the error log was '[18/Jan/2012:12:13:43 -0500] - Failed to create semaphore for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) '. Error: Unknown error 256 Could not start the directory server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the error log was '[18/Jan/2012:12:13:43 -0500] - Failed to create semaphore for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) '. Error: Unknown error 256 [12/01/18:12:23:44] - [Setup] Fatal Error: Could not create directory server instance 'PKI-IPA'. Error: Could not create directory server instance 'PKI-IPA'. [12/01/18:12:23:44] - [Setup] Fatal Exiting . . . Log file is '-' Exiting . . . Log file is '-' 2012-01-18 12:23:44,640 DEBUG stderr=Server failed to start !!! Please check errors log for problems Possible timeout starting server: timeout=1326907423 now=1326907424 2012-01-18 12:23:44,641 CRITICAL failed to restart ds instance Command '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpBJYIDo' returned non-zero exit status 1 2012-01-18 12:23:44,641 DEBUG duration: 604 seconds 2012-01-18 12:23:44,641 DEBUG [3/3]: restarting directory server 2012-01-18 12:23:45,784 DEBUG args=/sbin/service dirsrv restart PKI-IPA 2012-01-18 12:23:45,784 DEBUG stdout=Shutting down dirsrv: PKI-IPA... server already stoppedESC[60G[ESC[0;31mFAILEDESC[0;39m] *** Error: 1 instance(s) unsuccessfully stoppedESC[60G[ESC[0;31mFAILEDESC[0;39m] Starting dirsrv: PKI-IPA...ESC[60G[ESC[0;31mFAILEDESC[0;39m] *** Warning: 1 instance(s) failed to start 2012-01-18 12:23:45,784 DEBUG stderr= 2012-01-18 12:23:45,825 DEBUG args=/sbin/service dirsrv status 2012-01-18 12:23:45,825 DEBUG stdout=dirsrv PKI-IPA is stopped 2012-01-18 12:23:45,825 DEBUG stderr= 2012-01-18 12:23:45,825 CRITICAL Failed to restart the directory server. See the installation log for details. (END) from the errors log there: [18/Jan/2012:12:13:43 -0500] - 389-Directory/1.2.9.14 B2011.342.117 starting up [18/Jan/2012:12:13:43 -0500] - Failed to create semaphore for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) [18/Jan/2012:12:23:44 -0500] - 389-Directory/1.2.9.14 B2011.342.117 starting up [18/Jan/2012:12:23:44 -0500] - Failed to create semaphore for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) Any idea what the perms should be?, seems that import and everything else went fine, also any additional things to get this one working would be certainly helpful. The package version used is 2.1.3. Thanks in advance Nigel Sollars -- ?Science is a differential equation. Religion is a boundary condition.? Alan Turing -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Jan 18 17:56:29 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 18 Jan 2012 12:56:29 -0500 Subject: [Freeipa-users] installation hickup In-Reply-To: References: Message-ID: <4F1707CD.7010307@redhat.com> On 01/18/2012 12:30 PM, Nigel Sollars wrote: > Hi all, > > Ive been trying to install freeipa on centos 6.2. all packages are > installed and DNS etc etc all straitened up. the hick up arises on > the running of setup-ds.pl > > from the install log: > > 2012-01-18 12:13:40,007 DEBUG calling setup-ds.pl > 2012-01-18 12:23:44,640 DEBUG args=/usr/sbin/setup-ds.pl > --silent --logfile - -f /tmp/tmpBJYIDo > 2012-01-18 12:23:44,640 DEBUG stdout=Server failed to start !!! Please > check errors log for problems > Possible timeout starting server: timeout=1326907423 now=1326907424 > [12/01/18:12:23:44] - [Setup] Info Could not start the directory > server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. > The last line from the error log was '[18/Jan/2012:12:13:43 -0500] - > Failed to create semaphore for stats file > (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) > '. Error: Unknown error 256 > Could not start the directory server using command > '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the > error log was '[18/Jan/2012:12:13:43 -0500] - Failed to create > semaphore for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error > 13.(Permission denied) > '. Error: Unknown error 256 > [12/01/18:12:23:44] - [Setup] Fatal Error: Could not create directory > server instance 'PKI-IPA'. > Error: Could not create directory server instance 'PKI-IPA'. > [12/01/18:12:23:44] - [Setup] Fatal Exiting . . . > Log file is '-' > > Exiting . . . > Log file is '-' > > > 2012-01-18 12:23:44,640 DEBUG stderr=Server failed to start !!! Please > check errors log for problems > Possible timeout starting server: timeout=1326907423 now=1326907424 > > 2012-01-18 12:23:44,641 CRITICAL failed to restart ds instance Command > '/usr/sbin/setup-ds.pl --silent --logfile - -f > /tmp/tmpBJYIDo' returned non-zero exit status 1 > 2012-01-18 12:23:44,641 DEBUG duration: 604 seconds > 2012-01-18 12:23:44,641 DEBUG [3/3]: restarting directory server > 2012-01-18 12:23:45,784 DEBUG args=/sbin/service dirsrv restart PKI-IPA > 2012-01-18 12:23:45,784 DEBUG stdout=Shutting down dirsrv: > PKI-IPA... server already stoppedESC[60G[ESC[0;31mFAILEDESC[0;39m] > *** Error: 1 instance(s) unsuccessfully > stoppedESC[60G[ESC[0;31mFAILEDESC[0;39m] > Starting dirsrv: > PKI-IPA...ESC[60G[ESC[0;31mFAILEDESC[0;39m] > *** Warning: 1 instance(s) failed to start > > 2012-01-18 12:23:45,784 DEBUG stderr= > 2012-01-18 12:23:45,825 DEBUG args=/sbin/service dirsrv status > 2012-01-18 12:23:45,825 DEBUG stdout=dirsrv PKI-IPA is stopped > > 2012-01-18 12:23:45,825 DEBUG stderr= > 2012-01-18 12:23:45,825 CRITICAL Failed to restart the directory > server. See the installation log for details. > (END) > > from the errors log there: > > [18/Jan/2012:12:13:43 -0500] - 389-Directory/1.2.9.14 > B2011.342.117 starting up > [18/Jan/2012:12:13:43 -0500] - Failed to create semaphore for stats > file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) > [18/Jan/2012:12:23:44 -0500] - 389-Directory/1.2.9.14 > B2011.342.117 starting up > [18/Jan/2012:12:23:44 -0500] - Failed to create semaphore for stats > file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) > > Any idea what the perms should be?, seems that import and everything > else went fine, also any additional things to get this one working > would be certainly helpful. > Smells like SELinux problem. DS is not allowed to access the specified directory. Some policy might be missing. Just a guess though. > > The package version used is 2.1.3. > > Thanks in advance > > Nigel Sollars > > -- > ?Science is a differential equation. Religion is a boundary condition.? > > Alan Turing > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Jan 18 17:56:12 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 18 Jan 2012 10:56:12 -0700 Subject: [Freeipa-users] installation hickup In-Reply-To: References: Message-ID: <4F1707BC.7050701@redhat.com> On 01/18/2012 10:30 AM, Nigel Sollars wrote: > Hi all, > > Ive been trying to install freeipa on centos 6.2. all packages are > installed and DNS etc etc all straitened up. the hick up arises on > the running of setup-ds.pl > > from the install log: > > 2012-01-18 12:13:40,007 DEBUG calling setup-ds.pl > 2012-01-18 12:23:44,640 DEBUG args=/usr/sbin/setup-ds.pl > --silent --logfile - -f /tmp/tmpBJYIDo > 2012-01-18 12:23:44,640 DEBUG stdout=Server failed to start !!! Please > check errors log for problems > Possible timeout starting server: timeout=1326907423 now=1326907424 > [12/01/18:12:23:44] - [Setup] Info Could not start the directory > server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. > The last line from the error log was '[18/Jan/2012:12:13:43 -0500] - > Failed to create semaphore for stats file > (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) > '. Error: Unknown error 256 > Could not start the directory server using command > '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the > error log was '[18/Jan/2012:12:13:43 -0500] - Failed to create > semaphore for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error > 13.(Permission denied) > '. Error: Unknown error 256 > [12/01/18:12:23:44] - [Setup] Fatal Error: Could not create directory > server instance 'PKI-IPA'. > Error: Could not create directory server instance 'PKI-IPA'. > [12/01/18:12:23:44] - [Setup] Fatal Exiting . . . > Log file is '-' > > Exiting . . . > Log file is '-' > > > 2012-01-18 12:23:44,640 DEBUG stderr=Server failed to start !!! Please > check errors log for problems > Possible timeout starting server: timeout=1326907423 now=1326907424 > > 2012-01-18 12:23:44,641 CRITICAL failed to restart ds instance Command > '/usr/sbin/setup-ds.pl --silent --logfile - -f > /tmp/tmpBJYIDo' returned non-zero exit status 1 > 2012-01-18 12:23:44,641 DEBUG duration: 604 seconds > 2012-01-18 12:23:44,641 DEBUG [3/3]: restarting directory server > 2012-01-18 12:23:45,784 DEBUG args=/sbin/service dirsrv restart PKI-IPA > 2012-01-18 12:23:45,784 DEBUG stdout=Shutting down dirsrv: > PKI-IPA... server already stoppedESC[60G[ESC[0;31mFAILEDESC[0;39m] > *** Error: 1 instance(s) unsuccessfully > stoppedESC[60G[ESC[0;31mFAILEDESC[0;39m] > Starting dirsrv: > PKI-IPA...ESC[60G[ESC[0;31mFAILEDESC[0;39m] > *** Warning: 1 instance(s) failed to start > > 2012-01-18 12:23:45,784 DEBUG stderr= > 2012-01-18 12:23:45,825 DEBUG args=/sbin/service dirsrv status > 2012-01-18 12:23:45,825 DEBUG stdout=dirsrv PKI-IPA is stopped > > 2012-01-18 12:23:45,825 DEBUG stderr= > 2012-01-18 12:23:45,825 CRITICAL Failed to restart the directory > server. See the installation log for details. > (END) > > from the errors log there: > > [18/Jan/2012:12:13:43 -0500] - 389-Directory/1.2.9.14 > B2011.342.117 starting up > [18/Jan/2012:12:13:43 -0500] - Failed to create semaphore for stats > file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) > [18/Jan/2012:12:23:44 -0500] - 389-Directory/1.2.9.14 > B2011.342.117 starting up > [18/Jan/2012:12:23:44 -0500] - Failed to create semaphore for stats > file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) sounds like a left over shm file from a previous install attempt ls -al /dev/shm you'll have to start over with an ipa-server-install --uninstall if you then have left over sem.slapd-INST-NAME.stats files, remove them > > Any idea what the perms should be?, seems that import and everything > else went fine, also any additional things to get this one working > would be certainly helpful. > > > The package version used is 2.1.3. > > Thanks in advance > > Nigel Sollars > > -- > ?Science is a differential equation. Religion is a boundary condition.? > > Alan Turing > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsollars at gmail.com Wed Jan 18 18:49:10 2012 From: nsollars at gmail.com (Nigel Sollars) Date: Wed, 18 Jan 2012 13:49:10 -0500 Subject: [Freeipa-users] installation hickup In-Reply-To: <4F1707BC.7050701@redhat.com> References: <4F1707BC.7050701@redhat.com> Message-ID: Hi, thanks for the quick response, I put SELinux into passive mode, and ran the uninstall ( again ), removed /var/lib/dirsrv and /var/run/dirsrv. in /dev/shm I have nothing, nothing is created there whilst installation either, the directory remains empty. re-running install fails the same as before, any other pointers would be most welcome. One other thing is this is a guest in Xen, i run the install with the -N option as suggested. Nige On Wed, Jan 18, 2012 at 12:56 PM, Rich Megginson wrote: > ** > On 01/18/2012 10:30 AM, Nigel Sollars wrote: > > Hi all, > > Ive been trying to install freeipa on centos 6.2. all packages are > installed and DNS etc etc all straitened up. the hick up arises on the > running of setup-ds.pl > > from the install log: > > 2012-01-18 12:13:40,007 DEBUG calling setup-ds.pl > 2012-01-18 12:23:44,640 DEBUG args=/usr/sbin/setup-ds.pl --silent > --logfile - -f /tmp/tmpBJYIDo > 2012-01-18 12:23:44,640 DEBUG stdout=Server failed to start !!! Please > check errors log for problems > Possible timeout starting server: timeout=1326907423 now=1326907424 > [12/01/18:12:23:44] - [Setup] Info Could not start the directory server > using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line > from the error log was '[18/Jan/2012:12:13:43 -0500] - Failed to create > semaphore for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error > 13.(Permission denied) > '. Error: Unknown error 256 > Could not start the directory server using command > '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the > error log was '[18/Jan/2012:12:13:43 -0500] - Failed to create semaphore > for stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission > denied) > '. Error: Unknown error 256 > [12/01/18:12:23:44] - [Setup] Fatal Error: Could not create directory > server instance 'PKI-IPA'. > Error: Could not create directory server instance 'PKI-IPA'. > [12/01/18:12:23:44] - [Setup] Fatal Exiting . . . > Log file is '-' > > Exiting . . . > Log file is '-' > > > 2012-01-18 12:23:44,640 DEBUG stderr=Server failed to start !!! Please > check errors log for problems > Possible timeout starting server: timeout=1326907423 now=1326907424 > > 2012-01-18 12:23:44,641 CRITICAL failed to restart ds instance Command > '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpBJYIDo' returned > non-zero exit status 1 > 2012-01-18 12:23:44,641 DEBUG duration: 604 seconds > 2012-01-18 12:23:44,641 DEBUG [3/3]: restarting directory server > 2012-01-18 12:23:45,784 DEBUG args=/sbin/service dirsrv restart PKI-IPA > 2012-01-18 12:23:45,784 DEBUG stdout=Shutting down dirsrv: > PKI-IPA... server already stoppedESC[60G[ESC[0;31mFAILEDESC[0;39m] > *** Error: 1 instance(s) unsuccessfully > stoppedESC[60G[ESC[0;31mFAILEDESC[0;39m] > Starting dirsrv: > PKI-IPA...ESC[60G[ESC[0;31mFAILEDESC[0;39m] > *** Warning: 1 instance(s) failed to start > > 2012-01-18 12:23:45,784 DEBUG stderr= > 2012-01-18 12:23:45,825 DEBUG args=/sbin/service dirsrv status > 2012-01-18 12:23:45,825 DEBUG stdout=dirsrv PKI-IPA is stopped > > 2012-01-18 12:23:45,825 DEBUG stderr= > 2012-01-18 12:23:45,825 CRITICAL Failed to restart the directory server. > See the installation log for details. > (END) > > from the errors log there: > > [18/Jan/2012:12:13:43 -0500] - 389-Directory/1.2.9.14 B2011.342.117 > starting up > [18/Jan/2012:12:13:43 -0500] - Failed to create semaphore for stats file > (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) > [18/Jan/2012:12:23:44 -0500] - 389-Directory/1.2.9.14 B2011.342.117 > starting up > [18/Jan/2012:12:23:44 -0500] - Failed to create semaphore for stats file > (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) > > sounds like a left over shm file from a previous install attempt > ls -al /dev/shm > > you'll have to start over with an ipa-server-install --uninstall > if you then have left over sem.slapd-INST-NAME.stats files, remove them > > > Any idea what the perms should be?, seems that import and everything > else went fine, also any additional things to get this one working would be > certainly helpful. > > > The package version used is 2.1.3. > > Thanks in advance > > Nigel Sollars > > -- > ?Science is a differential equation. Religion is a boundary condition.? > > Alan Turing > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > -- ?Science is a differential equation. Religion is a boundary condition.? Alan Turing -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Jan 18 18:57:56 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 18 Jan 2012 13:57:56 -0500 Subject: [Freeipa-users] installation hickup In-Reply-To: References: <4F1707BC.7050701@redhat.com> Message-ID: <4F171634.9080601@redhat.com> On 01/18/2012 01:49 PM, Nigel Sollars wrote: > Hi, > > thanks for the quick response, > > I put SELinux into passive mode, and ran the uninstall ( again ), > removed /var/lib/dirsrv and /var/run/dirsrv. > > in /dev/shm I have nothing, nothing is created there whilst > installation either, the directory remains empty. > > re-running install fails the same as before, any other pointers would > be most welcome. One other thing is this is a guest in Xen, i run > the install with the -N option as suggested. > What about limits? >From my past I remember that there are some default settings that might limit the number of resources like threads or semaphores. May be it makes sense to try to increase those. > Nige > > On Wed, Jan 18, 2012 at 12:56 PM, Rich Megginson > wrote: > > On 01/18/2012 10:30 AM, Nigel Sollars wrote: >> Hi all, >> >> Ive been trying to install freeipa on centos 6.2. all packages >> are installed and DNS etc etc all straitened up. the hick up >> arises on the running of setup-ds.pl >> >> from the install log: >> >> 2012-01-18 12 :13:40,007 DEBUG calling >> setup-ds.pl >> 2012-01-18 12 :23:44,640 DEBUG >> args=/usr/sbin/setup-ds.pl --silent >> --logfile - -f /tmp/tmpBJYIDo >> 2012-01-18 12 :23:44,640 DEBUG stdout=Server >> failed to start !!! Please check errors log for problems >> Possible timeout starting server: timeout=1326907423 now=1326907424 >> [12/01/18:12:23:44] - [Setup] Info Could not start the directory >> server using command >> '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line >> from the error log was '[18/Jan/2012:12:13:43 -0500] - Failed to >> create semaphore for stats file >> (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) >> '. Error: Unknown error 256 >> Could not start the directory server using command >> '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line >> from the error log was '[18/Jan/2012:12:13:43 -0500] - Failed to >> create semaphore for stats file >> (/var/run/dirsrv/slapd-PKI-IPA.stats). Error 13.(Permission denied) >> '. Error: Unknown error 256 >> [12/01/18:12:23:44] - [Setup] Fatal Error: Could not create >> directory server instance 'PKI-IPA'. >> Error: Could not create directory server instance 'PKI-IPA'. >> [12/01/18:12:23:44] - [Setup] Fatal Exiting . . . >> Log file is '-' >> >> Exiting . . . >> Log file is '-' >> >> >> 2012-01-18 12 :23:44,640 DEBUG stderr=Server >> failed to start !!! Please check errors log for problems >> Possible timeout starting server: timeout=1326907423 now=1326907424 >> >> 2012-01-18 12 :23:44,641 CRITICAL failed to >> restart ds instance Command '/usr/sbin/setup-ds.pl >> --silent --logfile - -f /tmp/tmpBJYIDo' >> returned non-zero exit status 1 >> 2012-01-18 12 :23:44,641 DEBUG duration: >> 604 seconds >> 2012-01-18 12 :23:44,641 DEBUG [3/3]: >> restarting directory server >> 2012-01-18 12 :23:45,784 DEBUG >> args=/sbin/service dirsrv restart PKI-IPA >> 2012-01-18 12 :23:45,784 DEBUG >> stdout=Shutting down dirsrv: >> PKI-IPA... server already >> stoppedESC[60G[ESC[0;31mFAILEDESC[0;39m] >> *** Error: 1 instance(s) unsuccessfully >> stoppedESC[60G[ESC[0;31mFAILEDESC[0;39m] >> Starting dirsrv: >> PKI-IPA...ESC[60G[ESC[0;31mFAILEDESC[0;39m] >> *** Warning: 1 instance(s) failed to start >> >> 2012-01-18 12 :23:45,784 DEBUG stderr= >> 2012-01-18 12 :23:45,825 DEBUG >> args=/sbin/service dirsrv status >> 2012-01-18 12 :23:45,825 DEBUG stdout=dirsrv >> PKI-IPA is stopped >> >> 2012-01-18 12 :23:45,825 DEBUG stderr= >> 2012-01-18 12 :23:45,825 CRITICAL Failed to >> restart the directory server. See the installation log for details. >> (END) >> >> from the errors log there: >> >> [18/Jan/2012:12:13:43 -0500] - 389-Directory/1.2.9.14 >> B2011.342.117 starting up >> [18/Jan/2012:12:13:43 -0500] - Failed to create semaphore for >> stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error >> 13.(Permission denied) >> [18/Jan/2012:12:23:44 -0500] - 389-Directory/1.2.9.14 >> B2011.342.117 starting up >> [18/Jan/2012:12:23:44 -0500] - Failed to create semaphore for >> stats file (/var/run/dirsrv/slapd-PKI-IPA.stats). Error >> 13.(Permission denied) > sounds like a left over shm file from a previous install attempt > ls -al /dev/shm > > you'll have to start over with an ipa-server-install --uninstall > if you then have left over sem.slapd-INST-NAME.stats files, remove > them >> >> Any idea what the perms should be?, seems that import and >> everything else went fine, also any additional things to get this >> one working would be certainly helpful. >> >> >> The package version used is 2.1.3. >> >> Thanks in advance >> >> Nigel Sollars >> >> -- >> ?Science is a differential equation. Religion is a boundary >> condition.? >> >> Alan Turing >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > ?Science is a differential equation. Religion is a boundary condition.? > > Alan Turing > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Wed Jan 18 19:08:24 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 18 Jan 2012 14:08:24 -0500 Subject: [Freeipa-users] Replication for sites not using FreeIPA for DNS? In-Reply-To: References: Message-ID: <1326913704.5287.17.camel@sgallagh520.sgallagh.bos.redhat.com> On Wed, 2012-01-18 at 12:17 -0500, Ian Levesque wrote: > Hello, > > I'm running IPA version 2.1.3-9 on RHEL 6.2 and just configured > master/master replication. From what I can tell in the documentation > [1], all of the client-discovering-a-replica magic happens via SRV > records in DNS. This is quite different from what I'm used to, coming > from managing an Open Directory service in which the replicated > server's FQDN is passed on to the client through LDAP as an additional > LDAP/KDC server to add to the client's local config. > > My question is how can I take advantage of replication if we're not > using the FreeIPA-blessed DNS server? Do I need to manually tweak the > SSSD config to make it aware of a second LDAP/KDC server? Is there a > hidden flag I can pass ipa-client-install to do this for me? In addition to Dmitri's comments (and mine in the "Forcing IPA clients to prioritise different IPA Servers" thread) you should be aware that just because you're not using FreeIPA as the DNS server, it doesn't mean that you can't use SRV records to solve this problem. The SRV records are looked up on whatever DNS server is configured in /etc/resolv.conf. So if you ask your DNS administrator to add SRV records for your FreeIPA replicas, you can still continue this way. Otherwise, your best bet is to edit the sssd.conf directly (for now. As Dmitri says, we're looking at other approaches for future FreeIPA releases). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From erinn.looneytriggs at gmail.com Wed Jan 18 19:47:20 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 18 Jan 2012 10:47:20 -0900 Subject: [Freeipa-users] Sudo options Message-ID: <4F1721C8.1050203@gmail.com> I can't really figure out what the proper syntax is for the sudo rules in IPA. I have a number of options that I would like included by default, I have put them in place, from ipa sudorule-show: Sudo Option: env_keep = "LESSSECURE", env_reset, mail_badpass, mail_no_host, mail_no_perms, syslog = local2 This doesn't appear to work, when sudo is run: sudo: unknown defaults entry `env_keep ' sudo: unknown defaults entry `mail_badpass, mail_no_host, mail_no_perms, syslog ' One thing that jumps out at me is that the '= whatever' portion is not being maintained. The directions in the IDM guide are less than clear, simply referencing the sudoers page for options. These are all valid sudo options, this is basically a straight port over from a sudoers file. So anyone have any experience doing this bit? -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From ian at crystal.harvard.edu Wed Jan 18 20:38:04 2012 From: ian at crystal.harvard.edu (Ian Levesque) Date: Wed, 18 Jan 2012 15:38:04 -0500 Subject: [Freeipa-users] Replication for sites not using FreeIPA for DNS? In-Reply-To: <1326913704.5287.17.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1326913704.5287.17.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <8E143A4E-A49F-428D-999E-A0A5F19F815B@crystal.harvard.edu> On Jan 18, 2012, at 2:08 PM, Stephen Gallagher wrote: > On Wed, 2012-01-18 at 12:17 -0500, Ian Levesque wrote: >> Hello, >> >> I'm running IPA version 2.1.3-9 on RHEL 6.2 and just configured >> master/master replication. From what I can tell in the documentation >> [1], all of the client-discovering-a-replica magic happens via SRV >> records in DNS. This is quite different from what I'm used to, coming >> from managing an Open Directory service in which the replicated >> server's FQDN is passed on to the client through LDAP as an additional >> LDAP/KDC server to add to the client's local config. >> >> My question is how can I take advantage of replication if we're not >> using the FreeIPA-blessed DNS server? Do I need to manually tweak the >> SSSD config to make it aware of a second LDAP/KDC server? Is there a >> hidden flag I can pass ipa-client-install to do this for me? > > > In addition to Dmitri's comments (and mine in the "Forcing IPA clients > to prioritise different IPA Servers" thread) you should be aware that > just because you're not using FreeIPA as the DNS server, it doesn't mean > that you can't use SRV records to solve this problem. > > The SRV records are looked up on whatever DNS server is configured > in /etc/resolv.conf. So if you ask your DNS administrator to add SRV > records for your FreeIPA replicas, you can still continue this way. > > Otherwise, your best bet is to edit the sssd.conf directly (for now. As > Dmitri says, we're looking at other approaches for future FreeIPA > releases). Many thanks to both of you for your replies. I'm curious why you don't employ a feature similar to Apple's approach, where replica information is passed to the client. In this scenario, SSSD can be notified of the configuration and handle it automatically... I'm personally not a big fan of using DNS for service management, and would prefer to have the server and client hash it out amongst themselves. That said, I appreciate the workaround and can easily incorporate it into our deployment workflow. Best regards, Ian From dpal at redhat.com Wed Jan 18 20:45:40 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 18 Jan 2012 15:45:40 -0500 Subject: [Freeipa-users] Replication for sites not using FreeIPA for DNS? In-Reply-To: <8E143A4E-A49F-428D-999E-A0A5F19F815B@crystal.harvard.edu> References: <1326913704.5287.17.camel@sgallagh520.sgallagh.bos.redhat.com> <8E143A4E-A49F-428D-999E-A0A5F19F815B@crystal.harvard.edu> Message-ID: <4F172F74.6070108@redhat.com> On 01/18/2012 03:38 PM, Ian Levesque wrote: > On Jan 18, 2012, at 2:08 PM, Stephen Gallagher wrote: > >> On Wed, 2012-01-18 at 12:17 -0500, Ian Levesque wrote: >>> Hello, >>> >>> I'm running IPA version 2.1.3-9 on RHEL 6.2 and just configured >>> master/master replication. From what I can tell in the documentation >>> [1], all of the client-discovering-a-replica magic happens via SRV >>> records in DNS. This is quite different from what I'm used to, coming >>> from managing an Open Directory service in which the replicated >>> server's FQDN is passed on to the client through LDAP as an additional >>> LDAP/KDC server to add to the client's local config. >>> >>> My question is how can I take advantage of replication if we're not >>> using the FreeIPA-blessed DNS server? Do I need to manually tweak the >>> SSSD config to make it aware of a second LDAP/KDC server? Is there a >>> hidden flag I can pass ipa-client-install to do this for me? >> >> In addition to Dmitri's comments (and mine in the "Forcing IPA clients >> to prioritise different IPA Servers" thread) you should be aware that >> just because you're not using FreeIPA as the DNS server, it doesn't mean >> that you can't use SRV records to solve this problem. >> >> The SRV records are looked up on whatever DNS server is configured >> in /etc/resolv.conf. So if you ask your DNS administrator to add SRV >> records for your FreeIPA replicas, you can still continue this way. >> >> Otherwise, your best bet is to edit the sssd.conf directly (for now. As >> Dmitri says, we're looking at other approaches for future FreeIPA >> releases). > Many thanks to both of you for your replies. I'm curious why you don't employ a feature similar to Apple's approach, where replica information is passed to the client. In this scenario, SSSD can be notified of the configuration and handle it automatically... I'm personally not a big fan of using DNS for service management, and would prefer to have the server and client hash it out amongst themselves. That said, I appreciate the workaround and can easily incorporate it into our deployment workflow. > We looked into passing configuration at early stages but seemed to be much more complex and less extensible than DNS based solution. > Best regards, > Ian > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From JR.Aquino at citrix.com Wed Jan 18 20:50:31 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Wed, 18 Jan 2012 20:50:31 +0000 Subject: [Freeipa-users] Sudo options In-Reply-To: <4F1721C8.1050203@gmail.com> References: <4F1721C8.1050203@gmail.com> Message-ID: <918E438C-971C-436B-941E-2A4AD55266C1@citrixonline.com> On Jan 18, 2012, at 11:47 AM, Erinn Looney-Triggs wrote: > I can't really figure out what the proper syntax is for the sudo rules > in IPA. I have a number of options that I would like included by > default, I have put them in place, from ipa sudorule-show: > > Sudo Option: env_keep = "LESSSECURE", env_reset, mail_badpass, > mail_no_host, mail_no_perms, syslog = local2 It looks to be getting confused by the whitespace. Remove the whitespace for env_keep = "LESSSECURE" & syslog = local2 to: env_keep="LESSSECURE" syslog=local2 Let me know if that helps. Also, can you post a compare against: ipa sudorule-show defaults vs $ sudo -l > > This doesn't appear to work, when sudo is run: > > sudo: unknown defaults entry `env_keep ' > sudo: unknown defaults entry `mail_badpass, mail_no_host, mail_no_perms, > syslog ' > > One thing that jumps out at me is that the '= whatever' portion is not > being maintained. > > The directions in the IDM guide are less than clear, simply referencing > the sudoers page for options. These are all valid sudo options, this is > basically a straight port over from a sudoers file. > > So anyone have any experience doing this bit? > > -Erinn > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From erinn.looneytriggs at gmail.com Wed Jan 18 21:24:24 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 18 Jan 2012 12:24:24 -0900 Subject: [Freeipa-users] Sudo options In-Reply-To: <918E438C-971C-436B-941E-2A4AD55266C1@citrixonline.com> References: <4F1721C8.1050203@gmail.com> <918E438C-971C-436B-941E-2A4AD55266C1@citrixonline.com> Message-ID: <4F173888.2050804@gmail.com> On 01/18/2012 11:50 AM, JR Aquino wrote: > On Jan 18, 2012, at 11:47 AM, Erinn Looney-Triggs wrote: > >> I can't really figure out what the proper syntax is for the sudo rules >> in IPA. I have a number of options that I would like included by >> default, I have put them in place, from ipa sudorule-show: >> >> Sudo Option: env_keep = "LESSSECURE", env_reset, mail_badpass, >> mail_no_host, mail_no_perms, syslog = local2 > > It looks to be getting confused by the whitespace. > > Remove the whitespace for env_keep = "LESSSECURE" & syslog = local2 to: > env_keep="LESSSECURE" > syslog=local2 > > Let me know if that helps. > > Also, can you post a compare against: > > ipa sudorule-show defaults > > vs > > $ sudo -l > > >> >> This doesn't appear to work, when sudo is run: >> >> sudo: unknown defaults entry `env_keep ' >> sudo: unknown defaults entry `mail_badpass, mail_no_host, mail_no_perms, >> syslog ' >> >> One thing that jumps out at me is that the '= whatever' portion is not >> being maintained. >> >> The directions in the IDM guide are less than clear, simply referencing >> the sudoers page for options. These are all valid sudo options, this is >> basically a straight port over from a sudoers file. >> >> So anyone have any experience doing this bit? >> >> -Erinn >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > It looks like this was actually ttwo problems, one the quoting, and the second that via the web ui, I had put multiple options on a single line separated by a comma, so initially one rule was: mail_badpass, mail_no_host, mail_no_perms, syslog = local2 After fixing the spacing issue, as well as putting each into it's own statement everything worked just fine. There should probably either be better documentation, or better validation of input for those options, or ideally both :). I reckon I will open a bug up. Thanks for the help, -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From erinn.looneytriggs at gmail.com Wed Jan 18 21:29:08 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 18 Jan 2012 12:29:08 -0900 Subject: [Freeipa-users] Sudo options In-Reply-To: <918E438C-971C-436B-941E-2A4AD55266C1@citrixonline.com> References: <4F1721C8.1050203@gmail.com> <918E438C-971C-436B-941E-2A4AD55266C1@citrixonline.com> Message-ID: <4F1739A4.3070302@gmail.com> On 01/18/2012 11:50 AM, JR Aquino wrote: > On Jan 18, 2012, at 11:47 AM, Erinn Looney-Triggs wrote: > >> I can't really figure out what the proper syntax is for the sudo rules >> in IPA. I have a number of options that I would like included by >> default, I have put them in place, from ipa sudorule-show: >> >> Sudo Option: env_keep = "LESSSECURE", env_reset, mail_badpass, >> mail_no_host, mail_no_perms, syslog = local2 > > It looks to be getting confused by the whitespace. > > Remove the whitespace for env_keep = "LESSSECURE" & syslog = local2 to: > env_keep="LESSSECURE" > syslog=local2 > > Let me know if that helps. > > Also, can you post a compare against: > > ipa sudorule-show defaults > > vs > > $ sudo -l > > >> >> This doesn't appear to work, when sudo is run: >> >> sudo: unknown defaults entry `env_keep ' >> sudo: unknown defaults entry `mail_badpass, mail_no_host, mail_no_perms, >> syslog ' >> >> One thing that jumps out at me is that the '= whatever' portion is not >> being maintained. >> >> The directions in the IDM guide are less than clear, simply referencing >> the sudoers page for options. These are all valid sudo options, this is >> basically a straight port over from a sudoers file. >> >> So anyone have any experience doing this bit? >> >> -Erinn >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > Sorry missed the second part. From sudo -l: requiretty, env_reset, env_keep="COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC KDEDIR LESSSECURE LS_COLORS MAIL PATH PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", mail_badpass, mail_no_host, mail_no_perms, syslog=local2 from sudorule-show: Sudo Option: env_keep = "LESSSECURE", env_reset, mail_badpass, mail_no_host, mail_no_perms, syslog = local2 -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From JR.Aquino at citrix.com Wed Jan 18 21:37:58 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Wed, 18 Jan 2012 21:37:58 +0000 Subject: [Freeipa-users] Sudo options In-Reply-To: <4F173888.2050804@gmail.com> References: <4F1721C8.1050203@gmail.com> <918E438C-971C-436B-941E-2A4AD55266C1@citrixonline.com> <4F173888.2050804@gmail.com> Message-ID: On Jan 18, 2012, at 1:24 PM, Erinn Looney-Triggs wrote: On 01/18/2012 11:50 AM, JR Aquino wrote: On Jan 18, 2012, at 11:47 AM, Erinn Looney-Triggs wrote: I can't really figure out what the proper syntax is for the sudo rules in IPA. I have a number of options that I would like included by default, I have put them in place, from ipa sudorule-show: Sudo Option: env_keep = "LESSSECURE", env_reset, mail_badpass, mail_no_host, mail_no_perms, syslog = local2 It looks to be getting confused by the whitespace. Remove the whitespace for env_keep = "LESSSECURE" & syslog = local2 to: env_keep="LESSSECURE" syslog=local2 Let me know if that helps. Also, can you post a compare against: ipa sudorule-show defaults vs $ sudo -l This doesn't appear to work, when sudo is run: sudo: unknown defaults entry `env_keep ' sudo: unknown defaults entry `mail_badpass, mail_no_host, mail_no_perms, syslog ' One thing that jumps out at me is that the '= whatever' portion is not being maintained. The directions in the IDM guide are less than clear, simply referencing the sudoers page for options. These are all valid sudo options, this is basically a straight port over from a sudoers file. So anyone have any experience doing this bit? -Erinn _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users It looks like this was actually ttwo problems, one the quoting, and the second that via the web ui, I had put multiple options on a single line separated by a comma, so initially one rule was: mail_badpass, mail_no_host, mail_no_perms, syslog = local2 After fixing the spacing issue, as well as putting each into it's own statement everything worked just fine. There should probably either be better documentation, or better validation of input for those options, or ideally both :). I reckon I will open a bug up. Thanks! I agree with you. Might even help to do some level of input validation as well. Thanks again! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jr Aquino, GCIH, GWAPT | Sr. Information Security Specialist Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 jr.aquino at citrixonline.com http://www.citrixonline.com [cid:image001.jpg at 01CB2FE6.2B7BFA80] Access Your PC or Mac From Anywhere: www.gotomypc.com Online Meetings Made Easy: www.gotomeeting.com Web Events Made Easy: www.gotowebinar.com Remote Support Made Easy: www.gotoassist.com Thanks for the help, -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3720 bytes Desc: image001.jpg URL: From shelltoesuperstar at gmail.com Thu Jan 19 13:18:56 2012 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Thu, 19 Jan 2012 13:18:56 +0000 Subject: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers In-Reply-To: <4F16E646.1000400@redhat.com> References: <1326856794.21682.70.camel@sgallagh520.sgallagh.bos.redhat.com> <4F16E646.1000400@redhat.com> Message-ID: Thanks for the advice Stephen (and the quick response), obviously that won't help with load balanced comms during the installation process but it should keep it to a minimum afterwards. Wouldn't a quick solution be the addition of a "--primary" flag to the ipa-client-install script? It could behave in the same way as the --server flag and be a substitute for it but it just forces all enrolment comms to be kept to the named server and reorders the ipa_server entry in sssd.conf from "ipa_server = __srv__, x.x.x.x" to "ipa_server = x.x.x.x, __srv__" Would that be enough? Regards Charlie On Wed, Jan 18, 2012 at 3:33 PM, Dmitri Pal wrote: > ** > On 01/17/2012 10:19 PM, Stephen Gallagher wrote: > > On Wed, 2012-01-18 at 03:02 +0000, Charlie Derwent wrote: > > Hi > > I've got 5 different IPA servers at 5 differents labs around the > country that are all replicas of one another. In order to keep the the > cross-site network traffic to a minimum I want the IPA clients at Site > "A" to only communicate to IPA Server "A", "B" to "B", "C" to "C" etc. > except in the case of the failure of one of the servers. > > I originally assumed that making the IPA client to connect to a > specific IPA server with "ipa-client-install --server=IPA_server_fqdn" > would suffice but I very quickly found out this wasn't the case with > the client going to multiple servers just to complete the installation > process. Then I found out about modifying the DNS SRV records priority > and weight however, please correct me if I'm wrong, these wouldn't > these changes replicate and be enacted gloablly. (i.e. all clients at > any site would prioritise IPA "A" over IPA "B"). > > Is there any way to get the functionality I desire? > > > We're looking at ways to implement a concept of client location into the > connection logic. At the moment, however, the only way to do this is > manually on the client. > > You can make the following change in the clients' /etc/sssd/sssd.conf > files: > > In the [domain/your.domain.com] section there is an option "ipa_server". > > By default, this is configured to be: > ipa_server = __srv__, x.x.x.x > > (Where x.x.x.x is the server you were originally talking to when you ran > ipa-client-install, as a backup in case DNS is not working). > > You can manually change this to be: > ipa_server = nearest.server.com, further.server.com,only-in-emergencies.server.com, ... > > With this manual setup, SSSD (the daemon that manages the client-side > portion) will always attempt to connect to nearest.server.com unless it > is unavailable, after which time it will fail over to the next in the > list, and so on.* > > > * If all of them are unavailable, SSSD switches to offline operation, > where it will try to reconnect every couple of minutes, but will serve > requests from its cache in the meantime. When it reconnects from an > offline state, it will start retrying from the first server in the list > (aka the nearest one). > > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > We are tracking this requirement with the following ticket: > https://fedorahosted.org/freeipa/ticket/122 > It is currently Deferred is we do not have time to look at it yet but any > help is always appreciated. > It seems that the page that the ticket is pointing actually changed since > we last looked at it. > May be based on the ideas expressed in this page the changes can be made > in IPA storage or LDAP driver without the need to touch BIND. If something > like this is possible it would be much easier to implement. But still we > have a full plate now and will for quite some time so help would be > definitely needed. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Thu Jan 19 13:29:45 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 19 Jan 2012 08:29:45 -0500 Subject: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers In-Reply-To: References: <1326856794.21682.70.camel@sgallagh520.sgallagh.bos.redhat.com> <4F16E646.1000400@redhat.com> Message-ID: <1326979785.2141.12.camel@sgallagh520.sgallagh.bos.redhat.com> On Thu, 2012-01-19 at 13:18 +0000, Charlie Derwent wrote: > Thanks for the advice Stephen (and the quick response), obviously that > won't help with load balanced comms during the installation process > but it should keep it to a minimum afterwards. > > Wouldn't a quick solution be the addition of a "--primary" flag to the > ipa-client-install script? It could behave in the same way as the > --server flag and be a substitute for it but it just forces all > enrolment comms to be kept to the named server and reorders the > ipa_server entry in sssd.conf from "ipa_server = __srv__, x.x.x.x" to > "ipa_server = x.x.x.x, __srv__" > > Would that be enough? That seems perfectly reasonable to me. Would you mind filing an RFE at https://fedorahosted.org/freeipa/ please? (If you don't have a Fedora account, you can get one for free at https://admin.fedoraproject.org/accounts) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From shelltoesuperstar at gmail.com Thu Jan 19 14:06:34 2012 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Thu, 19 Jan 2012 14:06:34 +0000 Subject: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers In-Reply-To: <1326979785.2141.12.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1326856794.21682.70.camel@sgallagh520.sgallagh.bos.redhat.com> <4F16E646.1000400@redhat.com> <1326979785.2141.12.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: https://fedorahosted.org/freeipa/ticket/22827 Done. On Thu, Jan 19, 2012 at 1:29 PM, Stephen Gallagher wrote: > On Thu, 2012-01-19 at 13:18 +0000, Charlie Derwent wrote: > > Thanks for the advice Stephen (and the quick response), obviously that > > won't help with load balanced comms during the installation process > > but it should keep it to a minimum afterwards. > > > > Wouldn't a quick solution be the addition of a "--primary" flag to the > > ipa-client-install script? It could behave in the same way as the > > --server flag and be a substitute for it but it just forces all > > enrolment comms to be kept to the named server and reorders the > > ipa_server entry in sssd.conf from "ipa_server = __srv__, x.x.x.x" to > > "ipa_server = x.x.x.x, __srv__" > > > > Would that be enough? > > > That seems perfectly reasonable to me. Would you mind filing an RFE at > https://fedorahosted.org/freeipa/ please? (If you don't have a Fedora > account, you can get one for free at > https://admin.fedoraproject.org/accounts) > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Thu Jan 19 15:33:08 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 19 Jan 2012 10:33:08 -0500 Subject: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers In-Reply-To: References: <1326856794.21682.70.camel@sgallagh520.sgallagh.bos.redhat.com> <4F16E646.1000400@redhat.com> <1326979785.2141.12.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <1326987188.2141.14.camel@sgallagh520.sgallagh.bos.redhat.com> On Thu, 2012-01-19 at 14:06 +0000, Charlie Derwent wrote: > https://fedorahosted.org/freeipa/ticket/22827 For the record, the correct link is https://fedorahosted.org/freeipa/ticket/2282 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From nsollars at gmail.com Thu Jan 19 18:44:17 2012 From: nsollars at gmail.com (Nigel Sollars) Date: Thu, 19 Jan 2012 13:44:17 -0500 Subject: [Freeipa-users] Post installation ( looks to be small issue ).. Message-ID: Hi all, After fixing upa number of things and successfully installing / testing the server install, I have a small issue with the UI inside firefox in that after importing the CA and looking at a few guides I notice these line in my http error logs: [Thu Jan 19 13:17:56 2012] [error] [client x.x.x.x] File does not exist: /usr/share/ipa/ui/develop.js, referer: https://ipaserver.jitscaleus.net/ipa/ui/ [Thu Jan 19 13:19:41 2012] [error] [client x.x.x.x] File does not exist: /usr/share/ipa/ui/develop.js, referer: https://ipaserver.jitscaleus.net/ipa/ui/ [Thu Jan 19 13:19:59 2012] [error] [client x.x.x.x] File does not exist: /usr/share/ipa/ui/develop.js, referer: https://ipaserver.jitscaleus.net/ipa/ui/ [Thu Jan 19 13:27:58 2012] [error] [client x.x.3.x] File does not exist: /usr/share/ipa/ui/develop.js, referer: https://ipaserver.jitscaleus.net/ipa/ui/ [Thu Jan 19 13:31:34 2012] [error] [client x.x.x.x] File does not exist: /usr/share/ipa/ui/develop.js, referer: https://ipaserver.jitscaleus.net/ipa/ui/ I ran through the trouble shooting guide with re-running kinit ( passing password ) then running, ldapsearch -Y GSSAPI -b "dc=domain,dc=com" uid=admin, which returned the correct response, The browser loops around the configuration from the server to return to the webui with the error of an invalid ticket. I am not 100% if this is relevant or not but the client install that was called after the ser install finalized, bombed completely with the folowing: Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 1292, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 1279, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 1117, in install fstore.backup_file("/etc/sssd/sssd.conf") File "/usr/lib/python2.6/site-packages/ipapython/sysrestore.py", line 126, in backup_file shutil.copy2(path, backup_path) File "/usr/lib64/python2.6/shutil.py", line 95, in copy2 copyfile(src, dst) File "/usr/lib64/python2.6/shutil.py", line 51, in copyfile with open(dst, 'wb') as fdst: IOError: [Errno 2] No such file or directory: '/var/lib/ipa-client/sysrestore/107a99f6a6514e30-sssd.conf' Hope this helps Nige -- ?Science is a differential equation. Religion is a boundary condition.? Alan Turing -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Markel at deem.com Thu Jan 19 18:20:59 2012 From: Robert.Markel at deem.com (Robert Markel) Date: Thu, 19 Jan 2012 18:20:59 +0000 Subject: [Freeipa-users] FreeIPA on CentOS 6.2 Message-ID: <2F5EA05F899E3141A4AE896FF73B337C079CF411@sccorpmail03.mygazoo.com> Is anyone on the list running FreeIPA on CentOS 6.2? I understand that RHEL 6.2 includes it and wanted to ensure that the CentOS version did not have any big surprises before embarking on an upgrade. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Jan 19 19:28:43 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Jan 2012 14:28:43 -0500 Subject: [Freeipa-users] Post installation ( looks to be small issue ).. In-Reply-To: References: Message-ID: <4F186EEB.8040004@redhat.com> Nigel Sollars wrote: > Hi all, > > After fixing upa number of things and successfully installing / testing > the server install, I have a small issue with the UI inside firefox in > that after importing the CA and looking at a few guides I notice these > line in my http error logs: What things did you fix up? > > [Thu Jan 19 13:17:56 2012] [error] [client x.x.x.x] File does not exist: > /usr/share/ipa/ui/develop.js, referer: > https://ipaserver.jitscaleus.net/ipa/ui/ > [Thu Jan 19 13:19:41 2012] [error] [client x.x.x.x] File does not exist: > /usr/share/ipa/ui/develop.js, referer: > https://ipaserver.jitscaleus.net/ipa/ui/ > [Thu Jan 19 13:19:59 2012] [error] [client x.x.x.x] File does not exist: > /usr/share/ipa/ui/develop.js, referer: > https://ipaserver.jitscaleus.net/ipa/ui/ > [Thu Jan 19 13:27:58 2012] [error] [client x.x.3.x] File does not exist: > /usr/share/ipa/ui/develop.js, referer: > https://ipaserver.jitscaleus.net/ipa/ui/ > [Thu Jan 19 13:31:34 2012] [error] [client x.x.x.x] File does not exist: > /usr/share/ipa/ui/develop.js, referer: > https://ipaserver.jitscaleus.net/ipa/ui/ I think this can be ignored, I believe the code is just used for testing/developing (and isn't used at all in newer builds). > I ran through the trouble shooting guide with re-running kinit ( passing > password ) then running, ldapsearch -Y GSSAPI -b "dc=domain,dc=com" > uid=admin, which returned the correct response, > > The browser loops around the configuration from the server to return to > the webui with the error of an invalid ticket. Did you configure the browser to do negotiate authentication (or use the configure firefox button)? > I am not 100% if this is relevant or not but the client install that was > called after the ser install finalized, bombed completely with the folowing: > > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 1292, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 1279, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 1117, in install > fstore.backup_file("/etc/sssd/sssd.conf") > File "/usr/lib/python2.6/site-packages/ipapython/sysrestore.py", line > 126, in backup_file > shutil.copy2(path, backup_path) > File "/usr/lib64/python2.6/shutil.py", line 95, in copy2 > copyfile(src, dst) > File "/usr/lib64/python2.6/shutil.py", line 51, in copyfile > with open(dst, 'wb') as fdst: > IOError: [Errno 2] No such file or directory: > '/var/lib/ipa-client/sysrestore/107a99f6a6514e30-sssd.conf' Strange. Does /var/lib/ipa-client/sysrestore exist? rob From g17jimmy at gmail.com Thu Jan 19 21:59:53 2012 From: g17jimmy at gmail.com (Jimmy) Date: Thu, 19 Jan 2012 16:59:53 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F0DF1C3.2020506@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> Message-ID: ok. I started from scratch this week on this and I think I've got the right doc and understand better where this is going. My problem now is that when configuring SSL on the AD server (step c in this url: http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) I get this error: certreq -submit request.req certnew.cer Active Directory Enrollment Policy {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} ldap: RequestId: 3 RequestId: "3" Certificate not issued (Denied) Denied by Policy Module 0x80094801, The request does not contain a certificate template extension or the CertificateTemplate request attribute. The request contains no certificate template information. 0x80094801 (-2146875391) Certificate Request Processor: The request contains no certificate template information. 0x80094801 (-2146875391) Denied by Policy Module 0x80094801, The request does not contain a certificate template extension or the CertificateTemplate request attribute. The RH doc says to use the browser if an error occurs and IIS is running but I'm not running IIS. I researched that error but didn't find anything that helps with FreeIPA and passsync. Jimmy On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson wrote: > ** > On 01/11/2012 11:22 AM, Jimmy wrote: > > We need to be able to replicate user/pass between Windows 2008 AD and > FreeIPA. > > > That's what IPA Windows Sync is supposed to do. > > > I have followed many different documents and posted here about it and from > what I've read and procedures I've followed we are unable to accomplish > this. > > > What have you tried, and what problems have you run into? > > It doesn't need to be a full trust. > > Thanks > > On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: > >> > Just wondering if there was anyone listening on the list that might be >> > available for little work integrating FreeIPA with Active Directory >> > (preferrably in the south east US.) I hope this isn't against the list >> > rules, I just thought one of you guys could help or point me in the >> right >> > direction. >> >> If you want some help, it is certainly not against list rules ;-) But >> in that >> case, it would be much better if you asked what exactly do you need. >> >> I'm not an AD expert, but a couple tips: If you are looking for >> cross-domain >> (cross-realm) trust, then you might be a bit disappointed, it is still in >> development, so it probably won't be 100% functional at this moment. >> >> If you are looking for something else, could you be a little more >> specific what >> it is? >> >> I also recommend starting with reading some doc: >> http://freeipa.org/page/DocumentationPortal >> >> Thanks >> Jan >> > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Jan 19 22:04:11 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 19 Jan 2012 15:04:11 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> Message-ID: <4F18935B.6000803@redhat.com> On 01/19/2012 02:59 PM, Jimmy wrote: > ok. I started from scratch this week on this and I think I've got the > right doc and understand better where this is going. My problem now is > that when configuring SSL on the AD server (step c in this url: > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) > > I get this error: > > certreq -submit request.req certnew.cer > Active Directory Enrollment Policy > {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} > ldap: > RequestId: 3 > RequestId: "3" > Certificate not issued (Denied) Denied by Policy Module 0x80094801, > The request does not contain a certificate template extension or the > CertificateTemplate request attribute. > The request contains no certificate template information. 0x80094801 > (-2146875391 ) > Certificate Request Processor: The request contains no certificate > template information. 0x80094801 (-2146875391 ) > Denied by Policy Module 0x80094801, The request does not contain a > certificate template extension or the CertificateTemplate request > attribute. > > The RH doc says to use the browser if an error occurs and IIS is > running but I'm not running IIS. I researched that error but didn't > find anything that helps with FreeIPA and passsync. Hmm - try installing Microsoft Certificate Authority in Enterprise Root CA mode - it will usually automatically create and install the AD server cert. http://directory.fedoraproject.org/wiki/Howto:WindowsSync > > Jimmy > > On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson > wrote: > > On 01/11/2012 11:22 AM, Jimmy wrote: >> We need to be able to replicate user/pass between Windows 2008 AD >> and FreeIPA. > > That's what IPA Windows Sync is supposed to do. > > >> I have followed many different documents and posted here about it >> and from what I've read and procedures I've followed we are >> unable to accomplish this. > > What have you tried, and what problems have you run into? > >> It doesn't need to be a full trust. >> >> Thanks >> >> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? > > wrote: >> >> > Just wondering if there was anyone listening on the list >> that might be >> > available for little work integrating FreeIPA with Active >> Directory >> > (preferrably in the south east US.) I hope this isn't >> against the list >> > rules, I just thought one of you guys could help or point >> me in the right >> > direction. >> >> If you want some help, it is certainly not against list rules >> ;-) But in that >> case, it would be much better if you asked what exactly do >> you need. >> >> I'm not an AD expert, but a couple tips: If you are looking >> for cross-domain >> (cross-realm) trust, then you might be a bit disappointed, it >> is still in >> development, so it probably won't be 100% functional at this >> moment. >> >> If you are looking for something else, could you be a little >> more specific what >> it is? >> >> I also recommend starting with reading some doc: >> http://freeipa.org/page/DocumentationPortal >> >> Thanks >> Jan >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Fri Jan 20 09:39:22 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 20 Jan 2012 10:39:22 +0100 (CET) Subject: [Freeipa-users] RHEL 6.2 IPA and automember Message-ID: <27252.213.225.75.97.1327052362.squirrel@www.nixtra.com> Hi, What happened to the automember functionality in the IPA shipped with RHEL 6.2? I no longer have the option to create or modify automember configuration. This was working fine in the release shipped with RHEL 6.2 beta. # ipa automember ipa: ERROR: unknown command 'automember' Regards, Siggi From rcritten at redhat.com Fri Jan 20 14:45:03 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Jan 2012 09:45:03 -0500 Subject: [Freeipa-users] RHEL 6.2 IPA and automember In-Reply-To: <27252.213.225.75.97.1327052362.squirrel@www.nixtra.com> References: <27252.213.225.75.97.1327052362.squirrel@www.nixtra.com> Message-ID: <4F197DEF.308@redhat.com> Sigbjorn Lie wrote: > Hi, > > What happened to the automember functionality in the IPA shipped with RHEL 6.2? > > I no longer have the option to create or modify automember configuration. This was working fine in > the release shipped with RHEL 6.2 beta. > > # ipa automember > ipa: ERROR: unknown command 'automember' It was removed from the final release because it had not been fully verified by QE. rob From sigbjorn at nixtra.com Fri Jan 20 16:24:18 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 20 Jan 2012 17:24:18 +0100 Subject: [Freeipa-users] RHEL 6.2 IPA and automember In-Reply-To: <4F197DEF.308@redhat.com> References: <27252.213.225.75.97.1327052362.squirrel@www.nixtra.com> <4F197DEF.308@redhat.com> Message-ID: <4F199532.4090800@nixtra.com> On 01/20/2012 03:45 PM, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> Hi, >> >> What happened to the automember functionality in the IPA shipped with >> RHEL 6.2? >> >> I no longer have the option to create or modify automember >> configuration. This was working fine in >> the release shipped with RHEL 6.2 beta. >> >> # ipa automember >> ipa: ERROR: unknown command 'automember' > > It was removed from the final release because it had not been fully > verified by QE. :( When can it be expected to be back in RHEL? Regards, Siggi From sigbjorn at nixtra.com Fri Jan 20 16:35:44 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 20 Jan 2012 17:35:44 +0100 Subject: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers In-Reply-To: <1326987188.2141.14.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1326856794.21682.70.camel@sgallagh520.sgallagh.bos.redhat.com> <4F16E646.1000400@redhat.com> <1326979785.2141.12.camel@sgallagh520.sgallagh.bos.redhat.com> <1326987188.2141.14.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4F1997E0.4070106@nixtra.com> On 01/19/2012 04:33 PM, Stephen Gallagher wrote: > On Thu, 2012-01-19 at 14:06 +0000, Charlie Derwent wrote: >> https://fedorahosted.org/freeipa/ticket/22827 > For the record, the correct link is > https://fedorahosted.org/freeipa/ticket/2282 > > The Solaris LDAP client has a property called servers, and a property called preferred servers. As the name implies, all the preferred servers will be used before using the rest of the servers in the servers property for that client. Perhaps this would be a good idea to implement in SSSD too? Regards, Siggi From nsollars at gmail.com Fri Jan 20 16:50:06 2012 From: nsollars at gmail.com (Nigel Sollars) Date: Fri, 20 Jan 2012 11:50:06 -0500 Subject: [Freeipa-users] Post installation ( looks to be small issue ).. In-Reply-To: References: <4F186EEB.8040004@redhat.com> Message-ID: HI, So is the failure of the client an issue, as in I need to run it again?. I still cant get the local firefox to authenticate. Regards Nige On Thu, Jan 19, 2012 at 2:34 PM, Nigel Sollars wrote: > > > On Thu, Jan 19, 2012 at 2:28 PM, Rob Crittenden wrote: > >> Nigel Sollars wrote: >> >>> Hi all, >>> >>> After fixing upa number of things and successfully installing / testing >>> the server install, I have a small issue with the UI inside firefox in >>> that after importing the CA and looking at a few guides I notice these >>> line in my http error logs: >>> >> >> What things did you fix up? > > > > Just permissions on /dev/shm and /var/tmp > > >> >> >> >>> [Thu Jan 19 13:17:56 2012] [error] [client x.x.x.x] File does not exist: >>> /usr/share/ipa/ui/develop.js, referer: >>> https://ipaserver.jitscaleus.**net/ipa/ui/ >>> [Thu Jan 19 13:19:41 2012] [error] [client x.x.x.x] File does not exist: >>> /usr/share/ipa/ui/develop.js, referer: >>> https://ipaserver.jitscaleus.**net/ipa/ui/ >>> [Thu Jan 19 13:19:59 2012] [error] [client x.x.x.x] File does not exist: >>> /usr/share/ipa/ui/develop.js, referer: >>> https://ipaserver.jitscaleus.**net/ipa/ui/ >>> [Thu Jan 19 13:27:58 2012] [error] [client x.x.3.x] File does not exist: >>> /usr/share/ipa/ui/develop.js, referer: >>> https://ipaserver.jitscaleus.**net/ipa/ui/ >>> [Thu Jan 19 13:31:34 2012] [error] [client x.x.x.x] File does not exist: >>> /usr/share/ipa/ui/develop.js, referer: >>> https://ipaserver.jitscaleus.**net/ipa/ui/ >>> >> >> I think this can be ignored, I believe the code is just used for >> testing/developing (and isn't used at all in newer builds). >> >> >> > > Ok cool > > > >> I ran through the trouble shooting guide with re-running kinit ( passing >>> password ) then running, ldapsearch -Y GSSAPI -b "dc=domain,dc=com" >>> uid=admin, which returned the correct response, >>> >>> The browser loops around the configuration from the server to return to >>> the webui with the error of an invalid ticket. >>> >> >> Did you configure the browser to do negotiate authentication (or use the >> configure firefox button)? >> >> >> > Via the button, the CA is there about:config shows the correct network > options there also. > > > >> I am not 100% if this is relevant or not but the client install that was >>> called after the ser install finalized, bombed completely with the >>> folowing: >>> >>> Traceback (most recent call last): >>> File "/usr/sbin/ipa-client-install"**, line 1292, in >>> sys.exit(main()) >>> File "/usr/sbin/ipa-client-install"**, line 1279, in main >>> rval = install(options, env, fstore, statestore) >>> File "/usr/sbin/ipa-client-install"**, line 1117, in install >>> fstore.backup_file("/etc/sssd/**sssd.conf") >>> File "/usr/lib/python2.6/site-**packages/ipapython/sysrestore.**py", >>> line >>> 126, in backup_file >>> shutil.copy2(path, backup_path) >>> File "/usr/lib64/python2.6/shutil.**py", line 95, in copy2 >>> copyfile(src, dst) >>> File "/usr/lib64/python2.6/shutil.**py", line 51, in copyfile >>> with open(dst, 'wb') as fdst: >>> IOError: [Errno 2] No such file or directory: >>> '/var/lib/ipa-client/**sysrestore/107a99f6a6514e30-**sssd.conf' >>> >> >> Strange. Does /var/lib/ipa-client/sysrestore exist? >> >> > No that one is not there > > > >> rob >> > > > > -- > ?Science is a differential equation. Religion is a boundary condition.? > > Alan Turing > > -- ?Science is a differential equation. Religion is a boundary condition.? Alan Turing -------------- next part -------------- An HTML attachment was scrubbed... URL: From g17jimmy at gmail.com Fri Jan 20 17:23:25 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 20 Jan 2012 12:23:25 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F18935B.6000803@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> Message-ID: You are correct. I had installed as an Enterprise root, but the doc I was reading(original link) seemed to say that I had to do the certreq manually, my bad. I think I'm getting closer I can establish an openssl connection from DS to AD but I get these errors: openssl s_client -connect 192.168.201.150:636 -showcerts -CAfile dsca.crt CONNECTED(00000003) depth=0 CN = csp-ad.cspad.pdh.csp verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = csp-ad.cspad.pdh.csp verify error:num=27:certificate not trusted verify return:1 depth=0 CN = csp-ad.cspad.pdh.csp verify error:num=21:unable to verify the first certificate verify return:1 I thought I had imported the cert from AD but it doesn't seem so. I'm still researching but if you guys have a suggestion let me know. -J On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson wrote: > ** > On 01/19/2012 02:59 PM, Jimmy wrote: > > ok. I started from scratch this week on this and I think I've got the > right doc and understand better where this is going. My problem now is that > when configuring SSL on the AD server (step c in this url: > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) > > I get this error: > > certreq -submit request.req certnew.cer > Active Directory Enrollment Policy > {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} > ldap: > RequestId: 3 > RequestId: "3" > Certificate not issued (Denied) Denied by Policy Module 0x80094801, The > request does not contain a certificate template extension or the > CertificateTemplate request attribute. > The request contains no certificate template information. 0x80094801 > (-2146875391) > Certificate Request Processor: The request contains no certificate > template information. 0x80094801 (-2146875391) > Denied by Policy Module 0x80094801, The request does not contain a > certificate template extension or the CertificateTemplate request attribute. > > The RH doc says to use the browser if an error occurs and IIS is running > but I'm not running IIS. I researched that error but didn't find anything > that helps with FreeIPA and passsync. > > Hmm - try installing Microsoft Certificate Authority in Enterprise Root CA > mode - it will usually automatically create and install the AD server > cert. http://directory.fedoraproject.org/wiki/Howto:WindowsSync > > > Jimmy > > On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson wrote: > >> On 01/11/2012 11:22 AM, Jimmy wrote: >> >> We need to be able to replicate user/pass between Windows 2008 AD and >> FreeIPA. >> >> >> That's what IPA Windows Sync is supposed to do. >> >> >> I have followed many different documents and posted here about it and >> from what I've read and procedures I've followed we are unable to >> accomplish this. >> >> >> What have you tried, and what problems have you run into? >> >> It doesn't need to be a full trust. >> >> Thanks >> >> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: >> >>> > Just wondering if there was anyone listening on the list that might >>> be >>> > available for little work integrating FreeIPA with Active Directory >>> > (preferrably in the south east US.) I hope this isn't against the list >>> > rules, I just thought one of you guys could help or point me in the >>> right >>> > direction. >>> >>> If you want some help, it is certainly not against list rules ;-) But >>> in that >>> case, it would be much better if you asked what exactly do you need. >>> >>> I'm not an AD expert, but a couple tips: If you are looking for >>> cross-domain >>> (cross-realm) trust, then you might be a bit disappointed, it is still in >>> development, so it probably won't be 100% functional at this moment. >>> >>> If you are looking for something else, could you be a little more >>> specific what >>> it is? >>> >>> I also recommend starting with reading some doc: >>> http://freeipa.org/page/DocumentationPortal >>> >>> Thanks >>> Jan >>> >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Jan 20 17:23:44 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 20 Jan 2012 10:23:44 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> Message-ID: <4F19A320.8080501@redhat.com> On 01/20/2012 10:23 AM, Jimmy wrote: > You are correct. I had installed as an Enterprise root, but the doc I > was reading(original link) seemed to say that I had to do the certreq > manually, my bad. I think I'm getting closer I can establish an > openssl connection from DS to AD but I get these errors: > > openssl s_client -connect 192.168.201.150:636 > -showcerts -CAfile dsca.crt > CONNECTED(00000003) > depth=0 CN = csp-ad.cspad.pdh.csp > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 CN = csp-ad.cspad.pdh.csp > verify error:num=27:certificate not trusted > verify return:1 > depth=0 CN = csp-ad.cspad.pdh.csp > verify error:num=21:unable to verify the first certificate > verify return:1 > > I thought I had imported the cert from AD but it doesn't seem so. I'm > still researching but if you guys have a suggestion let me know. Is dsca.crt the CA that issued the DS server cert? If so, that won't work. You need the CA cert from the CA that issued the AD server cert (i.e. the CA cert from the MS Enterprise Root CA). > -J > > On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson > wrote: > > On 01/19/2012 02:59 PM, Jimmy wrote: >> ok. I started from scratch this week on this and I think I've got >> the right doc and understand better where this is going. My >> problem now is that when configuring SSL on the AD server (step c >> in this url: >> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >> >> I get this error: >> >> certreq -submit request.req certnew.cer >> Active Directory Enrollment Policy >> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >> ldap: >> RequestId: 3 >> RequestId: "3" >> Certificate not issued (Denied) Denied by Policy Module >> 0x80094801, The request does not contain a certificate template >> extension or the CertificateTemplate request attribute. >> The request contains no certificate template information. >> 0x80094801 (-2146875391 ) >> Certificate Request Processor: The request contains no >> certificate template information. 0x80094801 (-2146875391 >> ) >> Denied by Policy Module 0x80094801, The request does not contain >> a certificate template extension or the CertificateTemplate >> request attribute. >> >> The RH doc says to use the browser if an error occurs and IIS is >> running but I'm not running IIS. I researched that error but >> didn't find anything that helps with FreeIPA and passsync. > Hmm - try installing Microsoft Certificate Authority in Enterprise > Root CA mode - it will usually automatically create and install > the AD server cert. > http://directory.fedoraproject.org/wiki/Howto:WindowsSync > >> >> Jimmy >> >> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson >> > wrote: >> >> On 01/11/2012 11:22 AM, Jimmy wrote: >>> We need to be able to replicate user/pass between Windows >>> 2008 AD and FreeIPA. >> >> That's what IPA Windows Sync is supposed to do. >> >> >>> I have followed many different documents and posted here >>> about it and from what I've read and procedures I've >>> followed we are unable to accomplish this. >> >> What have you tried, and what problems have you run into? >> >>> It doesn't need to be a full trust. >>> >>> Thanks >>> >>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? >>> > wrote: >>> >>> > Just wondering if there was anyone listening on the >>> list that might be >>> > available for little work integrating FreeIPA with >>> Active Directory >>> > (preferrably in the south east US.) I hope this isn't >>> against the list >>> > rules, I just thought one of you guys could help or >>> point me in the right >>> > direction. >>> >>> If you want some help, it is certainly not against list >>> rules ;-) But in that >>> case, it would be much better if you asked what exactly >>> do you need. >>> >>> I'm not an AD expert, but a couple tips: If you are >>> looking for cross-domain >>> (cross-realm) trust, then you might be a bit >>> disappointed, it is still in >>> development, so it probably won't be 100% functional at >>> this moment. >>> >>> If you are looking for something else, could you be a >>> little more specific what >>> it is? >>> >>> I also recommend starting with reading some doc: >>> http://freeipa.org/page/DocumentationPortal >>> >>> Thanks >>> Jan >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Fri Jan 20 17:33:42 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 20 Jan 2012 12:33:42 -0500 Subject: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers In-Reply-To: <4F1997E0.4070106@nixtra.com> References: <1326856794.21682.70.camel@sgallagh520.sgallagh.bos.redhat.com> <4F16E646.1000400@redhat.com> <1326979785.2141.12.camel@sgallagh520.sgallagh.bos.redhat.com> <1326987188.2141.14.camel@sgallagh520.sgallagh.bos.redhat.com> <4F1997E0.4070106@nixtra.com> Message-ID: <1327080822.2250.55.camel@sgallagh520.sgallagh.bos.redhat.com> On Fri, 2012-01-20 at 17:35 +0100, Sigbjorn Lie wrote: > On 01/19/2012 04:33 PM, Stephen Gallagher wrote: > > On Thu, 2012-01-19 at 14:06 +0000, Charlie Derwent wrote: > >> https://fedorahosted.org/freeipa/ticket/22827 > > For the record, the correct link is > > https://fedorahosted.org/freeipa/ticket/2282 > > > > > > The Solaris LDAP client has a property called servers, and a property > called preferred servers. As the name implies, all the preferred servers > will be used before using the rest of the servers in the servers > property for that client. > > Perhaps this would be a good idea to implement in SSSD too? https://fedorahosted.org/sssd/ticket/1128 Currently scheduled for SSSD 1.9.0 (end of May) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sigbjorn at nixtra.com Fri Jan 20 17:41:18 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 20 Jan 2012 18:41:18 +0100 Subject: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers In-Reply-To: <1327080822.2250.55.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1326856794.21682.70.camel@sgallagh520.sgallagh.bos.redhat.com> <4F16E646.1000400@redhat.com> <1326979785.2141.12.camel@sgallagh520.sgallagh.bos.redhat.com> <1326987188.2141.14.camel@sgallagh520.sgallagh.bos.redhat.com> <4F1997E0.4070106@nixtra.com> <1327080822.2250.55.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4F19A73E.5090101@nixtra.com> On 01/20/2012 06:33 PM, Stephen Gallagher wrote: > On Fri, 2012-01-20 at 17:35 +0100, Sigbjorn Lie wrote: >> On 01/19/2012 04:33 PM, Stephen Gallagher wrote: >>> On Thu, 2012-01-19 at 14:06 +0000, Charlie Derwent wrote: >>>> https://fedorahosted.org/freeipa/ticket/22827 >>> For the record, the correct link is >>> https://fedorahosted.org/freeipa/ticket/2282 >>> >>> >> The Solaris LDAP client has a property called servers, and a property >> called preferred servers. As the name implies, all the preferred servers >> will be used before using the rest of the servers in the servers >> property for that client. >> >> Perhaps this would be a good idea to implement in SSSD too? > https://fedorahosted.org/sssd/ticket/1128 > > Currently scheduled for SSSD 1.9.0 (end of May) > Excellent! :) In the ticket is mentioned "server", a single server. Will this feature be implemented of a single primary server, or a group of primary/preferred servers? Regards, Siggi From dpal at redhat.com Fri Jan 20 17:49:22 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Jan 2012 12:49:22 -0500 Subject: [Freeipa-users] RHEL 6.2 IPA and automember In-Reply-To: <4F199532.4090800@nixtra.com> References: <27252.213.225.75.97.1327052362.squirrel@www.nixtra.com> <4F197DEF.308@redhat.com> <4F199532.4090800@nixtra.com> Message-ID: <4F19A922.1000503@redhat.com> On 01/20/2012 11:24 AM, Sigbjorn Lie wrote: > On 01/20/2012 03:45 PM, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >>> Hi, >>> >>> What happened to the automember functionality in the IPA shipped >>> with RHEL 6.2? >>> >>> I no longer have the option to create or modify automember >>> configuration. This was working fine in >>> the release shipped with RHEL 6.2 beta. >>> >>> # ipa automember >>> ipa: ERROR: unknown command 'automember' >> >> It was removed from the final release because it had not been fully >> verified by QE. > > :( > > When can it be expected to be back in RHEL? > In 6.3 > > Regards, > Siggi > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sgallagh at redhat.com Fri Jan 20 17:51:23 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 20 Jan 2012 12:51:23 -0500 Subject: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers In-Reply-To: <4F19A73E.5090101@nixtra.com> References: <1326856794.21682.70.camel@sgallagh520.sgallagh.bos.redhat.com> <4F16E646.1000400@redhat.com> <1326979785.2141.12.camel@sgallagh520.sgallagh.bos.redhat.com> <1326987188.2141.14.camel@sgallagh520.sgallagh.bos.redhat.com> <4F1997E0.4070106@nixtra.com> <1327080822.2250.55.camel@sgallagh520.sgallagh.bos.redhat.com> <4F19A73E.5090101@nixtra.com> Message-ID: <1327081883.2250.56.camel@sgallagh520.sgallagh.bos.redhat.com> On Fri, 2012-01-20 at 18:41 +0100, Sigbjorn Lie wrote: > On 01/20/2012 06:33 PM, Stephen Gallagher wrote: > > On Fri, 2012-01-20 at 17:35 +0100, Sigbjorn Lie wrote: > >> On 01/19/2012 04:33 PM, Stephen Gallagher wrote: > >>> On Thu, 2012-01-19 at 14:06 +0000, Charlie Derwent wrote: > >>>> https://fedorahosted.org/freeipa/ticket/22827 > >>> For the record, the correct link is > >>> https://fedorahosted.org/freeipa/ticket/2282 > >>> > >>> > >> The Solaris LDAP client has a property called servers, and a property > >> called preferred servers. As the name implies, all the preferred servers > >> will be used before using the rest of the servers in the servers > >> property for that client. > >> > >> Perhaps this would be a good idea to implement in SSSD too? > > https://fedorahosted.org/sssd/ticket/1128 > > > > Currently scheduled for SSSD 1.9.0 (end of May) > > > Excellent! :) > > In the ticket is mentioned "server", a single server. Will this feature > be implemented of a single primary server, or a group of > primary/preferred servers? > The original intent was to handle switching back over to the primary server when failover caused an error. However, please add your request to that ticket and it'll be evaluated there. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From g17jimmy at gmail.com Fri Jan 20 19:46:12 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 20 Jan 2012 14:46:12 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F19A320.8080501@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> Message-ID: Getting close here... Now I see this message in the sync log file: attempting to sync password for testuser searching for (ntuserdomainid=testuser) ldap error in queryusername 32: no such object deferring password change for testuser On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson wrote: > ** > On 01/20/2012 10:23 AM, Jimmy wrote: > > You are correct. I had installed as an Enterprise root, but the doc I was > reading(original link) seemed to say that I had to do the certreq manually, > my bad. I think I'm getting closer I can establish an openssl connection > from DS to AD but I get these errors: > > openssl s_client -connect 192.168.201.150:636 -showcerts -CAfile > dsca.crt > CONNECTED(00000003) > depth=0 CN = csp-ad.cspad.pdh.csp > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 CN = csp-ad.cspad.pdh.csp > verify error:num=27:certificate not trusted > verify return:1 > depth=0 CN = csp-ad.cspad.pdh.csp > verify error:num=21:unable to verify the first certificate > verify return:1 > > I thought I had imported the cert from AD but it doesn't seem so. I'm > still researching but if you guys have a suggestion let me know. > > Is dsca.crt the CA that issued the DS server cert? If so, that won't > work. You need the CA cert from the CA that issued the AD server cert > (i.e. the CA cert from the MS Enterprise Root CA). > > -J > > On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson wrote: > >> On 01/19/2012 02:59 PM, Jimmy wrote: >> >> ok. I started from scratch this week on this and I think I've got the >> right doc and understand better where this is going. My problem now is that >> when configuring SSL on the AD server (step c in this url: >> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >> >> I get this error: >> >> certreq -submit request.req certnew.cer >> Active Directory Enrollment Policy >> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >> ldap: >> RequestId: 3 >> RequestId: "3" >> Certificate not issued (Denied) Denied by Policy Module 0x80094801, The >> request does not contain a certificate template extension or the >> CertificateTemplate request attribute. >> The request contains no certificate template information. 0x80094801 >> (-2146875391) >> Certificate Request Processor: The request contains no certificate >> template information. 0x80094801 (-2146875391) >> Denied by Policy Module 0x80094801, The request does not contain a >> certificate template extension or the CertificateTemplate request attribute. >> >> The RH doc says to use the browser if an error occurs and IIS is >> running but I'm not running IIS. I researched that error but didn't find >> anything that helps with FreeIPA and passsync. >> >> Hmm - try installing Microsoft Certificate Authority in Enterprise Root >> CA mode - it will usually automatically create and install the AD server >> cert. http://directory.fedoraproject.org/wiki/Howto:WindowsSync >> >> >> Jimmy >> >> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson wrote: >> >>> On 01/11/2012 11:22 AM, Jimmy wrote: >>> >>> We need to be able to replicate user/pass between Windows 2008 AD and >>> FreeIPA. >>> >>> >>> That's what IPA Windows Sync is supposed to do. >>> >>> >>> I have followed many different documents and posted here about it and >>> from what I've read and procedures I've followed we are unable to >>> accomplish this. >>> >>> >>> What have you tried, and what problems have you run into? >>> >>> It doesn't need to be a full trust. >>> >>> Thanks >>> >>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: >>> >>>> > Just wondering if there was anyone listening on the list that might >>>> be >>>> > available for little work integrating FreeIPA with Active Directory >>>> > (preferrably in the south east US.) I hope this isn't against the list >>>> > rules, I just thought one of you guys could help or point me in the >>>> right >>>> > direction. >>>> >>>> If you want some help, it is certainly not against list rules ;-) But >>>> in that >>>> case, it would be much better if you asked what exactly do you need. >>>> >>>> I'm not an AD expert, but a couple tips: If you are looking for >>>> cross-domain >>>> (cross-realm) trust, then you might be a bit disappointed, it is still >>>> in >>>> development, so it probably won't be 100% functional at this moment. >>>> >>>> If you are looking for something else, could you be a little more >>>> specific what >>>> it is? >>>> >>>> I also recommend starting with reading some doc: >>>> http://freeipa.org/page/DocumentationPortal >>>> >>>> Thanks >>>> Jan >>>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Jan 20 19:46:33 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 20 Jan 2012 12:46:33 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> Message-ID: <4F19C499.5090803@redhat.com> On 01/20/2012 12:46 PM, Jimmy wrote: > Getting close here... Now I see this message in the sync log file: > > attempting to sync password for testuser > searching for (ntuserdomainid=testuser) > ldap error in queryusername > 32: no such object > deferring password change for testuser This usually means the search base is incorrect or not found. You can look at the 389 access log to see what it was using as the search criteria. > > On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson > wrote: > > On 01/20/2012 10:23 AM, Jimmy wrote: >> You are correct. I had installed as an Enterprise root, but the >> doc I was reading(original link) seemed to say that I had to do >> the certreq manually, my bad. I think I'm getting closer I can >> establish an openssl connection from DS to AD but I get these >> errors: >> >> openssl s_client -connect 192.168.201.150:636 >> -showcerts -CAfile dsca.crt >> CONNECTED(00000003) >> depth=0 CN = csp-ad.cspad.pdh.csp >> verify error:num=20:unable to get local issuer certificate >> verify return:1 >> depth=0 CN = csp-ad.cspad.pdh.csp >> verify error:num=27:certificate not trusted >> verify return:1 >> depth=0 CN = csp-ad.cspad.pdh.csp >> verify error:num=21:unable to verify the first certificate >> verify return:1 >> >> I thought I had imported the cert from AD but it doesn't seem so. >> I'm still researching but if you guys have a suggestion let me know. > Is dsca.crt the CA that issued the DS server cert? If so, that > won't work. You need the CA cert from the CA that issued the AD > server cert (i.e. the CA cert from the MS Enterprise Root CA). > >> -J >> >> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson >> > wrote: >> >> On 01/19/2012 02:59 PM, Jimmy wrote: >>> ok. I started from scratch this week on this and I think >>> I've got the right doc and understand better where this is >>> going. My problem now is that when configuring SSL on the AD >>> server (step c in this url: >>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>> >>> I get this error: >>> >>> certreq -submit request.req certnew.cer >>> Active Directory Enrollment Policy >>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>> ldap: >>> RequestId: 3 >>> RequestId: "3" >>> Certificate not issued (Denied) Denied by Policy Module >>> 0x80094801, The request does not contain a certificate >>> template extension or the CertificateTemplate request attribute. >>> The request contains no certificate template information. >>> 0x80094801 (-2146875391 ) >>> Certificate Request Processor: The request contains no >>> certificate template information. 0x80094801 (-2146875391 >>> ) >>> Denied by Policy Module 0x80094801, The request does not >>> contain a certificate template extension or the >>> CertificateTemplate request attribute. >>> >>> The RH doc says to use the browser if an error occurs and >>> IIS is running but I'm not running IIS. I researched that >>> error but didn't find anything that helps with FreeIPA and >>> passsync. >> Hmm - try installing Microsoft Certificate Authority in >> Enterprise Root CA mode - it will usually automatically >> create and install the AD server cert. >> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >> >>> >>> Jimmy >>> >>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson >>> > wrote: >>> >>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>> We need to be able to replicate user/pass between >>>> Windows 2008 AD and FreeIPA. >>> >>> That's what IPA Windows Sync is supposed to do. >>> >>> >>>> I have followed many different documents and posted >>>> here about it and from what I've read and procedures >>>> I've followed we are unable to accomplish this. >>> >>> What have you tried, and what problems have you run into? >>> >>>> It doesn't need to be a full trust. >>>> >>>> Thanks >>>> >>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? >>>> > wrote: >>>> >>>> > Just wondering if there was anyone listening on >>>> the list that might be >>>> > available for little work integrating FreeIPA >>>> with Active Directory >>>> > (preferrably in the south east US.) I hope this >>>> isn't against the list >>>> > rules, I just thought one of you guys could help >>>> or point me in the right >>>> > direction. >>>> >>>> If you want some help, it is certainly not against >>>> list rules ;-) But in that >>>> case, it would be much better if you asked what >>>> exactly do you need. >>>> >>>> I'm not an AD expert, but a couple tips: If you are >>>> looking for cross-domain >>>> (cross-realm) trust, then you might be a bit >>>> disappointed, it is still in >>>> development, so it probably won't be 100% >>>> functional at this moment. >>>> >>>> If you are looking for something else, could you be >>>> a little more specific what >>>> it is? >>>> >>>> I also recommend starting with reading some doc: >>>> http://freeipa.org/page/DocumentationPortal >>>> >>>> Thanks >>>> Jan >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g17jimmy at gmail.com Fri Jan 20 20:08:35 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 20 Jan 2012 15:08:35 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F19C499.5090803@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> Message-ID: That was it! I have passwords syncing, *BUT*(at the risk of sounding stupid)-- is it not possible to also sync(add) the users from AD to DS? I created a new user in AD and it doesn't propogate to DS, just says: attempting to sync password for testuser3 searching for (ntuserdomainid=testuser3) There are no entries that match: testuser3 deferring password change for testuser3 On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson wrote: > ** > On 01/20/2012 12:46 PM, Jimmy wrote: > > Getting close here... Now I see this message in the sync log file: > > attempting to sync password for testuser > searching for (ntuserdomainid=testuser) > ldap error in queryusername > 32: no such object > deferring password change for testuser > > This usually means the search base is incorrect or not found. You can > look at the 389 access log to see what it was using as the search criteria. > > > On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson wrote: > >> On 01/20/2012 10:23 AM, Jimmy wrote: >> >> You are correct. I had installed as an Enterprise root, but the doc I was >> reading(original link) seemed to say that I had to do the certreq manually, >> my bad. I think I'm getting closer I can establish an openssl connection >> from DS to AD but I get these errors: >> >> openssl s_client -connect 192.168.201.150:636 -showcerts -CAfile >> dsca.crt >> CONNECTED(00000003) >> depth=0 CN = csp-ad.cspad.pdh.csp >> verify error:num=20:unable to get local issuer certificate >> verify return:1 >> depth=0 CN = csp-ad.cspad.pdh.csp >> verify error:num=27:certificate not trusted >> verify return:1 >> depth=0 CN = csp-ad.cspad.pdh.csp >> verify error:num=21:unable to verify the first certificate >> verify return:1 >> >> I thought I had imported the cert from AD but it doesn't seem so. I'm >> still researching but if you guys have a suggestion let me know. >> >> Is dsca.crt the CA that issued the DS server cert? If so, that won't >> work. You need the CA cert from the CA that issued the AD server cert >> (i.e. the CA cert from the MS Enterprise Root CA). >> >> -J >> >> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson wrote: >> >>> On 01/19/2012 02:59 PM, Jimmy wrote: >>> >>> ok. I started from scratch this week on this and I think I've got the >>> right doc and understand better where this is going. My problem now is that >>> when configuring SSL on the AD server (step c in this url: >>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>> >>> I get this error: >>> >>> certreq -submit request.req certnew.cer >>> Active Directory Enrollment Policy >>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>> ldap: >>> RequestId: 3 >>> RequestId: "3" >>> Certificate not issued (Denied) Denied by Policy Module 0x80094801, The >>> request does not contain a certificate template extension or the >>> CertificateTemplate request attribute. >>> The request contains no certificate template information. 0x80094801 >>> (-2146875391) >>> Certificate Request Processor: The request contains no certificate >>> template information. 0x80094801 (-2146875391) >>> Denied by Policy Module 0x80094801, The request does not contain a >>> certificate template extension or the CertificateTemplate request attribute. >>> >>> The RH doc says to use the browser if an error occurs and IIS is >>> running but I'm not running IIS. I researched that error but didn't find >>> anything that helps with FreeIPA and passsync. >>> >>> Hmm - try installing Microsoft Certificate Authority in Enterprise Root >>> CA mode - it will usually automatically create and install the AD server >>> cert. http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>> >>> >>> Jimmy >>> >>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson wrote: >>> >>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>> >>>> We need to be able to replicate user/pass between Windows 2008 AD and >>>> FreeIPA. >>>> >>>> >>>> That's what IPA Windows Sync is supposed to do. >>>> >>>> >>>> I have followed many different documents and posted here about it and >>>> from what I've read and procedures I've followed we are unable to >>>> accomplish this. >>>> >>>> >>>> What have you tried, and what problems have you run into? >>>> >>>> It doesn't need to be a full trust. >>>> >>>> Thanks >>>> >>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: >>>> >>>>> > Just wondering if there was anyone listening on the list that >>>>> might be >>>>> > available for little work integrating FreeIPA with Active Directory >>>>> > (preferrably in the south east US.) I hope this isn't against the >>>>> list >>>>> > rules, I just thought one of you guys could help or point me in the >>>>> right >>>>> > direction. >>>>> >>>>> If you want some help, it is certainly not against list rules ;-) >>>>> But in that >>>>> case, it would be much better if you asked what exactly do you need. >>>>> >>>>> I'm not an AD expert, but a couple tips: If you are looking for >>>>> cross-domain >>>>> (cross-realm) trust, then you might be a bit disappointed, it is still >>>>> in >>>>> development, so it probably won't be 100% functional at this moment. >>>>> >>>>> If you are looking for something else, could you be a little more >>>>> specific what >>>>> it is? >>>>> >>>>> I also recommend starting with reading some doc: >>>>> http://freeipa.org/page/DocumentationPortal >>>>> >>>>> Thanks >>>>> Jan >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Jan 20 20:28:29 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 20 Jan 2012 13:28:29 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> Message-ID: <4F19CE6D.6010101@redhat.com> On 01/20/2012 01:08 PM, Jimmy wrote: > That was it! I have passwords syncing, *BUT*(at the risk of sounding > stupid)-- is it not possible to also sync(add) the users from AD to DS? Yes, it is. Just configure IPA Windows Sync > I created a new user in AD and it doesn't propogate to DS, just says: > > attempting to sync password for testuser3 > searching for (ntuserdomainid=testuser3) > There are no entries that match: testuser3 > deferring password change for testuser3 > > On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson > wrote: > > On 01/20/2012 12:46 PM, Jimmy wrote: >> Getting close here... Now I see this message in the sync log file: >> >> attempting to sync password for testuser >> searching for (ntuserdomainid=testuser) >> ldap error in queryusername >> 32: no such object >> deferring password change for testuser > This usually means the search base is incorrect or not found. You > can look at the 389 access log to see what it was using as the > search criteria. > >> >> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson >> > wrote: >> >> On 01/20/2012 10:23 AM, Jimmy wrote: >>> You are correct. I had installed as an Enterprise root, but >>> the doc I was reading(original link) seemed to say that I >>> had to do the certreq manually, my bad. I think I'm getting >>> closer I can establish an openssl connection from DS to AD >>> but I get these errors: >>> >>> openssl s_client -connect 192.168.201.150:636 >>> -showcerts -CAfile dsca.crt >>> CONNECTED(00000003) >>> depth=0 CN = csp-ad.cspad.pdh.csp >>> verify error:num=20:unable to get local issuer certificate >>> verify return:1 >>> depth=0 CN = csp-ad.cspad.pdh.csp >>> verify error:num=27:certificate not trusted >>> verify return:1 >>> depth=0 CN = csp-ad.cspad.pdh.csp >>> verify error:num=21:unable to verify the first certificate >>> verify return:1 >>> >>> I thought I had imported the cert from AD but it doesn't >>> seem so. I'm still researching but if you guys have a >>> suggestion let me know. >> Is dsca.crt the CA that issued the DS server cert? If so, >> that won't work. You need the CA cert from the CA that >> issued the AD server cert (i.e. the CA cert from the MS >> Enterprise Root CA). >> >>> -J >>> >>> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson >>> > wrote: >>> >>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>> ok. I started from scratch this week on this and I >>>> think I've got the right doc and understand better >>>> where this is going. My problem now is that when >>>> configuring SSL on the AD server (step c in this url: >>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>> >>>> I get this error: >>>> >>>> certreq -submit request.req certnew.cer >>>> Active Directory Enrollment Policy >>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>> ldap: >>>> RequestId: 3 >>>> RequestId: "3" >>>> Certificate not issued (Denied) Denied by Policy Module >>>> 0x80094801, The request does not contain a certificate >>>> template extension or the CertificateTemplate request >>>> attribute. >>>> The request contains no certificate template >>>> information. 0x80094801 (-2146875391 ) >>>> Certificate Request Processor: The request contains no >>>> certificate template information. 0x80094801 >>>> (-2146875391 ) >>>> Denied by Policy Module 0x80094801, The request does >>>> not contain a certificate template extension or the >>>> CertificateTemplate request attribute. >>>> >>>> The RH doc says to use the browser if an error occurs >>>> and IIS is running but I'm not running IIS. I >>>> researched that error but didn't find anything that >>>> helps with FreeIPA and passsync. >>> Hmm - try installing Microsoft Certificate Authority in >>> Enterprise Root CA mode - it will usually automatically >>> create and install the AD server cert. >>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>> >>>> >>>> Jimmy >>>> >>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson >>>> > wrote: >>>> >>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>>> We need to be able to replicate user/pass between >>>>> Windows 2008 AD and FreeIPA. >>>> >>>> That's what IPA Windows Sync is supposed to do. >>>> >>>> >>>>> I have followed many different documents and >>>>> posted here about it and from what I've read and >>>>> procedures I've followed we are unable to >>>>> accomplish this. >>>> >>>> What have you tried, and what problems have you run >>>> into? >>>> >>>>> It doesn't need to be a full trust. >>>>> >>>>> Thanks >>>>> >>>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? >>>>> > >>>>> wrote: >>>>> >>>>> > Just wondering if there was anyone listening >>>>> on the list that might be >>>>> > available for little work integrating >>>>> FreeIPA with Active Directory >>>>> > (preferrably in the south east US.) I hope >>>>> this isn't against the list >>>>> > rules, I just thought one of you guys could >>>>> help or point me in the right >>>>> > direction. >>>>> >>>>> If you want some help, it is certainly not >>>>> against list rules ;-) But in that >>>>> case, it would be much better if you asked >>>>> what exactly do you need. >>>>> >>>>> I'm not an AD expert, but a couple tips: If >>>>> you are looking for cross-domain >>>>> (cross-realm) trust, then you might be a bit >>>>> disappointed, it is still in >>>>> development, so it probably won't be 100% >>>>> functional at this moment. >>>>> >>>>> If you are looking for something else, could >>>>> you be a little more specific what >>>>> it is? >>>>> >>>>> I also recommend starting with reading some doc: >>>>> http://freeipa.org/page/DocumentationPortal >>>>> >>>>> Thanks >>>>> Jan >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Jan 20 20:53:47 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Jan 2012 15:53:47 -0500 Subject: [Freeipa-users] Post installation ( looks to be small issue ).. In-Reply-To: References: <4F186EEB.8040004@redhat.com> Message-ID: <4F19D45B.4000809@redhat.com> Nigel Sollars wrote: > HI, > > So is the failure of the client an issue, as in I need to run it again?. > > I still cant get the local firefox to authenticate. I think what I'd recommend is to uninstall and re-install the server from scratch. It might be the case that re-running the client installer would work but it isn't worth the risk that something else wasn't completed by the server installer. rob > > Regards > Nige > > On Thu, Jan 19, 2012 at 2:34 PM, Nigel Sollars > wrote: > > > > On Thu, Jan 19, 2012 at 2:28 PM, Rob Crittenden > wrote: > > Nigel Sollars wrote: > > Hi all, > > After fixing upa number of things and successfully > installing / testing > the server install, I have a small issue with the UI inside > firefox in > that after importing the CA and looking at a few guides I > notice these > line in my http error logs: > > > What things did you fix up? > > > > Just permissions on /dev/shm and /var/tmp > > > > > [Thu Jan 19 13:17:56 2012] [error] [client x.x.x.x] File > does not exist: > /usr/share/ipa/ui/develop.js, referer: > https://ipaserver.jitscaleus.__net/ipa/ui/ > > [Thu Jan 19 13:19:41 2012] [error] [client x.x.x.x] File > does not exist: > /usr/share/ipa/ui/develop.js, referer: > https://ipaserver.jitscaleus.__net/ipa/ui/ > > [Thu Jan 19 13:19:59 2012] [error] [client x.x.x.x] File > does not exist: > /usr/share/ipa/ui/develop.js, referer: > https://ipaserver.jitscaleus.__net/ipa/ui/ > > [Thu Jan 19 13:27:58 2012] [error] [client x.x.3.x] File > does not exist: > /usr/share/ipa/ui/develop.js, referer: > https://ipaserver.jitscaleus.__net/ipa/ui/ > > [Thu Jan 19 13:31:34 2012] [error] [client x.x.x.x] File > does not exist: > /usr/share/ipa/ui/develop.js, referer: > https://ipaserver.jitscaleus.__net/ipa/ui/ > > > > I think this can be ignored, I believe the code is just used for > testing/developing (and isn't used at all in newer builds). > > > > > Ok cool > > I ran through the trouble shooting guide with re-running > kinit ( passing > password ) then running, ldapsearch -Y GSSAPI -b > "dc=domain,dc=com" > uid=admin, which returned the correct response, > > The browser loops around the configuration from the server > to return to > the webui with the error of an invalid ticket. > > > Did you configure the browser to do negotiate authentication (or > use the configure firefox button)? > > > > Via the button, the CA is there about:config shows the correct > network options there also. > > I am not 100% if this is relevant or not but the client > install that was > called after the ser install finalized, bombed completely > with the folowing: > > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install"__, line 1292, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install"__, line 1279, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install"__, line 1117, in install > fstore.backup_file("/etc/sssd/__sssd.conf") > File > "/usr/lib/python2.6/site-__packages/ipapython/sysrestore.__py", > line > 126, in backup_file > shutil.copy2(path, backup_path) > File "/usr/lib64/python2.6/shutil.__py", line 95, in copy2 > copyfile(src, dst) > File "/usr/lib64/python2.6/shutil.__py", line 51, in copyfile > with open(dst, 'wb') as fdst: > IOError: [Errno 2] No such file or directory: > '/var/lib/ipa-client/__sysrestore/107a99f6a6514e30-__sssd.conf' > > > Strange. Does /var/lib/ipa-client/sysrestore exist? > > > No that one is not there > > rob > > > > > -- > ?Science is a differential equation. Religion is a boundary condition.? > Alan Turing > > > > > -- > ?Science is a differential equation. Religion is a boundary condition.? > Alan Turing > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sigbjorn at nixtra.com Sat Jan 21 18:40:29 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Sat, 21 Jan 2012 19:40:29 +0100 Subject: [Freeipa-users] Forcing IPA clients to prioritise different IPA Servers In-Reply-To: <1327081883.2250.56.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1326856794.21682.70.camel@sgallagh520.sgallagh.bos.redhat.com> <4F16E646.1000400@redhat.com> <1326979785.2141.12.camel@sgallagh520.sgallagh.bos.redhat.com> <1326987188.2141.14.camel@sgallagh520.sgallagh.bos.redhat.com> <4F1997E0.4070106@nixtra.com> <1327080822.2250.55.camel@sgallagh520.sgallagh.bos.redhat.com> <4F19A73E.5090101@nixtra.com> <1327081883.2250.56.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4F1B069D.8040300@nixtra.com> On 01/20/2012 06:51 PM, Stephen Gallagher wrote: > On Fri, 2012-01-20 at 18:41 +0100, Sigbjorn Lie wrote: >> > On 01/20/2012 06:33 PM, Stephen Gallagher wrote: >>> > > On Fri, 2012-01-20 at 17:35 +0100, Sigbjorn Lie wrote: >>>> > >> On 01/19/2012 04:33 PM, Stephen Gallagher wrote: >>>>> > >>> On Thu, 2012-01-19 at 14:06 +0000, Charlie Derwent wrote: >>>>>> > >>>> https://fedorahosted.org/freeipa/ticket/22827 >>>>> > >>> For the record, the correct link is >>>>> > >>> https://fedorahosted.org/freeipa/ticket/2282 >>>>> > >>> >>>>> > >>> >>>> > >> The Solaris LDAP client has a property called servers, and a property >>>> > >> called preferred servers. As the name implies, all the preferred servers >>>> > >> will be used before using the rest of the servers in the servers >>>> > >> property for that client. >>>> > >> >>>> > >> Perhaps this would be a good idea to implement in SSSD too? >>> > > https://fedorahosted.org/sssd/ticket/1128 >>> > > >>> > > Currently scheduled for SSSD 1.9.0 (end of May) >>> > > >> > Excellent!:) >> > >> > In the ticket is mentioned "server", a single server. Will this feature >> > be implemented of a single primary server, or a group of >> > primary/preferred servers? >> > > The original intent was to handle switching back over to the primary > server when failover caused an error. However, please add your request > to that ticket and it'll be evaluated there. Done. I still can't log on to the fedorahosted.org trac., so I added it to https://bugzilla.redhat.com/show_bug.cgi?id=783166 -------------- next part -------------- An HTML attachment was scrubbed... URL: From g17jimmy at gmail.com Mon Jan 23 17:19:39 2012 From: g17jimmy at gmail.com (Jimmy) Date: Mon, 23 Jan 2012 12:19:39 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F19CE6D.6010101@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> Message-ID: Here's what I found in the DS admin guide. Is this all that's needed to create the sync agreement? Thanks. add sync agreement: ldapmodify -x -D "cn=Directory Manager" -W Enter LDAP Password: ******* dn: cn=ExampleSyncAgreement,cn=sync replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config changetype: add objectclass: top objectclass: nsDSWindowsReplicationAgreement cn: ExampleSyncAgreement nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com nsds7NewWinUserSyncEnabled: on nsds7NewWinGroupSyncEnabled: on nsds7WindowsDomain: ad1 nsDS5ReplicaRoot: dc=example,dc=com nsDS5ReplicaHost: ad1.windows-server.com nsDS5ReplicaPort: 389 nsDS5ReplicaBindDN: cn=sync user,cn=config nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA== nsDS5ReplicaTransportInfo: TLS winSyncInterval: 1200 On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson wrote: > ** > On 01/20/2012 01:08 PM, Jimmy wrote: > > That was it! I have passwords syncing, *BUT*(at the risk of sounding > stupid)-- is it not possible to also sync(add) the users from AD to DS? > > Yes, it is. Just configure IPA Windows Sync > > I created a new user in AD and it doesn't propogate to DS, just says: > > attempting to sync password for testuser3 > searching for (ntuserdomainid=testuser3) > There are no entries that match: testuser3 > deferring password change for testuser3 > > On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson wrote: > >> On 01/20/2012 12:46 PM, Jimmy wrote: >> >> Getting close here... Now I see this message in the sync log file: >> >> attempting to sync password for testuser >> searching for (ntuserdomainid=testuser) >> ldap error in queryusername >> 32: no such object >> deferring password change for testuser >> >> This usually means the search base is incorrect or not found. You can >> look at the 389 access log to see what it was using as the search criteria. >> >> >> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson wrote: >> >>> On 01/20/2012 10:23 AM, Jimmy wrote: >>> >>> You are correct. I had installed as an Enterprise root, but the doc I >>> was reading(original link) seemed to say that I had to do the certreq >>> manually, my bad. I think I'm getting closer I can establish an openssl >>> connection from DS to AD but I get these errors: >>> >>> openssl s_client -connect 192.168.201.150:636 -showcerts -CAfile >>> dsca.crt >>> CONNECTED(00000003) >>> depth=0 CN = csp-ad.cspad.pdh.csp >>> verify error:num=20:unable to get local issuer certificate >>> verify return:1 >>> depth=0 CN = csp-ad.cspad.pdh.csp >>> verify error:num=27:certificate not trusted >>> verify return:1 >>> depth=0 CN = csp-ad.cspad.pdh.csp >>> verify error:num=21:unable to verify the first certificate >>> verify return:1 >>> >>> I thought I had imported the cert from AD but it doesn't seem so. I'm >>> still researching but if you guys have a suggestion let me know. >>> >>> Is dsca.crt the CA that issued the DS server cert? If so, that won't >>> work. You need the CA cert from the CA that issued the AD server cert >>> (i.e. the CA cert from the MS Enterprise Root CA). >>> >>> -J >>> >>> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson wrote: >>> >>>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>> >>>> ok. I started from scratch this week on this and I think I've got the >>>> right doc and understand better where this is going. My problem now is that >>>> when configuring SSL on the AD server (step c in this url: >>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>> >>>> I get this error: >>>> >>>> certreq -submit request.req certnew.cer >>>> Active Directory Enrollment Policy >>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>> ldap: >>>> RequestId: 3 >>>> RequestId: "3" >>>> Certificate not issued (Denied) Denied by Policy Module 0x80094801, >>>> The request does not contain a certificate template extension or the >>>> CertificateTemplate request attribute. >>>> The request contains no certificate template information. 0x80094801 >>>> (-2146875391) >>>> Certificate Request Processor: The request contains no certificate >>>> template information. 0x80094801 (-2146875391) >>>> Denied by Policy Module 0x80094801, The request does not contain a >>>> certificate template extension or the CertificateTemplate request attribute. >>>> >>>> The RH doc says to use the browser if an error occurs and IIS is >>>> running but I'm not running IIS. I researched that error but didn't find >>>> anything that helps with FreeIPA and passsync. >>>> >>>> Hmm - try installing Microsoft Certificate Authority in Enterprise >>>> Root CA mode - it will usually automatically create and install the AD >>>> server cert. http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>> >>>> >>>> Jimmy >>>> >>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson wrote: >>>> >>>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>>> >>>>> We need to be able to replicate user/pass between Windows 2008 AD and >>>>> FreeIPA. >>>>> >>>>> >>>>> That's what IPA Windows Sync is supposed to do. >>>>> >>>>> >>>>> I have followed many different documents and posted here about it and >>>>> from what I've read and procedures I've followed we are unable to >>>>> accomplish this. >>>>> >>>>> >>>>> What have you tried, and what problems have you run into? >>>>> >>>>> It doesn't need to be a full trust. >>>>> >>>>> Thanks >>>>> >>>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: >>>>> >>>>>> > Just wondering if there was anyone listening on the list that >>>>>> might be >>>>>> > available for little work integrating FreeIPA with Active Directory >>>>>> > (preferrably in the south east US.) I hope this isn't against the >>>>>> list >>>>>> > rules, I just thought one of you guys could help or point me in the >>>>>> right >>>>>> > direction. >>>>>> >>>>>> If you want some help, it is certainly not against list rules ;-) >>>>>> But in that >>>>>> case, it would be much better if you asked what exactly do you need. >>>>>> >>>>>> I'm not an AD expert, but a couple tips: If you are looking for >>>>>> cross-domain >>>>>> (cross-realm) trust, then you might be a bit disappointed, it is >>>>>> still in >>>>>> development, so it probably won't be 100% functional at this moment. >>>>>> >>>>>> If you are looking for something else, could you be a little more >>>>>> specific what >>>>>> it is? >>>>>> >>>>>> I also recommend starting with reading some doc: >>>>>> http://freeipa.org/page/DocumentationPortal >>>>>> >>>>>> Thanks >>>>>> Jan >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Jan 23 17:30:59 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 23 Jan 2012 10:30:59 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> Message-ID: <4F1D9953.7060408@redhat.com> On 01/23/2012 10:19 AM, Jimmy wrote: > Here's what I found in the DS admin guide. Is this all that's needed > to create the sync agreement? Not with ipa - you should use the ipa-replica-manage command instead > Thanks. > > add sync agreement: > ldapmodify -x -D "cn=Directory Manager" -W > Enter LDAP Password: ******* > dn: cn=ExampleSyncAgreement,cn=sync > replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config it should be cn=replica, not cn=sync replica - does it use the latter in the Admin Guide? > changetype: add > objectclass: top > objectclass: nsDSWindowsReplicationAgreement > cn: ExampleSyncAgreement > nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 > nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com > nsds7NewWinUserSyncEnabled: on > nsds7NewWinGroupSyncEnabled: on > nsds7WindowsDomain: ad1 > nsDS5ReplicaRoot: dc=example,dc=com > nsDS5ReplicaHost: ad1.windows-server.com > nsDS5ReplicaPort: 389 > nsDS5ReplicaBindDN: cn=sync user,cn=config > nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA== > nsDS5ReplicaTransportInfo: TLS > winSyncInterval: 1200 > > On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson > wrote: > > On 01/20/2012 01:08 PM, Jimmy wrote: >> That was it! I have passwords syncing, *BUT*(at the risk of >> sounding stupid)-- is it not possible to also sync(add) the users >> from AD to DS? > Yes, it is. Just configure IPA Windows Sync > >> I created a new user in AD and it doesn't propogate to DS, just >> says: >> >> attempting to sync password for testuser3 >> searching for (ntuserdomainid=testuser3) >> There are no entries that match: testuser3 >> deferring password change for testuser3 >> >> On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson >> > wrote: >> >> On 01/20/2012 12:46 PM, Jimmy wrote: >>> Getting close here... Now I see this message in the sync log >>> file: >>> >>> attempting to sync password for testuser >>> searching for (ntuserdomainid=testuser) >>> ldap error in queryusername >>> 32: no such object >>> deferring password change for testuser >> This usually means the search base is incorrect or not >> found. You can look at the 389 access log to see what it was >> using as the search criteria. >> >>> >>> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson >>> > wrote: >>> >>> On 01/20/2012 10:23 AM, Jimmy wrote: >>>> You are correct. I had installed as an Enterprise root, >>>> but the doc I was reading(original link) seemed to say >>>> that I had to do the certreq manually, my bad. I think >>>> I'm getting closer I can establish an openssl >>>> connection from DS to AD but I get these errors: >>>> >>>> openssl s_client -connect 192.168.201.150:636 >>>> -showcerts -CAfile dsca.crt >>>> CONNECTED(00000003) >>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>> verify error:num=20:unable to get local issuer certificate >>>> verify return:1 >>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>> verify error:num=27:certificate not trusted >>>> verify return:1 >>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>> verify error:num=21:unable to verify the first certificate >>>> verify return:1 >>>> >>>> I thought I had imported the cert from AD but it >>>> doesn't seem so. I'm still researching but if you guys >>>> have a suggestion let me know. >>> Is dsca.crt the CA that issued the DS server cert? If >>> so, that won't work. You need the CA cert from the CA >>> that issued the AD server cert (i.e. the CA cert from >>> the MS Enterprise Root CA). >>> >>>> -J >>>> >>>> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson >>>> > wrote: >>>> >>>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>>> ok. I started from scratch this week on this and I >>>>> think I've got the right doc and understand better >>>>> where this is going. My problem now is that when >>>>> configuring SSL on the AD server (step c in this >>>>> url: >>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>> >>>>> I get this error: >>>>> >>>>> certreq -submit request.req certnew.cer >>>>> Active Directory Enrollment Policy >>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>> ldap: >>>>> RequestId: 3 >>>>> RequestId: "3" >>>>> Certificate not issued (Denied) Denied by Policy >>>>> Module 0x80094801, The request does not contain a >>>>> certificate template extension or the >>>>> CertificateTemplate request attribute. >>>>> The request contains no certificate template >>>>> information. 0x80094801 (-2146875391 >>>>> ) >>>>> Certificate Request Processor: The request >>>>> contains no certificate template information. >>>>> 0x80094801 (-2146875391 ) >>>>> Denied by Policy Module 0x80094801, The request >>>>> does not contain a certificate template extension >>>>> or the CertificateTemplate request attribute. >>>>> >>>>> The RH doc says to use the browser if an error >>>>> occurs and IIS is running but I'm not running IIS. >>>>> I researched that error but didn't find anything >>>>> that helps with FreeIPA and passsync. >>>> Hmm - try installing Microsoft Certificate >>>> Authority in Enterprise Root CA mode - it will >>>> usually automatically create and install the AD >>>> server cert. >>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>> >>>> >>>>> >>>>> Jimmy >>>>> >>>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson >>>>> > >>>>> wrote: >>>>> >>>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>>>> We need to be able to replicate user/pass >>>>>> between Windows 2008 AD and FreeIPA. >>>>> >>>>> That's what IPA Windows Sync is supposed to do. >>>>> >>>>> >>>>>> I have followed many different documents and >>>>>> posted here about it and from what I've read >>>>>> and procedures I've followed we are unable to >>>>>> accomplish this. >>>>> >>>>> What have you tried, and what problems have >>>>> you run into? >>>>> >>>>>> It doesn't need to be a full trust. >>>>>> >>>>>> Thanks >>>>>> >>>>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? >>>>>> >>>>> > wrote: >>>>>> >>>>>> > Just wondering if there was anyone >>>>>> listening on the list that might be >>>>>> > available for little work integrating >>>>>> FreeIPA with Active Directory >>>>>> > (preferrably in the south east US.) I >>>>>> hope this isn't against the list >>>>>> > rules, I just thought one of you guys >>>>>> could help or point me in the right >>>>>> > direction. >>>>>> >>>>>> If you want some help, it is certainly >>>>>> not against list rules ;-) But in that >>>>>> case, it would be much better if you >>>>>> asked what exactly do you need. >>>>>> >>>>>> I'm not an AD expert, but a couple tips: >>>>>> If you are looking for cross-domain >>>>>> (cross-realm) trust, then you might be a >>>>>> bit disappointed, it is still in >>>>>> development, so it probably won't be 100% >>>>>> functional at this moment. >>>>>> >>>>>> If you are looking for something else, >>>>>> could you be a little more specific what >>>>>> it is? >>>>>> >>>>>> I also recommend starting with reading >>>>>> some doc: >>>>>> http://freeipa.org/page/DocumentationPortal >>>>>> >>>>>> Thanks >>>>>> Jan >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-users mailing list >>>>>> Freeipa-users at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g17jimmy at gmail.com Mon Jan 23 17:52:25 2012 From: g17jimmy at gmail.com (Jimmy) Date: Mon, 23 Jan 2012 12:52:25 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F1D9953.7060408@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> Message-ID: That's what I was thinking, and what I did, but it still doesn't replicate new users. This is the command I used: ipa-replica-manage connect --passsync --binddn cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp --bindpw=******** --cacert /home/winsync/AD-server-cert.cer 192.168.201.150 -v On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson wrote: > ** > On 01/23/2012 10:19 AM, Jimmy wrote: > > Here's what I found in the DS admin guide. Is this all that's needed to > create the sync agreement? > > Not with ipa - you should use the ipa-replica-manage command instead > > Thanks. > > add sync agreement: > ldapmodify -x -D "cn=Directory Manager" -W > Enter LDAP Password: ******* > dn: cn=ExampleSyncAgreement,cn=sync > replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config > > it should be cn=replica, not cn=sync replica - does it use the latter in > the Admin Guide? > > changetype: add > objectclass: top > objectclass: nsDSWindowsReplicationAgreement > cn: ExampleSyncAgreement > nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 > nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com > > nsds7NewWinUserSyncEnabled: on > nsds7NewWinGroupSyncEnabled: on > nsds7WindowsDomain: ad1 > nsDS5ReplicaRoot: dc=example,dc=com > nsDS5ReplicaHost: ad1.windows-server.com > nsDS5ReplicaPort: 389 > nsDS5ReplicaBindDN: cn=sync user,cn=config > nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA== > nsDS5ReplicaTransportInfo: TLS > winSyncInterval: 1200 > > On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson wrote: > >> On 01/20/2012 01:08 PM, Jimmy wrote: >> >> That was it! I have passwords syncing, *BUT*(at the risk of sounding >> stupid)-- is it not possible to also sync(add) the users from AD to DS? >> >> Yes, it is. Just configure IPA Windows Sync >> >> I created a new user in AD and it doesn't propogate to DS, just says: >> >> attempting to sync password for testuser3 >> searching for (ntuserdomainid=testuser3) >> There are no entries that match: testuser3 >> deferring password change for testuser3 >> >> On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson wrote: >> >>> On 01/20/2012 12:46 PM, Jimmy wrote: >>> >>> Getting close here... Now I see this message in the sync log file: >>> >>> attempting to sync password for testuser >>> searching for (ntuserdomainid=testuser) >>> ldap error in queryusername >>> 32: no such object >>> deferring password change for testuser >>> >>> This usually means the search base is incorrect or not found. You can >>> look at the 389 access log to see what it was using as the search criteria. >>> >>> >>> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson wrote: >>> >>>> On 01/20/2012 10:23 AM, Jimmy wrote: >>>> >>>> You are correct. I had installed as an Enterprise root, but the doc I >>>> was reading(original link) seemed to say that I had to do the certreq >>>> manually, my bad. I think I'm getting closer I can establish an openssl >>>> connection from DS to AD but I get these errors: >>>> >>>> openssl s_client -connect 192.168.201.150:636 -showcerts -CAfile >>>> dsca.crt >>>> CONNECTED(00000003) >>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>> verify error:num=20:unable to get local issuer certificate >>>> verify return:1 >>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>> verify error:num=27:certificate not trusted >>>> verify return:1 >>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>> verify error:num=21:unable to verify the first certificate >>>> verify return:1 >>>> >>>> I thought I had imported the cert from AD but it doesn't seem so. I'm >>>> still researching but if you guys have a suggestion let me know. >>>> >>>> Is dsca.crt the CA that issued the DS server cert? If so, that won't >>>> work. You need the CA cert from the CA that issued the AD server cert >>>> (i.e. the CA cert from the MS Enterprise Root CA). >>>> >>>> -J >>>> >>>> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson wrote: >>>> >>>>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>>> >>>>> ok. I started from scratch this week on this and I think I've got the >>>>> right doc and understand better where this is going. My problem now is that >>>>> when configuring SSL on the AD server (step c in this url: >>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>> >>>>> I get this error: >>>>> >>>>> certreq -submit request.req certnew.cer >>>>> Active Directory Enrollment Policy >>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>> ldap: >>>>> RequestId: 3 >>>>> RequestId: "3" >>>>> Certificate not issued (Denied) Denied by Policy Module 0x80094801, >>>>> The request does not contain a certificate template extension or the >>>>> CertificateTemplate request attribute. >>>>> The request contains no certificate template information. 0x80094801 >>>>> (-2146875391) >>>>> Certificate Request Processor: The request contains no certificate >>>>> template information. 0x80094801 (-2146875391) >>>>> Denied by Policy Module 0x80094801, The request does not contain a >>>>> certificate template extension or the CertificateTemplate request attribute. >>>>> >>>>> The RH doc says to use the browser if an error occurs and IIS is >>>>> running but I'm not running IIS. I researched that error but didn't find >>>>> anything that helps with FreeIPA and passsync. >>>>> >>>>> Hmm - try installing Microsoft Certificate Authority in Enterprise >>>>> Root CA mode - it will usually automatically create and install the AD >>>>> server cert. >>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>> >>>>> >>>>> Jimmy >>>>> >>>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson wrote: >>>>> >>>>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>>>> >>>>>> We need to be able to replicate user/pass between Windows 2008 AD and >>>>>> FreeIPA. >>>>>> >>>>>> >>>>>> That's what IPA Windows Sync is supposed to do. >>>>>> >>>>>> >>>>>> I have followed many different documents and posted here about it and >>>>>> from what I've read and procedures I've followed we are unable to >>>>>> accomplish this. >>>>>> >>>>>> >>>>>> What have you tried, and what problems have you run into? >>>>>> >>>>>> It doesn't need to be a full trust. >>>>>> >>>>>> Thanks >>>>>> >>>>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: >>>>>> >>>>>>> > Just wondering if there was anyone listening on the list that >>>>>>> might be >>>>>>> > available for little work integrating FreeIPA with Active Directory >>>>>>> > (preferrably in the south east US.) I hope this isn't against the >>>>>>> list >>>>>>> > rules, I just thought one of you guys could help or point me in >>>>>>> the right >>>>>>> > direction. >>>>>>> >>>>>>> If you want some help, it is certainly not against list rules ;-) >>>>>>> But in that >>>>>>> case, it would be much better if you asked what exactly do you need. >>>>>>> >>>>>>> I'm not an AD expert, but a couple tips: If you are looking for >>>>>>> cross-domain >>>>>>> (cross-realm) trust, then you might be a bit disappointed, it is >>>>>>> still in >>>>>>> development, so it probably won't be 100% functional at this moment. >>>>>>> >>>>>>> If you are looking for something else, could you be a little more >>>>>>> specific what >>>>>>> it is? >>>>>>> >>>>>>> I also recommend starting with reading some doc: >>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>> >>>>>>> Thanks >>>>>>> Jan >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Jan 23 18:06:14 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 23 Jan 2012 11:06:14 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> Message-ID: <4F1DA196.3070808@redhat.com> On 01/23/2012 10:52 AM, Jimmy wrote: > That's what I was thinking, and what I did, but it still doesn't > replicate new users. This is the command I used: > > ipa-replica-manage connect --passsync --binddn > cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp --bindpw=******** --cacert > /home/winsync/AD-server-cert.cer 192.168.201.150 -v Did you create the user cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp? And does this user have the rights to perform sync? (e.g. has to have replicator rights, or be some sort of admin) - see http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx - the AD user must have replication rights and write rights. In addition, since this process uses SSL, you cannot use an IP address, you must use a hostname, or the SSL cert hostname checking (for MITM) will fail. > > On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson > wrote: > > On 01/23/2012 10:19 AM, Jimmy wrote: >> Here's what I found in the DS admin guide. Is this all that's >> needed to create the sync agreement? > Not with ipa - you should use the ipa-replica-manage command instead > >> Thanks. >> >> add sync agreement: >> ldapmodify -x -D "cn=Directory Manager" -W >> Enter LDAP Password: ******* >> dn: cn=ExampleSyncAgreement,cn=sync >> replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config > it should be cn=replica, not cn=sync replica - does it use the > latter in the Admin Guide? > >> changetype: add >> objectclass: top >> objectclass: nsDSWindowsReplicationAgreement >> cn: ExampleSyncAgreement >> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 >> nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com >> nsds7NewWinUserSyncEnabled: on >> nsds7NewWinGroupSyncEnabled: on >> nsds7WindowsDomain: ad1 >> nsDS5ReplicaRoot: dc=example,dc=com >> nsDS5ReplicaHost: ad1.windows-server.com >> >> nsDS5ReplicaPort: 389 >> nsDS5ReplicaBindDN: cn=sync user,cn=config >> nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA== >> nsDS5ReplicaTransportInfo: TLS >> winSyncInterval: 1200 >> >> On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson >> > wrote: >> >> On 01/20/2012 01:08 PM, Jimmy wrote: >>> That was it! I have passwords syncing, *BUT*(at the risk of >>> sounding stupid)-- is it not possible to also sync(add) the >>> users from AD to DS? >> Yes, it is. Just configure IPA Windows Sync >> >>> I created a new user in AD and it doesn't propogate to DS, >>> just says: >>> >>> attempting to sync password for testuser3 >>> searching for (ntuserdomainid=testuser3) >>> There are no entries that match: testuser3 >>> deferring password change for testuser3 >>> >>> On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson >>> > wrote: >>> >>> On 01/20/2012 12:46 PM, Jimmy wrote: >>>> Getting close here... Now I see this message in the >>>> sync log file: >>>> >>>> attempting to sync password for testuser >>>> searching for (ntuserdomainid=testuser) >>>> ldap error in queryusername >>>> 32: no such object >>>> deferring password change for testuser >>> This usually means the search base is incorrect or not >>> found. You can look at the 389 access log to see what >>> it was using as the search criteria. >>> >>>> >>>> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson >>>> > wrote: >>>> >>>> On 01/20/2012 10:23 AM, Jimmy wrote: >>>>> You are correct. I had installed as an Enterprise >>>>> root, but the doc I was reading(original link) >>>>> seemed to say that I had to do the certreq >>>>> manually, my bad. I think I'm getting closer I can >>>>> establish an openssl connection from DS to AD but >>>>> I get these errors: >>>>> >>>>> openssl s_client -connect 192.168.201.150:636 >>>>> -showcerts -CAfile >>>>> dsca.crt >>>>> CONNECTED(00000003) >>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>> verify error:num=20:unable to get local issuer >>>>> certificate >>>>> verify return:1 >>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>> verify error:num=27:certificate not trusted >>>>> verify return:1 >>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>> verify error:num=21:unable to verify the first >>>>> certificate >>>>> verify return:1 >>>>> >>>>> I thought I had imported the cert from AD but it >>>>> doesn't seem so. I'm still researching but if you >>>>> guys have a suggestion let me know. >>>> Is dsca.crt the CA that issued the DS server cert? >>>> If so, that won't work. You need the CA cert from >>>> the CA that issued the AD server cert (i.e. the CA >>>> cert from the MS Enterprise Root CA). >>>> >>>>> -J >>>>> >>>>> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson >>>>> > >>>>> wrote: >>>>> >>>>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>>>> ok. I started from scratch this week on this >>>>>> and I think I've got the right doc and >>>>>> understand better where this is going. My >>>>>> problem now is that when configuring SSL on >>>>>> the AD server (step c in this url: >>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>>> >>>>>> I get this error: >>>>>> >>>>>> certreq -submit request.req certnew.cer >>>>>> Active Directory Enrollment Policy >>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>>> ldap: >>>>>> RequestId: 3 >>>>>> RequestId: "3" >>>>>> Certificate not issued (Denied) Denied by >>>>>> Policy Module 0x80094801, The request does >>>>>> not contain a certificate template extension >>>>>> or the CertificateTemplate request attribute. >>>>>> The request contains no certificate template >>>>>> information. 0x80094801 (-2146875391 >>>>>> ) >>>>>> Certificate Request Processor: The request >>>>>> contains no certificate template information. >>>>>> 0x80094801 (-2146875391 ) >>>>>> Denied by Policy Module 0x80094801, The >>>>>> request does not contain a certificate >>>>>> template extension or the CertificateTemplate >>>>>> request attribute. >>>>>> >>>>>> The RH doc says to use the browser if an >>>>>> error occurs and IIS is running but I'm not >>>>>> running IIS. I researched that error but >>>>>> didn't find anything that helps with FreeIPA >>>>>> and passsync. >>>>> Hmm - try installing Microsoft Certificate >>>>> Authority in Enterprise Root CA mode - it will >>>>> usually automatically create and install the >>>>> AD server cert. >>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>> >>>>> >>>>>> >>>>>> Jimmy >>>>>> >>>>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich >>>>>> Megginson >>>>> > wrote: >>>>>> >>>>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>>>>> We need to be able to replicate >>>>>>> user/pass between Windows 2008 AD and >>>>>>> FreeIPA. >>>>>> >>>>>> That's what IPA Windows Sync is supposed >>>>>> to do. >>>>>> >>>>>> >>>>>>> I have followed many different documents >>>>>>> and posted here about it and from what >>>>>>> I've read and procedures I've followed >>>>>>> we are unable to accomplish this. >>>>>> >>>>>> What have you tried, and what problems >>>>>> have you run into? >>>>>> >>>>>>> It doesn't need to be a full trust. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan >>>>>>> Zelen? >>>>>> > wrote: >>>>>>> >>>>>>> > Just wondering if there was anyone >>>>>>> listening on the list that might be >>>>>>> > available for little work >>>>>>> integrating FreeIPA with Active >>>>>>> Directory >>>>>>> > (preferrably in the south east >>>>>>> US.) I hope this isn't against the list >>>>>>> > rules, I just thought one of you >>>>>>> guys could help or point me in the right >>>>>>> > direction. >>>>>>> >>>>>>> If you want some help, it is >>>>>>> certainly not against list rules ;-) >>>>>>> But in that >>>>>>> case, it would be much better if you >>>>>>> asked what exactly do you need. >>>>>>> >>>>>>> I'm not an AD expert, but a couple >>>>>>> tips: If you are looking for >>>>>>> cross-domain >>>>>>> (cross-realm) trust, then you might >>>>>>> be a bit disappointed, it is still in >>>>>>> development, so it probably won't be >>>>>>> 100% functional at this moment. >>>>>>> >>>>>>> If you are looking for something >>>>>>> else, could you be a little more >>>>>>> specific what >>>>>>> it is? >>>>>>> >>>>>>> I also recommend starting with >>>>>>> reading some doc: >>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>> >>>>>>> Thanks >>>>>>> Jan >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-users mailing list >>>>>>> Freeipa-users at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g17jimmy at gmail.com Mon Jan 23 18:34:11 2012 From: g17jimmy at gmail.com (Jimmy) Date: Mon, 23 Jan 2012 13:34:11 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F1DA196.3070808@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> Message-ID: I did create the winsync user and it is an admin. I will fix the ip address(change to hostname,) I only did it that was because this is currently a test system so I can figure out how to get it all working. On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson wrote: > ** > On 01/23/2012 10:52 AM, Jimmy wrote: > > That's what I was thinking, and what I did, but it still doesn't replicate > new users. This is the command I used: > > ipa-replica-manage connect --passsync --binddn > cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp --bindpw=******** --cacert > /home/winsync/AD-server-cert.cer 192.168.201.150 -v > > > Did you create the user cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp? And > does this user have the rights to perform sync? (e.g. has to have > replicator rights, or be some sort of admin) - see > http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx - the AD > user must have replication rights and write rights. > > In addition, since this process uses SSL, you cannot use an IP address, > you must use a hostname, or the SSL cert hostname checking (for MITM) will > fail. > > > On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson wrote: > >> On 01/23/2012 10:19 AM, Jimmy wrote: >> >> Here's what I found in the DS admin guide. Is this all that's needed to >> create the sync agreement? >> >> Not with ipa - you should use the ipa-replica-manage command instead >> >> Thanks. >> >> add sync agreement: >> ldapmodify -x -D "cn=Directory Manager" -W >> Enter LDAP Password: ******* >> dn: cn=ExampleSyncAgreement,cn=sync >> replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config >> >> it should be cn=replica, not cn=sync replica - does it use the latter in >> the Admin Guide? >> >> changetype: add >> objectclass: top >> objectclass: nsDSWindowsReplicationAgreement >> cn: ExampleSyncAgreement >> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 >> nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com >> >> nsds7NewWinUserSyncEnabled: on >> nsds7NewWinGroupSyncEnabled: on >> nsds7WindowsDomain: ad1 >> nsDS5ReplicaRoot: dc=example,dc=com >> nsDS5ReplicaHost: ad1.windows-server.com >> nsDS5ReplicaPort: 389 >> nsDS5ReplicaBindDN: cn=sync user,cn=config >> nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA== >> nsDS5ReplicaTransportInfo: TLS >> winSyncInterval: 1200 >> >> On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson wrote: >> >>> On 01/20/2012 01:08 PM, Jimmy wrote: >>> >>> That was it! I have passwords syncing, *BUT*(at the risk of sounding >>> stupid)-- is it not possible to also sync(add) the users from AD to DS? >>> >>> Yes, it is. Just configure IPA Windows Sync >>> >>> I created a new user in AD and it doesn't propogate to DS, just says: >>> >>> attempting to sync password for testuser3 >>> searching for (ntuserdomainid=testuser3) >>> There are no entries that match: testuser3 >>> deferring password change for testuser3 >>> >>> On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson wrote: >>> >>>> On 01/20/2012 12:46 PM, Jimmy wrote: >>>> >>>> Getting close here... Now I see this message in the sync log file: >>>> >>>> attempting to sync password for testuser >>>> searching for (ntuserdomainid=testuser) >>>> ldap error in queryusername >>>> 32: no such object >>>> deferring password change for testuser >>>> >>>> This usually means the search base is incorrect or not found. You can >>>> look at the 389 access log to see what it was using as the search criteria. >>>> >>>> >>>> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson wrote: >>>> >>>>> On 01/20/2012 10:23 AM, Jimmy wrote: >>>>> >>>>> You are correct. I had installed as an Enterprise root, but the doc I >>>>> was reading(original link) seemed to say that I had to do the certreq >>>>> manually, my bad. I think I'm getting closer I can establish an openssl >>>>> connection from DS to AD but I get these errors: >>>>> >>>>> openssl s_client -connect 192.168.201.150:636 -showcerts -CAfile >>>>> dsca.crt >>>>> CONNECTED(00000003) >>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>> verify error:num=20:unable to get local issuer certificate >>>>> verify return:1 >>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>> verify error:num=27:certificate not trusted >>>>> verify return:1 >>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>> verify error:num=21:unable to verify the first certificate >>>>> verify return:1 >>>>> >>>>> I thought I had imported the cert from AD but it doesn't seem so. >>>>> I'm still researching but if you guys have a suggestion let me know. >>>>> >>>>> Is dsca.crt the CA that issued the DS server cert? If so, that won't >>>>> work. You need the CA cert from the CA that issued the AD server cert >>>>> (i.e. the CA cert from the MS Enterprise Root CA). >>>>> >>>>> -J >>>>> >>>>> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson wrote: >>>>> >>>>>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>>>> >>>>>> ok. I started from scratch this week on this and I think I've got the >>>>>> right doc and understand better where this is going. My problem now is that >>>>>> when configuring SSL on the AD server (step c in this url: >>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>>> >>>>>> I get this error: >>>>>> >>>>>> certreq -submit request.req certnew.cer >>>>>> Active Directory Enrollment Policy >>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>>> ldap: >>>>>> RequestId: 3 >>>>>> RequestId: "3" >>>>>> Certificate not issued (Denied) Denied by Policy Module 0x80094801, >>>>>> The request does not contain a certificate template extension or the >>>>>> CertificateTemplate request attribute. >>>>>> The request contains no certificate template information. 0x80094801 >>>>>> (-2146875391) >>>>>> Certificate Request Processor: The request contains no certificate >>>>>> template information. 0x80094801 (-2146875391) >>>>>> Denied by Policy Module 0x80094801, The request does not contain a >>>>>> certificate template extension or the CertificateTemplate request attribute. >>>>>> >>>>>> The RH doc says to use the browser if an error occurs and IIS is >>>>>> running but I'm not running IIS. I researched that error but didn't find >>>>>> anything that helps with FreeIPA and passsync. >>>>>> >>>>>> Hmm - try installing Microsoft Certificate Authority in Enterprise >>>>>> Root CA mode - it will usually automatically create and install the AD >>>>>> server cert. >>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>>> >>>>>> >>>>>> Jimmy >>>>>> >>>>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson wrote: >>>>>> >>>>>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>>>>> >>>>>>> We need to be able to replicate user/pass between Windows 2008 AD >>>>>>> and FreeIPA. >>>>>>> >>>>>>> >>>>>>> That's what IPA Windows Sync is supposed to do. >>>>>>> >>>>>>> >>>>>>> I have followed many different documents and posted here about it >>>>>>> and from what I've read and procedures I've followed we are unable to >>>>>>> accomplish this. >>>>>>> >>>>>>> >>>>>>> What have you tried, and what problems have you run into? >>>>>>> >>>>>>> It doesn't need to be a full trust. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: >>>>>>> >>>>>>>> > Just wondering if there was anyone listening on the list that >>>>>>>> might be >>>>>>>> > available for little work integrating FreeIPA with Active >>>>>>>> Directory >>>>>>>> > (preferrably in the south east US.) I hope this isn't against the >>>>>>>> list >>>>>>>> > rules, I just thought one of you guys could help or point me in >>>>>>>> the right >>>>>>>> > direction. >>>>>>>> >>>>>>>> If you want some help, it is certainly not against list rules ;-) >>>>>>>> But in that >>>>>>>> case, it would be much better if you asked what exactly do you need. >>>>>>>> >>>>>>>> I'm not an AD expert, but a couple tips: If you are looking for >>>>>>>> cross-domain >>>>>>>> (cross-realm) trust, then you might be a bit disappointed, it is >>>>>>>> still in >>>>>>>> development, so it probably won't be 100% functional at this moment. >>>>>>>> >>>>>>>> If you are looking for something else, could you be a little more >>>>>>>> specific what >>>>>>>> it is? >>>>>>>> >>>>>>>> I also recommend starting with reading some doc: >>>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>>> >>>>>>>> Thanks >>>>>>>> Jan >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Jan 23 18:33:50 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 23 Jan 2012 11:33:50 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> Message-ID: <4F1DA80E.2070904@redhat.com> On 01/23/2012 11:34 AM, Jimmy wrote: > I did create the winsync user and it is an admin. > > I will fix the ip address(change to hostname,) I only did it that was > because this is currently a test system so I can figure out how to get > it all working. ok - once you do that, you can check the 389 errors log at /var/log/dirsrv/slapd-INST/errors to see if winsync is logging any errors > > On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson > wrote: > > On 01/23/2012 10:52 AM, Jimmy wrote: >> That's what I was thinking, and what I did, but it still doesn't >> replicate new users. This is the command I used: >> >> ipa-replica-manage connect --passsync --binddn >> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp --bindpw=******** >> --cacert /home/winsync/AD-server-cert.cer 192.168.201.150 -v > > Did you create the user > cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp? And does this user > have the rights to perform sync? (e.g. has to have replicator > rights, or be some sort of admin) - see > http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx - > the AD user must have replication rights and write rights. > > In addition, since this process uses SSL, you cannot use an IP > address, you must use a hostname, or the SSL cert hostname > checking (for MITM) will fail. > >> >> On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson >> > wrote: >> >> On 01/23/2012 10:19 AM, Jimmy wrote: >>> Here's what I found in the DS admin guide. Is this all >>> that's needed to create the sync agreement? >> Not with ipa - you should use the ipa-replica-manage command >> instead >> >>> Thanks. >>> >>> add sync agreement: >>> ldapmodify -x -D "cn=Directory Manager" -W >>> Enter LDAP Password: ******* >>> dn: cn=ExampleSyncAgreement,cn=sync >>> replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config >> it should be cn=replica, not cn=sync replica - does it use >> the latter in the Admin Guide? >> >>> changetype: add >>> objectclass: top >>> objectclass: nsDSWindowsReplicationAgreement >>> cn: ExampleSyncAgreement >>> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 >>> nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com >>> nsds7NewWinUserSyncEnabled: on >>> nsds7NewWinGroupSyncEnabled: on >>> nsds7WindowsDomain: ad1 >>> nsDS5ReplicaRoot: dc=example,dc=com >>> nsDS5ReplicaHost: ad1.windows-server.com >>> >>> nsDS5ReplicaPort: 389 >>> nsDS5ReplicaBindDN: cn=sync user,cn=config >>> nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA== >>> nsDS5ReplicaTransportInfo: TLS >>> winSyncInterval: 1200 >>> >>> On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson >>> > wrote: >>> >>> On 01/20/2012 01:08 PM, Jimmy wrote: >>>> That was it! I have passwords syncing, *BUT*(at the >>>> risk of sounding stupid)-- is it not possible to also >>>> sync(add) the users from AD to DS? >>> Yes, it is. Just configure IPA Windows Sync >>> >>>> I created a new user in AD and it doesn't propogate to >>>> DS, just says: >>>> >>>> attempting to sync password for testuser3 >>>> searching for (ntuserdomainid=testuser3) >>>> There are no entries that match: testuser3 >>>> deferring password change for testuser3 >>>> >>>> On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson >>>> > wrote: >>>> >>>> On 01/20/2012 12:46 PM, Jimmy wrote: >>>>> Getting close here... Now I see this message in >>>>> the sync log file: >>>>> >>>>> attempting to sync password for testuser >>>>> searching for (ntuserdomainid=testuser) >>>>> ldap error in queryusername >>>>> 32: no such object >>>>> deferring password change for testuser >>>> This usually means the search base is incorrect or >>>> not found. You can look at the 389 access log to >>>> see what it was using as the search criteria. >>>> >>>>> >>>>> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson >>>>> > >>>>> wrote: >>>>> >>>>> On 01/20/2012 10:23 AM, Jimmy wrote: >>>>>> You are correct. I had installed as an >>>>>> Enterprise root, but the doc I was >>>>>> reading(original link) seemed to say that I >>>>>> had to do the certreq manually, my bad. I >>>>>> think I'm getting closer I can establish an >>>>>> openssl connection from DS to AD but I get >>>>>> these errors: >>>>>> >>>>>> openssl s_client -connect >>>>>> 192.168.201.150:636 >>>>>> -showcerts >>>>>> -CAfile dsca.crt >>>>>> CONNECTED(00000003) >>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>> verify error:num=20:unable to get local >>>>>> issuer certificate >>>>>> verify return:1 >>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>> verify error:num=27:certificate not trusted >>>>>> verify return:1 >>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>> verify error:num=21:unable to verify the >>>>>> first certificate >>>>>> verify return:1 >>>>>> >>>>>> I thought I had imported the cert from AD but >>>>>> it doesn't seem so. I'm still researching but >>>>>> if you guys have a suggestion let me know. >>>>> Is dsca.crt the CA that issued the DS server >>>>> cert? If so, that won't work. You need the >>>>> CA cert from the CA that issued the AD server >>>>> cert (i.e. the CA cert from the MS Enterprise >>>>> Root CA). >>>>> >>>>>> -J >>>>>> >>>>>> On Thu, Jan 19, 2012 at 5:04 PM, Rich >>>>>> Megginson >>>>> > wrote: >>>>>> >>>>>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>>>>> ok. I started from scratch this week on >>>>>>> this and I think I've got the right doc >>>>>>> and understand better where this is >>>>>>> going. My problem now is that when >>>>>>> configuring SSL on the AD server (step c >>>>>>> in this url: >>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>>>> >>>>>>> I get this error: >>>>>>> >>>>>>> certreq -submit request.req certnew.cer >>>>>>> Active Directory Enrollment Policy >>>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>>>> ldap: >>>>>>> RequestId: 3 >>>>>>> RequestId: "3" >>>>>>> Certificate not issued (Denied) Denied >>>>>>> by Policy Module 0x80094801, The >>>>>>> request does not contain a certificate >>>>>>> template extension or the >>>>>>> CertificateTemplate request attribute. >>>>>>> The request contains no certificate >>>>>>> template information. 0x80094801 >>>>>>> (-2146875391 ) >>>>>>> Certificate Request Processor: The >>>>>>> request contains no certificate template >>>>>>> information. 0x80094801 (-2146875391 >>>>>>> ) >>>>>>> Denied by Policy Module 0x80094801, The >>>>>>> request does not contain a certificate >>>>>>> template extension or the >>>>>>> CertificateTemplate request attribute. >>>>>>> >>>>>>> The RH doc says to use the browser if an >>>>>>> error occurs and IIS is running but I'm >>>>>>> not running IIS. I researched that error >>>>>>> but didn't find anything that helps with >>>>>>> FreeIPA and passsync. >>>>>> Hmm - try installing Microsoft >>>>>> Certificate Authority in Enterprise Root >>>>>> CA mode - it will usually automatically >>>>>> create and install the AD server cert. >>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>>> >>>>>> >>>>>>> >>>>>>> Jimmy >>>>>>> >>>>>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich >>>>>>> Megginson >>>>>> > wrote: >>>>>>> >>>>>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>>>>>> We need to be able to replicate >>>>>>>> user/pass between Windows 2008 AD >>>>>>>> and FreeIPA. >>>>>>> >>>>>>> That's what IPA Windows Sync is >>>>>>> supposed to do. >>>>>>> >>>>>>> >>>>>>>> I have followed many different >>>>>>>> documents and posted here about it >>>>>>>> and from what I've read and >>>>>>>> procedures I've followed we are >>>>>>>> unable to accomplish this. >>>>>>> >>>>>>> What have you tried, and what >>>>>>> problems have you run into? >>>>>>> >>>>>>>> It doesn't need to be a full trust. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> On Tue, Jan 10, 2012 at 3:03 AM, >>>>>>>> Jan Zelen? >>>>>>> > wrote: >>>>>>>> >>>>>>>> > Just wondering if there was >>>>>>>> anyone listening on the list >>>>>>>> that might be >>>>>>>> > available for little work >>>>>>>> integrating FreeIPA with Active >>>>>>>> Directory >>>>>>>> > (preferrably in the south >>>>>>>> east US.) I hope this isn't >>>>>>>> against the list >>>>>>>> > rules, I just thought one of >>>>>>>> you guys could help or point me >>>>>>>> in the right >>>>>>>> > direction. >>>>>>>> >>>>>>>> If you want some help, it is >>>>>>>> certainly not against list >>>>>>>> rules ;-) But in that >>>>>>>> case, it would be much better >>>>>>>> if you asked what exactly do >>>>>>>> you need. >>>>>>>> >>>>>>>> I'm not an AD expert, but a >>>>>>>> couple tips: If you are looking >>>>>>>> for cross-domain >>>>>>>> (cross-realm) trust, then you >>>>>>>> might be a bit disappointed, it >>>>>>>> is still in >>>>>>>> development, so it probably >>>>>>>> won't be 100% functional at >>>>>>>> this moment. >>>>>>>> >>>>>>>> If you are looking for >>>>>>>> something else, could you be a >>>>>>>> little more specific what >>>>>>>> it is? >>>>>>>> >>>>>>>> I also recommend starting with >>>>>>>> reading some doc: >>>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>>> >>>>>>>> Thanks >>>>>>>> Jan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-users mailing list >>>>>>>> Freeipa-users at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g17jimmy at gmail.com Tue Jan 24 18:03:38 2012 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 24 Jan 2012 13:03:38 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F1DA80E.2070904@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> <4F1DA80E.2070904@redhat.com> Message-ID: Ok, I just realized that I only have passsync and not winsync, stupid oversight, but now that I know it I need to get winsync. Is there a location to download binaries or must I compile from source? I see the binaries for passsync on the directory server project downloads but I don't see the same for winsync. Thanks, Jim On Mon, Jan 23, 2012 at 1:33 PM, Rich Megginson wrote: > ** > On 01/23/2012 11:34 AM, Jimmy wrote: > > I did create the winsync user and it is an admin. > > I will fix the ip address(change to hostname,) I only did it that was > because this is currently a test system so I can figure out how to get it > all working. > > ok - once you do that, you can check the 389 errors log at > /var/log/dirsrv/slapd-INST/errors to see if winsync is logging any errors > > > On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson wrote: > >> On 01/23/2012 10:52 AM, Jimmy wrote: >> >> That's what I was thinking, and what I did, but it still doesn't >> replicate new users. This is the command I used: >> >> ipa-replica-manage connect --passsync --binddn >> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp --bindpw=******** --cacert >> /home/winsync/AD-server-cert.cer 192.168.201.150 -v >> >> >> Did you create the user cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp? And >> does this user have the rights to perform sync? (e.g. has to have >> replicator rights, or be some sort of admin) - see >> http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx - the >> AD user must have replication rights and write rights. >> >> In addition, since this process uses SSL, you cannot use an IP address, >> you must use a hostname, or the SSL cert hostname checking (for MITM) will >> fail. >> >> >> On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson wrote: >> >>> On 01/23/2012 10:19 AM, Jimmy wrote: >>> >>> Here's what I found in the DS admin guide. Is this all that's needed to >>> create the sync agreement? >>> >>> Not with ipa - you should use the ipa-replica-manage command instead >>> >>> Thanks. >>> >>> add sync agreement: >>> ldapmodify -x -D "cn=Directory Manager" -W >>> Enter LDAP Password: ******* >>> dn: cn=ExampleSyncAgreement,cn=sync >>> replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config >>> >>> it should be cn=replica, not cn=sync replica - does it use the latter >>> in the Admin Guide? >>> >>> changetype: add >>> objectclass: top >>> objectclass: nsDSWindowsReplicationAgreement >>> cn: ExampleSyncAgreement >>> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 >>> nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com >>> >>> nsds7NewWinUserSyncEnabled: on >>> nsds7NewWinGroupSyncEnabled: on >>> nsds7WindowsDomain: ad1 >>> nsDS5ReplicaRoot: dc=example,dc=com >>> nsDS5ReplicaHost: ad1.windows-server.com >>> nsDS5ReplicaPort: 389 >>> nsDS5ReplicaBindDN: cn=sync user,cn=config >>> nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA== >>> nsDS5ReplicaTransportInfo: TLS >>> winSyncInterval: 1200 >>> >>> On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson wrote: >>> >>>> On 01/20/2012 01:08 PM, Jimmy wrote: >>>> >>>> That was it! I have passwords syncing, *BUT*(at the risk of sounding >>>> stupid)-- is it not possible to also sync(add) the users from AD to DS? >>>> >>>> Yes, it is. Just configure IPA Windows Sync >>>> >>>> I created a new user in AD and it doesn't propogate to DS, just says: >>>> >>>> attempting to sync password for testuser3 >>>> searching for (ntuserdomainid=testuser3) >>>> There are no entries that match: testuser3 >>>> deferring password change for testuser3 >>>> >>>> On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson wrote: >>>> >>>>> On 01/20/2012 12:46 PM, Jimmy wrote: >>>>> >>>>> Getting close here... Now I see this message in the sync log file: >>>>> >>>>> attempting to sync password for testuser >>>>> searching for (ntuserdomainid=testuser) >>>>> ldap error in queryusername >>>>> 32: no such object >>>>> deferring password change for testuser >>>>> >>>>> This usually means the search base is incorrect or not found. You >>>>> can look at the 389 access log to see what it was using as the search >>>>> criteria. >>>>> >>>>> >>>>> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson wrote: >>>>> >>>>>> On 01/20/2012 10:23 AM, Jimmy wrote: >>>>>> >>>>>> You are correct. I had installed as an Enterprise root, but the doc I >>>>>> was reading(original link) seemed to say that I had to do the certreq >>>>>> manually, my bad. I think I'm getting closer I can establish an openssl >>>>>> connection from DS to AD but I get these errors: >>>>>> >>>>>> openssl s_client -connect 192.168.201.150:636 -showcerts -CAfile >>>>>> dsca.crt >>>>>> CONNECTED(00000003) >>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>> verify error:num=20:unable to get local issuer certificate >>>>>> verify return:1 >>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>> verify error:num=27:certificate not trusted >>>>>> verify return:1 >>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>> verify error:num=21:unable to verify the first certificate >>>>>> verify return:1 >>>>>> >>>>>> I thought I had imported the cert from AD but it doesn't seem so. >>>>>> I'm still researching but if you guys have a suggestion let me know. >>>>>> >>>>>> Is dsca.crt the CA that issued the DS server cert? If so, that >>>>>> won't work. You need the CA cert from the CA that issued the AD server >>>>>> cert (i.e. the CA cert from the MS Enterprise Root CA). >>>>>> >>>>>> -J >>>>>> >>>>>> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson >>>>> > wrote: >>>>>> >>>>>>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>>>>> >>>>>>> ok. I started from scratch this week on this and I think I've got >>>>>>> the right doc and understand better where this is going. My problem now is >>>>>>> that when configuring SSL on the AD server (step c in this url: >>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>>>> >>>>>>> I get this error: >>>>>>> >>>>>>> certreq -submit request.req certnew.cer >>>>>>> Active Directory Enrollment Policy >>>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>>>> ldap: >>>>>>> RequestId: 3 >>>>>>> RequestId: "3" >>>>>>> Certificate not issued (Denied) Denied by Policy Module 0x80094801, >>>>>>> The request does not contain a certificate template extension or the >>>>>>> CertificateTemplate request attribute. >>>>>>> The request contains no certificate template information. >>>>>>> 0x80094801 (-2146875391) >>>>>>> Certificate Request Processor: The request contains no certificate >>>>>>> template information. 0x80094801 (-2146875391) >>>>>>> Denied by Policy Module 0x80094801, The request does not contain a >>>>>>> certificate template extension or the CertificateTemplate request attribute. >>>>>>> >>>>>>> The RH doc says to use the browser if an error occurs and IIS is >>>>>>> running but I'm not running IIS. I researched that error but didn't find >>>>>>> anything that helps with FreeIPA and passsync. >>>>>>> >>>>>>> Hmm - try installing Microsoft Certificate Authority in Enterprise >>>>>>> Root CA mode - it will usually automatically create and install the AD >>>>>>> server cert. >>>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>>>> >>>>>>> >>>>>>> Jimmy >>>>>>> >>>>>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson >>>>>> > wrote: >>>>>>> >>>>>>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>>>>>> >>>>>>>> We need to be able to replicate user/pass between Windows 2008 AD >>>>>>>> and FreeIPA. >>>>>>>> >>>>>>>> >>>>>>>> That's what IPA Windows Sync is supposed to do. >>>>>>>> >>>>>>>> >>>>>>>> I have followed many different documents and posted here about it >>>>>>>> and from what I've read and procedures I've followed we are unable to >>>>>>>> accomplish this. >>>>>>>> >>>>>>>> >>>>>>>> What have you tried, and what problems have you run into? >>>>>>>> >>>>>>>> It doesn't need to be a full trust. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: >>>>>>>> >>>>>>>>> > Just wondering if there was anyone listening on the list that >>>>>>>>> might be >>>>>>>>> > available for little work integrating FreeIPA with Active >>>>>>>>> Directory >>>>>>>>> > (preferrably in the south east US.) I hope this isn't against >>>>>>>>> the list >>>>>>>>> > rules, I just thought one of you guys could help or point me in >>>>>>>>> the right >>>>>>>>> > direction. >>>>>>>>> >>>>>>>>> If you want some help, it is certainly not against list rules >>>>>>>>> ;-) But in that >>>>>>>>> case, it would be much better if you asked what exactly do you >>>>>>>>> need. >>>>>>>>> >>>>>>>>> I'm not an AD expert, but a couple tips: If you are looking for >>>>>>>>> cross-domain >>>>>>>>> (cross-realm) trust, then you might be a bit disappointed, it is >>>>>>>>> still in >>>>>>>>> development, so it probably won't be 100% functional at this >>>>>>>>> moment. >>>>>>>>> >>>>>>>>> If you are looking for something else, could you be a little more >>>>>>>>> specific what >>>>>>>>> it is? >>>>>>>>> >>>>>>>>> I also recommend starting with reading some doc: >>>>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Jan >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Jan 24 18:18:49 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 24 Jan 2012 11:18:49 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> <4F1DA80E.2070904@redhat.com> Message-ID: <4F1EF609.2040007@redhat.com> On 01/24/2012 11:03 AM, Jimmy wrote: > Ok, I just realized that I only have passsync and not winsync, stupid > oversight, but now that I know it I need to get winsync. Is there a > location to download binaries or must I compile from source? I see the > binaries for passsync on the directory server project downloads but I > don't see the same for winsync. winsync is built-in to 389 - there isn't any additional component that you need to install. > > Thanks, > Jim > > On Mon, Jan 23, 2012 at 1:33 PM, Rich Megginson > wrote: > > On 01/23/2012 11:34 AM, Jimmy wrote: >> I did create the winsync user and it is an admin. >> >> I will fix the ip address(change to hostname,) I only did it that >> was because this is currently a test system so I can figure out >> how to get it all working. > ok - once you do that, you can check the 389 errors log at > /var/log/dirsrv/slapd-INST/errors to see if winsync is logging any > errors > >> >> On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson >> > wrote: >> >> On 01/23/2012 10:52 AM, Jimmy wrote: >>> That's what I was thinking, and what I did, but it still >>> doesn't replicate new users. This is the command I used: >>> >>> ipa-replica-manage connect --passsync --binddn >>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp --bindpw=******** >>> --cacert /home/winsync/AD-server-cert.cer 192.168.201.150 -v >> >> Did you create the user >> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp? And does this >> user have the rights to perform sync? (e.g. has to have >> replicator rights, or be some sort of admin) - see >> http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx >> - the AD user must have replication rights and write rights. >> >> In addition, since this process uses SSL, you cannot use an >> IP address, you must use a hostname, or the SSL cert hostname >> checking (for MITM) will fail. >> >>> >>> On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson >>> > wrote: >>> >>> On 01/23/2012 10:19 AM, Jimmy wrote: >>>> Here's what I found in the DS admin guide. Is this all >>>> that's needed to create the sync agreement? >>> Not with ipa - you should use the ipa-replica-manage >>> command instead >>> >>>> Thanks. >>>> >>>> add sync agreement: >>>> ldapmodify -x -D "cn=Directory Manager" -W >>>> Enter LDAP Password: ******* >>>> dn: cn=ExampleSyncAgreement,cn=sync >>>> replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config >>> it should be cn=replica, not cn=sync replica - does it >>> use the latter in the Admin Guide? >>> >>>> changetype: add >>>> objectclass: top >>>> objectclass: nsDSWindowsReplicationAgreement >>>> cn: ExampleSyncAgreement >>>> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 >>>> nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com >>>> nsds7NewWinUserSyncEnabled: on >>>> nsds7NewWinGroupSyncEnabled: on >>>> nsds7WindowsDomain: ad1 >>>> nsDS5ReplicaRoot: dc=example,dc=com >>>> nsDS5ReplicaHost: ad1.windows-server.com >>>> >>>> nsDS5ReplicaPort: 389 >>>> nsDS5ReplicaBindDN: cn=sync user,cn=config >>>> nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA== >>>> nsDS5ReplicaTransportInfo: TLS >>>> winSyncInterval: 1200 >>>> >>>> On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson >>>> > wrote: >>>> >>>> On 01/20/2012 01:08 PM, Jimmy wrote: >>>>> That was it! I have passwords syncing, *BUT*(at >>>>> the risk of sounding stupid)-- is it not possible >>>>> to also sync(add) the users from AD to DS? >>>> Yes, it is. Just configure IPA Windows Sync >>>> >>>>> I created a new user in AD and it doesn't >>>>> propogate to DS, just says: >>>>> >>>>> attempting to sync password for testuser3 >>>>> searching for (ntuserdomainid=testuser3) >>>>> There are no entries that match: testuser3 >>>>> deferring password change for testuser3 >>>>> >>>>> On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson >>>>> > >>>>> wrote: >>>>> >>>>> On 01/20/2012 12:46 PM, Jimmy wrote: >>>>>> Getting close here... Now I see this message >>>>>> in the sync log file: >>>>>> >>>>>> attempting to sync password for testuser >>>>>> searching for (ntuserdomainid=testuser) >>>>>> ldap error in queryusername >>>>>> 32: no such object >>>>>> deferring password change for testuser >>>>> This usually means the search base is >>>>> incorrect or not found. You can look at the >>>>> 389 access log to see what it was using as the >>>>> search criteria. >>>>> >>>>>> >>>>>> On Fri, Jan 20, 2012 at 12:23 PM, Rich >>>>>> Megginson >>>>> > wrote: >>>>>> >>>>>> On 01/20/2012 10:23 AM, Jimmy wrote: >>>>>>> You are correct. I had installed as an >>>>>>> Enterprise root, but the doc I was >>>>>>> reading(original link) seemed to say >>>>>>> that I had to do the certreq manually, >>>>>>> my bad. I think I'm getting closer I can >>>>>>> establish an openssl connection from DS >>>>>>> to AD but I get these errors: >>>>>>> >>>>>>> openssl s_client -connect >>>>>>> 192.168.201.150:636 >>>>>>> -showcerts >>>>>>> -CAfile dsca.crt >>>>>>> CONNECTED(00000003) >>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>> verify error:num=20:unable to get local >>>>>>> issuer certificate >>>>>>> verify return:1 >>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>> verify error:num=27:certificate not trusted >>>>>>> verify return:1 >>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>> verify error:num=21:unable to verify the >>>>>>> first certificate >>>>>>> verify return:1 >>>>>>> >>>>>>> I thought I had imported the cert from >>>>>>> AD but it doesn't seem so. I'm still >>>>>>> researching but if you guys have a >>>>>>> suggestion let me know. >>>>>> Is dsca.crt the CA that issued the DS >>>>>> server cert? If so, that won't work. >>>>>> You need the CA cert from the CA that >>>>>> issued the AD server cert (i.e. the CA >>>>>> cert from the MS Enterprise Root CA). >>>>>> >>>>>>> -J >>>>>>> >>>>>>> On Thu, Jan 19, 2012 at 5:04 PM, Rich >>>>>>> Megginson >>>>>> > wrote: >>>>>>> >>>>>>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>>>>>> ok. I started from scratch this >>>>>>>> week on this and I think I've got >>>>>>>> the right doc and understand better >>>>>>>> where this is going. My problem now >>>>>>>> is that when configuring SSL on the >>>>>>>> AD server (step c in this url: >>>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>>>>> >>>>>>>> I get this error: >>>>>>>> >>>>>>>> certreq -submit request.req certnew.cer >>>>>>>> Active Directory Enrollment Policy >>>>>>>> >>>>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>>>>> ldap: >>>>>>>> RequestId: 3 >>>>>>>> RequestId: "3" >>>>>>>> Certificate not issued (Denied) >>>>>>>> Denied by Policy Module >>>>>>>> 0x80094801, The request does not >>>>>>>> contain a certificate template >>>>>>>> extension or the >>>>>>>> CertificateTemplate request attribute. >>>>>>>> The request contains no >>>>>>>> certificate template information. >>>>>>>> 0x80094801 (-2146875391 >>>>>>>> ) >>>>>>>> Certificate Request Processor: The >>>>>>>> request contains no certificate >>>>>>>> template information. 0x80094801 >>>>>>>> (-2146875391 ) >>>>>>>> Denied by Policy Module >>>>>>>> 0x80094801, The request does not >>>>>>>> contain a certificate template >>>>>>>> extension or the >>>>>>>> CertificateTemplate request attribute. >>>>>>>> >>>>>>>> The RH doc says to use the browser >>>>>>>> if an error occurs and IIS is >>>>>>>> running but I'm not running IIS. I >>>>>>>> researched that error but didn't >>>>>>>> find anything that helps with >>>>>>>> FreeIPA and passsync. >>>>>>> Hmm - try installing Microsoft >>>>>>> Certificate Authority in Enterprise >>>>>>> Root CA mode - it will usually >>>>>>> automatically create and install the >>>>>>> AD server cert. >>>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Jimmy >>>>>>>> >>>>>>>> On Wed, Jan 11, 2012 at 3:32 PM, >>>>>>>> Rich Megginson >>>>>>> > wrote: >>>>>>>> >>>>>>>> On 01/11/2012 11:22 AM, Jimmy >>>>>>>> wrote: >>>>>>>>> We need to be able to >>>>>>>>> replicate user/pass between >>>>>>>>> Windows 2008 AD and FreeIPA. >>>>>>>> >>>>>>>> That's what IPA Windows Sync is >>>>>>>> supposed to do. >>>>>>>> >>>>>>>> >>>>>>>>> I have followed many different >>>>>>>>> documents and posted here >>>>>>>>> about it and from what I've >>>>>>>>> read and procedures I've >>>>>>>>> followed we are unable to >>>>>>>>> accomplish this. >>>>>>>> >>>>>>>> What have you tried, and what >>>>>>>> problems have you run into? >>>>>>>> >>>>>>>>> It doesn't need to be a full >>>>>>>>> trust. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> On Tue, Jan 10, 2012 at 3:03 >>>>>>>>> AM, Jan Zelen? >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> > Just wondering if there >>>>>>>>> was anyone listening on >>>>>>>>> the list that might be >>>>>>>>> > available for little >>>>>>>>> work integrating FreeIPA >>>>>>>>> with Active Directory >>>>>>>>> > (preferrably in the >>>>>>>>> south east US.) I hope >>>>>>>>> this isn't against the list >>>>>>>>> > rules, I just thought >>>>>>>>> one of you guys could help >>>>>>>>> or point me in the right >>>>>>>>> > direction. >>>>>>>>> >>>>>>>>> If you want some help, it >>>>>>>>> is certainly not against >>>>>>>>> list rules ;-) But in that >>>>>>>>> case, it would be much >>>>>>>>> better if you asked what >>>>>>>>> exactly do you need. >>>>>>>>> >>>>>>>>> I'm not an AD expert, but >>>>>>>>> a couple tips: If you are >>>>>>>>> looking for cross-domain >>>>>>>>> (cross-realm) trust, then >>>>>>>>> you might be a bit >>>>>>>>> disappointed, it is still in >>>>>>>>> development, so it >>>>>>>>> probably won't be 100% >>>>>>>>> functional at this moment. >>>>>>>>> >>>>>>>>> If you are looking for >>>>>>>>> something else, could you >>>>>>>>> be a little more specific what >>>>>>>>> it is? >>>>>>>>> >>>>>>>>> I also recommend starting >>>>>>>>> with reading some doc: >>>>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Freeipa-users mailing list >>>>>>>>> Freeipa-users at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g17jimmy at gmail.com Tue Jan 24 18:25:21 2012 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 24 Jan 2012 13:25:21 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F1EF609.2040007@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> <4F1DA80E.2070904@redhat.com> <4F1EF609.2040007@redhat.com> Message-ID: ok, then I misread something just now. sorry. Thanks for straightening me up. - J On Tue, Jan 24, 2012 at 1:18 PM, Rich Megginson wrote: > ** > On 01/24/2012 11:03 AM, Jimmy wrote: > > Ok, I just realized that I only have passsync and not winsync, stupid > oversight, but now that I know it I need to get winsync. Is there a > location to download binaries or must I compile from source? I see the > binaries for passsync on the directory server project downloads but I don't > see the same for winsync. > > winsync is built-in to 389 - there isn't any additional component that you > need to install. > > > Thanks, > Jim > > On Mon, Jan 23, 2012 at 1:33 PM, Rich Megginson wrote: > >> On 01/23/2012 11:34 AM, Jimmy wrote: >> >> I did create the winsync user and it is an admin. >> >> I will fix the ip address(change to hostname,) I only did it that was >> because this is currently a test system so I can figure out how to get it >> all working. >> >> ok - once you do that, you can check the 389 errors log at >> /var/log/dirsrv/slapd-INST/errors to see if winsync is logging any errors >> >> >> On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson wrote: >> >>> On 01/23/2012 10:52 AM, Jimmy wrote: >>> >>> That's what I was thinking, and what I did, but it still doesn't >>> replicate new users. This is the command I used: >>> >>> ipa-replica-manage connect --passsync --binddn >>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp --bindpw=******** --cacert >>> /home/winsync/AD-server-cert.cer 192.168.201.150 -v >>> >>> >>> Did you create the user cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp? >>> And does this user have the rights to perform sync? (e.g. has to have >>> replicator rights, or be some sort of admin) - see >>> http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx - the >>> AD user must have replication rights and write rights. >>> >>> In addition, since this process uses SSL, you cannot use an IP address, >>> you must use a hostname, or the SSL cert hostname checking (for MITM) will >>> fail. >>> >>> >>> On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson wrote: >>> >>>> On 01/23/2012 10:19 AM, Jimmy wrote: >>>> >>>> Here's what I found in the DS admin guide. Is this all that's needed to >>>> create the sync agreement? >>>> >>>> Not with ipa - you should use the ipa-replica-manage command instead >>>> >>>> Thanks. >>>> >>>> add sync agreement: >>>> ldapmodify -x -D "cn=Directory Manager" -W >>>> Enter LDAP Password: ******* >>>> dn: cn=ExampleSyncAgreement,cn=sync >>>> replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config >>>> >>>> it should be cn=replica, not cn=sync replica - does it use the latter >>>> in the Admin Guide? >>>> >>>> changetype: add >>>> objectclass: top >>>> objectclass: nsDSWindowsReplicationAgreement >>>> cn: ExampleSyncAgreement >>>> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 >>>> nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com >>>> >>>> nsds7NewWinUserSyncEnabled: on >>>> nsds7NewWinGroupSyncEnabled: on >>>> nsds7WindowsDomain: ad1 >>>> nsDS5ReplicaRoot: dc=example,dc=com >>>> nsDS5ReplicaHost: ad1.windows-server.com >>>> nsDS5ReplicaPort: 389 >>>> nsDS5ReplicaBindDN: cn=sync user,cn=config >>>> nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA== >>>> nsDS5ReplicaTransportInfo: TLS >>>> winSyncInterval: 1200 >>>> >>>> On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson wrote: >>>> >>>>> On 01/20/2012 01:08 PM, Jimmy wrote: >>>>> >>>>> That was it! I have passwords syncing, *BUT*(at the risk of sounding >>>>> stupid)-- is it not possible to also sync(add) the users from AD to DS? >>>>> >>>>> Yes, it is. Just configure IPA Windows Sync >>>>> >>>>> I created a new user in AD and it doesn't propogate to DS, just says: >>>>> >>>>> attempting to sync password for testuser3 >>>>> searching for (ntuserdomainid=testuser3) >>>>> There are no entries that match: testuser3 >>>>> deferring password change for testuser3 >>>>> >>>>> On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson wrote: >>>>> >>>>>> On 01/20/2012 12:46 PM, Jimmy wrote: >>>>>> >>>>>> Getting close here... Now I see this message in the sync log file: >>>>>> >>>>>> attempting to sync password for testuser >>>>>> searching for (ntuserdomainid=testuser) >>>>>> ldap error in queryusername >>>>>> 32: no such object >>>>>> deferring password change for testuser >>>>>> >>>>>> This usually means the search base is incorrect or not found. You >>>>>> can look at the 389 access log to see what it was using as the search >>>>>> criteria. >>>>>> >>>>>> >>>>>> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson >>>>> > wrote: >>>>>> >>>>>>> On 01/20/2012 10:23 AM, Jimmy wrote: >>>>>>> >>>>>>> You are correct. I had installed as an Enterprise root, but the doc >>>>>>> I was reading(original link) seemed to say that I had to do the certreq >>>>>>> manually, my bad. I think I'm getting closer I can establish an openssl >>>>>>> connection from DS to AD but I get these errors: >>>>>>> >>>>>>> openssl s_client -connect 192.168.201.150:636 -showcerts -CAfile >>>>>>> dsca.crt >>>>>>> CONNECTED(00000003) >>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>> verify error:num=20:unable to get local issuer certificate >>>>>>> verify return:1 >>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>> verify error:num=27:certificate not trusted >>>>>>> verify return:1 >>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>> verify error:num=21:unable to verify the first certificate >>>>>>> verify return:1 >>>>>>> >>>>>>> I thought I had imported the cert from AD but it doesn't seem so. >>>>>>> I'm still researching but if you guys have a suggestion let me know. >>>>>>> >>>>>>> Is dsca.crt the CA that issued the DS server cert? If so, that >>>>>>> won't work. You need the CA cert from the CA that issued the AD server >>>>>>> cert (i.e. the CA cert from the MS Enterprise Root CA). >>>>>>> >>>>>>> -J >>>>>>> >>>>>>> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson < >>>>>>> rmeggins at redhat.com> wrote: >>>>>>> >>>>>>>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>>>>>> >>>>>>>> ok. I started from scratch this week on this and I think I've got >>>>>>>> the right doc and understand better where this is going. My problem now is >>>>>>>> that when configuring SSL on the AD server (step c in this url: >>>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>>>>> >>>>>>>> I get this error: >>>>>>>> >>>>>>>> certreq -submit request.req certnew.cer >>>>>>>> Active Directory Enrollment Policy >>>>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>>>>> ldap: >>>>>>>> RequestId: 3 >>>>>>>> RequestId: "3" >>>>>>>> Certificate not issued (Denied) Denied by Policy Module >>>>>>>> 0x80094801, The request does not contain a certificate template extension >>>>>>>> or the CertificateTemplate request attribute. >>>>>>>> The request contains no certificate template information. >>>>>>>> 0x80094801 (-2146875391) >>>>>>>> Certificate Request Processor: The request contains no certificate >>>>>>>> template information. 0x80094801 (-2146875391) >>>>>>>> Denied by Policy Module 0x80094801, The request does not contain >>>>>>>> a certificate template extension or the CertificateTemplate request >>>>>>>> attribute. >>>>>>>> >>>>>>>> The RH doc says to use the browser if an error occurs and IIS is >>>>>>>> running but I'm not running IIS. I researched that error but didn't find >>>>>>>> anything that helps with FreeIPA and passsync. >>>>>>>> >>>>>>>> Hmm - try installing Microsoft Certificate Authority in Enterprise >>>>>>>> Root CA mode - it will usually automatically create and install the AD >>>>>>>> server cert. >>>>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>>>>> >>>>>>>> >>>>>>>> Jimmy >>>>>>>> >>>>>>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson < >>>>>>>> rmeggins at redhat.com> wrote: >>>>>>>> >>>>>>>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>>>>>>> >>>>>>>>> We need to be able to replicate user/pass between Windows 2008 AD >>>>>>>>> and FreeIPA. >>>>>>>>> >>>>>>>>> >>>>>>>>> That's what IPA Windows Sync is supposed to do. >>>>>>>>> >>>>>>>>> >>>>>>>>> I have followed many different documents and posted here about it >>>>>>>>> and from what I've read and procedures I've followed we are unable to >>>>>>>>> accomplish this. >>>>>>>>> >>>>>>>>> >>>>>>>>> What have you tried, and what problems have you run into? >>>>>>>>> >>>>>>>>> It doesn't need to be a full trust. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: >>>>>>>>> >>>>>>>>>> > Just wondering if there was anyone listening on the list that >>>>>>>>>> might be >>>>>>>>>> > available for little work integrating FreeIPA with Active >>>>>>>>>> Directory >>>>>>>>>> > (preferrably in the south east US.) I hope this isn't against >>>>>>>>>> the list >>>>>>>>>> > rules, I just thought one of you guys could help or point me in >>>>>>>>>> the right >>>>>>>>>> > direction. >>>>>>>>>> >>>>>>>>>> If you want some help, it is certainly not against list rules >>>>>>>>>> ;-) But in that >>>>>>>>>> case, it would be much better if you asked what exactly do you >>>>>>>>>> need. >>>>>>>>>> >>>>>>>>>> I'm not an AD expert, but a couple tips: If you are looking for >>>>>>>>>> cross-domain >>>>>>>>>> (cross-realm) trust, then you might be a bit disappointed, it is >>>>>>>>>> still in >>>>>>>>>> development, so it probably won't be 100% functional at this >>>>>>>>>> moment. >>>>>>>>>> >>>>>>>>>> If you are looking for something else, could you be a little more >>>>>>>>>> specific what >>>>>>>>>> it is? >>>>>>>>>> >>>>>>>>>> I also recommend starting with reading some doc: >>>>>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g17jimmy at gmail.com Tue Jan 24 20:26:51 2012 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 24 Jan 2012 15:26:51 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F1EF609.2040007@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> <4F1DA80E.2070904@redhat.com> <4F1EF609.2040007@redhat.com> Message-ID: The sync is still not working so I was going back through the docs to see what I missed. I know this is from an older version of IPA but I was looking here: http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html#sect-Installation_and_Deployment_Guide-Prerequisites-Setting_up_Active_Directory and used this method to get the AD certificate server cert. 1. Navigate to My Network Places and drill down to the CA distribution point. On Windows 2003 Server this is typically C:\WINDOWS\system32\certsrv\CertEnroll\ 2. Double-click the security certificate file (.crt file) to display the *Certificate* dialog box. 3. On the *Details* tab, click *Copy to File* to start the *Certificate Export Wizard*. 4. Click *Next*, select *Base-64 encoded X.509 (.CER)* and then click * Next*. 5. Specify a suitable directory and file name for the exported file. The file name is not important. Click *Next* to export the certificate, and then click *Finish*. You should receive a message stating that the export was successful. 6. Click *OK* to exit the wizard. But when I run the command to create the sync agreement(pointing to the cert I got in the step above) the ssl connection fails and if I look at tcpdump of the connection I see that the AD server is not sending the cert that I have imported with the sync agreement. I have used certutil to verify that I have the same cert(same serial number and same public key) in the 389 server as the one in the AD server ( C:\WINDOWS\system32\ certsrv\CertEnroll\). The AD server is sending a completely different cert, and I have been unable to find the cert in the certificate stores on the AD server so I'm not sure where the bogus cert is coming from. Before I added the certificate services role the certsrv\certenroll directory was not present so I know this was created when I added that role to the AD server. The pcap can be seen here: http://www.pcapr.net/view/g17jimmy/2012/0/2/11/ldaps3.pcap.html (sorry, registration required on that site, I didn't have anywhere else to put it.) Any idea why AD would be sending me the wrong cert and where it's coming from? Yes, I know this isn't MS just trying to get these 2 systems to talk ;). On Tue, Jan 24, 2012 at 1:18 PM, Rich Megginson wrote: > ** > On 01/24/2012 11:03 AM, Jimmy wrote: > > Ok, I just realized that I only have passsync and not winsync, stupid > oversight, but now that I know it I need to get winsync. Is there a > location to download binaries or must I compile from source? I see the > binaries for passsync on the directory server project downloads but I don't > see the same for winsync. > > winsync is built-in to 389 - there isn't any additional component that you > need to install. > > > Thanks, > Jim > > On Mon, Jan 23, 2012 at 1:33 PM, Rich Megginson wrote: > >> On 01/23/2012 11:34 AM, Jimmy wrote: >> >> I did create the winsync user and it is an admin. >> >> I will fix the ip address(change to hostname,) I only did it that was >> because this is currently a test system so I can figure out how to get it >> all working. >> >> ok - once you do that, you can check the 389 errors log at >> /var/log/dirsrv/slapd-INST/errors to see if winsync is logging any errors >> >> >> On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson wrote: >> >>> On 01/23/2012 10:52 AM, Jimmy wrote: >>> >>> That's what I was thinking, and what I did, but it still doesn't >>> replicate new users. This is the command I used: >>> >>> ipa-replica-manage connect --passsync --binddn >>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp --bindpw=******** --cacert >>> /home/winsync/AD-server-cert.cer 192.168.201.150 -v >>> >>> >>> Did you create the user cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp? >>> And does this user have the rights to perform sync? (e.g. has to have >>> replicator rights, or be some sort of admin) - see >>> http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx - the >>> AD user must have replication rights and write rights. >>> >>> In addition, since this process uses SSL, you cannot use an IP address, >>> you must use a hostname, or the SSL cert hostname checking (for MITM) will >>> fail. >>> >>> >>> On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson wrote: >>> >>>> On 01/23/2012 10:19 AM, Jimmy wrote: >>>> >>>> Here's what I found in the DS admin guide. Is this all that's needed to >>>> create the sync agreement? >>>> >>>> Not with ipa - you should use the ipa-replica-manage command instead >>>> >>>> Thanks. >>>> >>>> add sync agreement: >>>> ldapmodify -x -D "cn=Directory Manager" -W >>>> Enter LDAP Password: ******* >>>> dn: cn=ExampleSyncAgreement,cn=sync >>>> replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config >>>> >>>> it should be cn=replica, not cn=sync replica - does it use the latter >>>> in the Admin Guide? >>>> >>>> changetype: add >>>> objectclass: top >>>> objectclass: nsDSWindowsReplicationAgreement >>>> cn: ExampleSyncAgreement >>>> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 >>>> nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com >>>> >>>> nsds7NewWinUserSyncEnabled: on >>>> nsds7NewWinGroupSyncEnabled: on >>>> nsds7WindowsDomain: ad1 >>>> nsDS5ReplicaRoot: dc=example,dc=com >>>> nsDS5ReplicaHost: ad1.windows-server.com >>>> nsDS5ReplicaPort: 389 >>>> nsDS5ReplicaBindDN: cn=sync user,cn=config >>>> nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA== >>>> nsDS5ReplicaTransportInfo: TLS >>>> winSyncInterval: 1200 >>>> >>>> On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson wrote: >>>> >>>>> On 01/20/2012 01:08 PM, Jimmy wrote: >>>>> >>>>> That was it! I have passwords syncing, *BUT*(at the risk of sounding >>>>> stupid)-- is it not possible to also sync(add) the users from AD to DS? >>>>> >>>>> Yes, it is. Just configure IPA Windows Sync >>>>> >>>>> I created a new user in AD and it doesn't propogate to DS, just says: >>>>> >>>>> attempting to sync password for testuser3 >>>>> searching for (ntuserdomainid=testuser3) >>>>> There are no entries that match: testuser3 >>>>> deferring password change for testuser3 >>>>> >>>>> On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson wrote: >>>>> >>>>>> On 01/20/2012 12:46 PM, Jimmy wrote: >>>>>> >>>>>> Getting close here... Now I see this message in the sync log file: >>>>>> >>>>>> attempting to sync password for testuser >>>>>> searching for (ntuserdomainid=testuser) >>>>>> ldap error in queryusername >>>>>> 32: no such object >>>>>> deferring password change for testuser >>>>>> >>>>>> This usually means the search base is incorrect or not found. You >>>>>> can look at the 389 access log to see what it was using as the search >>>>>> criteria. >>>>>> >>>>>> >>>>>> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson >>>>> > wrote: >>>>>> >>>>>>> On 01/20/2012 10:23 AM, Jimmy wrote: >>>>>>> >>>>>>> You are correct. I had installed as an Enterprise root, but the doc >>>>>>> I was reading(original link) seemed to say that I had to do the certreq >>>>>>> manually, my bad. I think I'm getting closer I can establish an openssl >>>>>>> connection from DS to AD but I get these errors: >>>>>>> >>>>>>> openssl s_client -connect 192.168.201.150:636 -showcerts -CAfile >>>>>>> dsca.crt >>>>>>> CONNECTED(00000003) >>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>> verify error:num=20:unable to get local issuer certificate >>>>>>> verify return:1 >>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>> verify error:num=27:certificate not trusted >>>>>>> verify return:1 >>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>> verify error:num=21:unable to verify the first certificate >>>>>>> verify return:1 >>>>>>> >>>>>>> I thought I had imported the cert from AD but it doesn't seem so. >>>>>>> I'm still researching but if you guys have a suggestion let me know. >>>>>>> >>>>>>> Is dsca.crt the CA that issued the DS server cert? If so, that >>>>>>> won't work. You need the CA cert from the CA that issued the AD server >>>>>>> cert (i.e. the CA cert from the MS Enterprise Root CA). >>>>>>> >>>>>>> -J >>>>>>> >>>>>>> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson < >>>>>>> rmeggins at redhat.com> wrote: >>>>>>> >>>>>>>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>>>>>> >>>>>>>> ok. I started from scratch this week on this and I think I've got >>>>>>>> the right doc and understand better where this is going. My problem now is >>>>>>>> that when configuring SSL on the AD server (step c in this url: >>>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>>>>> >>>>>>>> I get this error: >>>>>>>> >>>>>>>> certreq -submit request.req certnew.cer >>>>>>>> Active Directory Enrollment Policy >>>>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>>>>> ldap: >>>>>>>> RequestId: 3 >>>>>>>> RequestId: "3" >>>>>>>> Certificate not issued (Denied) Denied by Policy Module >>>>>>>> 0x80094801, The request does not contain a certificate template extension >>>>>>>> or the CertificateTemplate request attribute. >>>>>>>> The request contains no certificate template information. >>>>>>>> 0x80094801 (-2146875391) >>>>>>>> Certificate Request Processor: The request contains no certificate >>>>>>>> template information. 0x80094801 (-2146875391) >>>>>>>> Denied by Policy Module 0x80094801, The request does not contain >>>>>>>> a certificate template extension or the CertificateTemplate request >>>>>>>> attribute. >>>>>>>> >>>>>>>> The RH doc says to use the browser if an error occurs and IIS is >>>>>>>> running but I'm not running IIS. I researched that error but didn't find >>>>>>>> anything that helps with FreeIPA and passsync. >>>>>>>> >>>>>>>> Hmm - try installing Microsoft Certificate Authority in Enterprise >>>>>>>> Root CA mode - it will usually automatically create and install the AD >>>>>>>> server cert. >>>>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>>>>> >>>>>>>> >>>>>>>> Jimmy >>>>>>>> >>>>>>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson < >>>>>>>> rmeggins at redhat.com> wrote: >>>>>>>> >>>>>>>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>>>>>>> >>>>>>>>> We need to be able to replicate user/pass between Windows 2008 AD >>>>>>>>> and FreeIPA. >>>>>>>>> >>>>>>>>> >>>>>>>>> That's what IPA Windows Sync is supposed to do. >>>>>>>>> >>>>>>>>> >>>>>>>>> I have followed many different documents and posted here about it >>>>>>>>> and from what I've read and procedures I've followed we are unable to >>>>>>>>> accomplish this. >>>>>>>>> >>>>>>>>> >>>>>>>>> What have you tried, and what problems have you run into? >>>>>>>>> >>>>>>>>> It doesn't need to be a full trust. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: >>>>>>>>> >>>>>>>>>> > Just wondering if there was anyone listening on the list that >>>>>>>>>> might be >>>>>>>>>> > available for little work integrating FreeIPA with Active >>>>>>>>>> Directory >>>>>>>>>> > (preferrably in the south east US.) I hope this isn't against >>>>>>>>>> the list >>>>>>>>>> > rules, I just thought one of you guys could help or point me in >>>>>>>>>> the right >>>>>>>>>> > direction. >>>>>>>>>> >>>>>>>>>> If you want some help, it is certainly not against list rules >>>>>>>>>> ;-) But in that >>>>>>>>>> case, it would be much better if you asked what exactly do you >>>>>>>>>> need. >>>>>>>>>> >>>>>>>>>> I'm not an AD expert, but a couple tips: If you are looking for >>>>>>>>>> cross-domain >>>>>>>>>> (cross-realm) trust, then you might be a bit disappointed, it is >>>>>>>>>> still in >>>>>>>>>> development, so it probably won't be 100% functional at this >>>>>>>>>> moment. >>>>>>>>>> >>>>>>>>>> If you are looking for something else, could you be a little more >>>>>>>>>> specific what >>>>>>>>>> it is? >>>>>>>>>> >>>>>>>>>> I also recommend starting with reading some doc: >>>>>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Jan 24 20:29:20 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 24 Jan 2012 13:29:20 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> <4F1DA80E.2070904@redhat.com> <4F1EF609.2040007@redhat.com> Message-ID: <4F1F14A0.2090901@redhat.com> On 01/24/2012 01:26 PM, Jimmy wrote: > The sync is still not working so I was going back through the docs to > see what I missed. I know this is from an older version of IPA but I > was looking here: > http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html#sect-Installation_and_Deployment_Guide-Prerequisites-Setting_up_Active_Directory > > > and used this method to get the AD certificate server cert. You mean "CA cert" not "server cert", right? > > 1. > Navigate to My Network Places and drill down to the CA > distribution point. On Windows 2003 Server this is typically > |C:\WINDOWS\system32\certsrv\CertEnroll\| > 2. > Double-click the security certificate file (|.crt| file) to > display the *Certificate* dialog box. > 3. > On the *Details* tab, click *Copy to File* to start the > *Certificate Export Wizard*. > 4. > Click *Next*, select *Base-64 encoded X.509 (.CER)* and then > click *Next*. > 5. > Specify a suitable directory and file name for the exported > file. The file name is not important. Click *Next* to export the > certificate, and then click *Finish*. You should receive a > message stating that the export was successful. > 6. > Click *OK* to exit the wizard. > > But when I run the command to create the sync agreement(pointing to > the cert I got in the step above) the ssl connection fails and if I > look at tcpdump of the connection I see that the AD server is not > sending the cert that I have imported with the sync agreement. I have > used certutil to verify that I have the same cert(same serial number > and same public key) in the 389 server as the one in the AD server ( > C:\WINDOWS\system32\certsrv\CertEnroll\). The AD server is sending a > completely different cert, and I have been unable to find the cert in > the certificate stores on the AD server so I'm not sure where the > bogus cert is coming from. Before I added the certificate services > role the certsrv\certenroll directory was not present so I know this > was created when I added that role to the AD server. > > The pcap can be seen here: > http://www.pcapr.net/view/g17jimmy/2012/0/2/11/ldaps3.pcap.html (sorry, registration > required on that site, I didn't have anywhere else to put it.) Can you try fpaste.org? > > Any idea why AD would be sending me the wrong cert and where it's > coming from? Yes, I know this isn't MS just trying to get these 2 > systems to talk ;). > > On Tue, Jan 24, 2012 at 1:18 PM, Rich Megginson > wrote: > > On 01/24/2012 11:03 AM, Jimmy wrote: >> Ok, I just realized that I only have passsync and not winsync, >> stupid oversight, but now that I know it I need to get winsync. >> Is there a location to download binaries or must I compile from >> source? I see the binaries for passsync on the directory server >> project downloads but I don't see the same for winsync. > winsync is built-in to 389 - there isn't any additional component > that you need to install. > >> >> Thanks, >> Jim >> >> On Mon, Jan 23, 2012 at 1:33 PM, Rich Megginson >> > wrote: >> >> On 01/23/2012 11:34 AM, Jimmy wrote: >>> I did create the winsync user and it is an admin. >>> >>> I will fix the ip address(change to hostname,) I only did it >>> that was because this is currently a test system so I can >>> figure out how to get it all working. >> ok - once you do that, you can check the 389 errors log at >> /var/log/dirsrv/slapd-INST/errors to see if winsync is >> logging any errors >> >>> >>> On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson >>> > wrote: >>> >>> On 01/23/2012 10:52 AM, Jimmy wrote: >>>> That's what I was thinking, and what I did, but it >>>> still doesn't replicate new users. This is the command >>>> I used: >>>> >>>> ipa-replica-manage connect --passsync --binddn >>>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp >>>> --bindpw=******** --cacert >>>> /home/winsync/AD-server-cert.cer 192.168.201.150 -v >>> >>> Did you create the user >>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp? And does >>> this user have the rights to perform sync? (e.g. has to >>> have replicator rights, or be some sort of admin) - see >>> http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx >>> - the AD user must have replication rights and write rights. >>> >>> In addition, since this process uses SSL, you cannot use >>> an IP address, you must use a hostname, or the SSL cert >>> hostname checking (for MITM) will fail. >>> >>>> >>>> On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson >>>> > wrote: >>>> >>>> On 01/23/2012 10:19 AM, Jimmy wrote: >>>>> Here's what I found in the DS admin guide. Is this >>>>> all that's needed to create the sync agreement? >>>> Not with ipa - you should use the >>>> ipa-replica-manage command instead >>>> >>>>> Thanks. >>>>> >>>>> add sync agreement: >>>>> ldapmodify -x -D "cn=Directory Manager" -W >>>>> Enter LDAP Password: ******* >>>>> dn: cn=ExampleSyncAgreement,cn=sync >>>>> replica,cn=dc=example\,dc=com,cn=mapping >>>>> tree,cn=config >>>> it should be cn=replica, not cn=sync replica - does >>>> it use the latter in the Admin Guide? >>>> >>>>> changetype: add >>>>> objectclass: top >>>>> objectclass: nsDSWindowsReplicationAgreement >>>>> cn: ExampleSyncAgreement >>>>> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 >>>>> nsds7DirectoryReplicaSubtree: >>>>> ou=People,dc=example,dc=com >>>>> nsds7NewWinUserSyncEnabled: on >>>>> nsds7NewWinGroupSyncEnabled: on >>>>> nsds7WindowsDomain: ad1 >>>>> nsDS5ReplicaRoot: dc=example,dc=com >>>>> nsDS5ReplicaHost: ad1.windows-server.com >>>>> >>>>> nsDS5ReplicaPort: 389 >>>>> nsDS5ReplicaBindDN: cn=sync user,cn=config >>>>> nsDS5ReplicaBindCredentials: >>>>> {DES}ffGad646dT0nnsT8nJOaMA== >>>>> nsDS5ReplicaTransportInfo: TLS >>>>> winSyncInterval: 1200 >>>>> >>>>> On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson >>>>> > >>>>> wrote: >>>>> >>>>> On 01/20/2012 01:08 PM, Jimmy wrote: >>>>>> That was it! I have passwords syncing, >>>>>> *BUT*(at the risk of sounding stupid)-- is it >>>>>> not possible to also sync(add) the users from >>>>>> AD to DS? >>>>> Yes, it is. Just configure IPA Windows Sync >>>>> >>>>>> I created a new user in AD and it doesn't >>>>>> propogate to DS, just says: >>>>>> >>>>>> attempting to sync password for testuser3 >>>>>> searching for (ntuserdomainid=testuser3) >>>>>> There are no entries that match: testuser3 >>>>>> deferring password change for testuser3 >>>>>> >>>>>> On Fri, Jan 20, 2012 at 2:46 PM, Rich >>>>>> Megginson >>>>> > wrote: >>>>>> >>>>>> On 01/20/2012 12:46 PM, Jimmy wrote: >>>>>>> Getting close here... Now I see this >>>>>>> message in the sync log file: >>>>>>> >>>>>>> attempting to sync password for testuser >>>>>>> searching for (ntuserdomainid=testuser) >>>>>>> ldap error in queryusername >>>>>>> 32: no such object >>>>>>> deferring password change for testuser >>>>>> This usually means the search base is >>>>>> incorrect or not found. You can look at >>>>>> the 389 access log to see what it was >>>>>> using as the search criteria. >>>>>> >>>>>>> >>>>>>> On Fri, Jan 20, 2012 at 12:23 PM, Rich >>>>>>> Megginson >>>>>> > wrote: >>>>>>> >>>>>>> On 01/20/2012 10:23 AM, Jimmy wrote: >>>>>>>> You are correct. I had installed as >>>>>>>> an Enterprise root, but the doc I >>>>>>>> was reading(original link) seemed >>>>>>>> to say that I had to do the certreq >>>>>>>> manually, my bad. I think I'm >>>>>>>> getting closer I can establish an >>>>>>>> openssl connection from DS to AD >>>>>>>> but I get these errors: >>>>>>>> >>>>>>>> openssl s_client -connect >>>>>>>> 192.168.201.150:636 >>>>>>>> >>>>>>>> -showcerts -CAfile dsca.crt >>>>>>>> CONNECTED(00000003) >>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>>> verify error:num=20:unable to get >>>>>>>> local issuer certificate >>>>>>>> verify return:1 >>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>>> verify error:num=27:certificate not >>>>>>>> trusted >>>>>>>> verify return:1 >>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>>> verify error:num=21:unable to >>>>>>>> verify the first certificate >>>>>>>> verify return:1 >>>>>>>> >>>>>>>> I thought I had imported the cert >>>>>>>> from AD but it doesn't seem so. I'm >>>>>>>> still researching but if you guys >>>>>>>> have a suggestion let me know. >>>>>>> Is dsca.crt the CA that issued the >>>>>>> DS server cert? If so, that won't >>>>>>> work. You need the CA cert from the >>>>>>> CA that issued the AD server cert >>>>>>> (i.e. the CA cert from the MS >>>>>>> Enterprise Root CA). >>>>>>> >>>>>>>> -J >>>>>>>> >>>>>>>> On Thu, Jan 19, 2012 at 5:04 PM, >>>>>>>> Rich Megginson >>>>>>> > wrote: >>>>>>>> >>>>>>>> On 01/19/2012 02:59 PM, Jimmy >>>>>>>> wrote: >>>>>>>>> ok. I started from scratch >>>>>>>>> this week on this and I think >>>>>>>>> I've got the right doc and >>>>>>>>> understand better where this >>>>>>>>> is going. My problem now is >>>>>>>>> that when configuring SSL on >>>>>>>>> the AD server (step c in this >>>>>>>>> url: >>>>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>>>>>> >>>>>>>>> I get this error: >>>>>>>>> >>>>>>>>> certreq -submit request.req >>>>>>>>> certnew.cer >>>>>>>>> Active Directory Enrollment Policy >>>>>>>>> >>>>>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>>>>>> ldap: >>>>>>>>> RequestId: 3 >>>>>>>>> RequestId: "3" >>>>>>>>> Certificate not issued >>>>>>>>> (Denied) Denied by Policy >>>>>>>>> Module 0x80094801, The >>>>>>>>> request does not contain a >>>>>>>>> certificate template extension >>>>>>>>> or the CertificateTemplate >>>>>>>>> request attribute. >>>>>>>>> The request contains no >>>>>>>>> certificate template >>>>>>>>> information. 0x80094801 >>>>>>>>> (-2146875391 ) >>>>>>>>> Certificate Request Processor: >>>>>>>>> The request contains no >>>>>>>>> certificate template >>>>>>>>> information. 0x80094801 >>>>>>>>> (-2146875391 ) >>>>>>>>> Denied by Policy Module >>>>>>>>> 0x80094801, The request does >>>>>>>>> not contain a certificate >>>>>>>>> template extension or the >>>>>>>>> CertificateTemplate request >>>>>>>>> attribute. >>>>>>>>> >>>>>>>>> The RH doc says to use the >>>>>>>>> browser if an error occurs and >>>>>>>>> IIS is running but I'm not >>>>>>>>> running IIS. I researched that >>>>>>>>> error but didn't find anything >>>>>>>>> that helps with FreeIPA and >>>>>>>>> passsync. >>>>>>>> Hmm - try installing Microsoft >>>>>>>> Certificate Authority in >>>>>>>> Enterprise Root CA mode - it >>>>>>>> will usually automatically >>>>>>>> create and install the AD >>>>>>>> server cert. >>>>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Jimmy >>>>>>>>> >>>>>>>>> On Wed, Jan 11, 2012 at 3:32 >>>>>>>>> PM, Rich Megginson >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 01/11/2012 11:22 AM, >>>>>>>>> Jimmy wrote: >>>>>>>>>> We need to be able to >>>>>>>>>> replicate user/pass >>>>>>>>>> between Windows 2008 AD >>>>>>>>>> and FreeIPA. >>>>>>>>> >>>>>>>>> That's what IPA Windows >>>>>>>>> Sync is supposed to do. >>>>>>>>> >>>>>>>>> >>>>>>>>>> I have followed many >>>>>>>>>> different documents and >>>>>>>>>> posted here about it and >>>>>>>>>> from what I've read and >>>>>>>>>> procedures I've followed >>>>>>>>>> we are unable to >>>>>>>>>> accomplish this. >>>>>>>>> >>>>>>>>> What have you tried, and >>>>>>>>> what problems have you run >>>>>>>>> into? >>>>>>>>> >>>>>>>>>> It doesn't need to be a >>>>>>>>>> full trust. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> On Tue, Jan 10, 2012 at >>>>>>>>>> 3:03 AM, Jan Zelen? >>>>>>>>>> >>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> > Just wondering if >>>>>>>>>> there was anyone >>>>>>>>>> listening on the list >>>>>>>>>> that might be >>>>>>>>>> > available for >>>>>>>>>> little work >>>>>>>>>> integrating FreeIPA >>>>>>>>>> with Active Directory >>>>>>>>>> > (preferrably in the >>>>>>>>>> south east US.) I >>>>>>>>>> hope this isn't >>>>>>>>>> against the list >>>>>>>>>> > rules, I just >>>>>>>>>> thought one of you >>>>>>>>>> guys could help or >>>>>>>>>> point me in the right >>>>>>>>>> > direction. >>>>>>>>>> >>>>>>>>>> If you want some >>>>>>>>>> help, it is certainly >>>>>>>>>> not against list >>>>>>>>>> rules ;-) But in that >>>>>>>>>> case, it would be >>>>>>>>>> much better if you >>>>>>>>>> asked what exactly do >>>>>>>>>> you need. >>>>>>>>>> >>>>>>>>>> I'm not an AD expert, >>>>>>>>>> but a couple tips: If >>>>>>>>>> you are looking for >>>>>>>>>> cross-domain >>>>>>>>>> (cross-realm) trust, >>>>>>>>>> then you might be a >>>>>>>>>> bit disappointed, it >>>>>>>>>> is still in >>>>>>>>>> development, so it >>>>>>>>>> probably won't be >>>>>>>>>> 100% functional at >>>>>>>>>> this moment. >>>>>>>>>> >>>>>>>>>> If you are looking >>>>>>>>>> for something else, >>>>>>>>>> could you be a little >>>>>>>>>> more specific what >>>>>>>>>> it is? >>>>>>>>>> >>>>>>>>>> I also recommend >>>>>>>>>> starting with reading >>>>>>>>>> some doc: >>>>>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Freeipa-users mailing list >>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g17jimmy at gmail.com Tue Jan 24 21:07:22 2012 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 24 Jan 2012 16:07:22 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F1F14A0.2090901@redhat.com> References: <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> <4F1DA80E.2070904@redhat.com> <4F1EF609.2040007@redhat.com> <4F1F14A0.2090901@redhat.com> Message-ID: certutil output: http://fpaste.org/tJDW/ pcap output (exported from Wireshark, looks messy): http://fpaste.org/M3Gr/ On Tue, Jan 24, 2012 at 3:29 PM, Rich Megginson wrote: > ** > On 01/24/2012 01:26 PM, Jimmy wrote: > > The sync is still not working so I was going back through the docs to see > what I missed. I know this is from an older version of IPA but I was > looking here: > http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html#sect-Installation_and_Deployment_Guide-Prerequisites-Setting_up_Active_Directory > > and used this method to get the AD certificate server cert. > > You mean "CA cert" not "server cert", right? > > > 1. Navigate to My Network Places and drill down to the CA distribution > point. On Windows 2003 Server this is typically > C:\WINDOWS\system32\certsrv\CertEnroll\ > 2. Double-click the security certificate file (.crt file) to display > the *Certificate* dialog box. > 3. On the *Details* tab, click *Copy to File* to start the *Certificate > Export Wizard*. > 4. Click *Next*, select *Base-64 encoded X.509 (.CER)* and then > click *Next*. > 5. Specify a suitable directory and file name for the exported file. > The file name is not important. Click *Next* to export the > certificate, and then click *Finish*. You should receive a message > stating that the export was successful. > 6. Click *OK* to exit the wizard. > > But when I run the command to create the sync agreement(pointing to the > cert I got in the step above) the ssl connection fails and if I look at > tcpdump of the connection I see that the AD server is not sending the cert > that I have imported with the sync agreement. I have used certutil to > verify that I have the same cert(same serial number and same public key) in > the 389 server as the one in the AD server ( C:\WINDOWS\system32\ > certsrv\CertEnroll\). The AD server is sending a completely different > cert, and I have been unable to find the cert in the certificate stores on > the AD server so I'm not sure where the bogus cert is coming from. Before I > added the certificate services role the certsrv\certenroll directory was > not present so I know this was created when I added that role to the AD > server. > > The pcap can be seen here: > http://www.pcapr.net/view/g17jimmy/2012/0/2/11/ldaps3.pcap.html (sorry, > registration required on that site, I didn't have anywhere else to put it.) > > Can you try fpaste.org? > > > Any idea why AD would be sending me the wrong cert and where it's coming > from? Yes, I know this isn't MS just trying to get these 2 systems to talk > ;). > > On Tue, Jan 24, 2012 at 1:18 PM, Rich Megginson wrote: > >> On 01/24/2012 11:03 AM, Jimmy wrote: >> >> Ok, I just realized that I only have passsync and not winsync, stupid >> oversight, but now that I know it I need to get winsync. Is there a >> location to download binaries or must I compile from source? I see the >> binaries for passsync on the directory server project downloads but I don't >> see the same for winsync. >> >> winsync is built-in to 389 - there isn't any additional component that >> you need to install. >> >> >> Thanks, >> Jim >> >> On Mon, Jan 23, 2012 at 1:33 PM, Rich Megginson wrote: >> >>> On 01/23/2012 11:34 AM, Jimmy wrote: >>> >>> I did create the winsync user and it is an admin. >>> >>> I will fix the ip address(change to hostname,) I only did it that was >>> because this is currently a test system so I can figure out how to get it >>> all working. >>> >>> ok - once you do that, you can check the 389 errors log at >>> /var/log/dirsrv/slapd-INST/errors to see if winsync is logging any errors >>> >>> >>> On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson wrote: >>> >>>> On 01/23/2012 10:52 AM, Jimmy wrote: >>>> >>>> That's what I was thinking, and what I did, but it still doesn't >>>> replicate new users. This is the command I used: >>>> >>>> ipa-replica-manage connect --passsync --binddn >>>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp --bindpw=******** --cacert >>>> /home/winsync/AD-server-cert.cer 192.168.201.150 -v >>>> >>>> >>>> Did you create the user cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp? >>>> And does this user have the rights to perform sync? (e.g. has to have >>>> replicator rights, or be some sort of admin) - see >>>> http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx - the >>>> AD user must have replication rights and write rights. >>>> >>>> In addition, since this process uses SSL, you cannot use an IP address, >>>> you must use a hostname, or the SSL cert hostname checking (for MITM) will >>>> fail. >>>> >>>> >>>> On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson wrote: >>>> >>>>> On 01/23/2012 10:19 AM, Jimmy wrote: >>>>> >>>>> Here's what I found in the DS admin guide. Is this all that's needed >>>>> to create the sync agreement? >>>>> >>>>> Not with ipa - you should use the ipa-replica-manage command instead >>>>> >>>>> Thanks. >>>>> >>>>> add sync agreement: >>>>> ldapmodify -x -D "cn=Directory Manager" -W >>>>> Enter LDAP Password: ******* >>>>> dn: cn=ExampleSyncAgreement,cn=sync >>>>> replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config >>>>> >>>>> it should be cn=replica, not cn=sync replica - does it use the >>>>> latter in the Admin Guide? >>>>> >>>>> changetype: add >>>>> objectclass: top >>>>> objectclass: nsDSWindowsReplicationAgreement >>>>> cn: ExampleSyncAgreement >>>>> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 >>>>> nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com >>>>> >>>>> nsds7NewWinUserSyncEnabled: on >>>>> nsds7NewWinGroupSyncEnabled: on >>>>> nsds7WindowsDomain: ad1 >>>>> nsDS5ReplicaRoot: dc=example,dc=com >>>>> nsDS5ReplicaHost: ad1.windows-server.com >>>>> nsDS5ReplicaPort: 389 >>>>> nsDS5ReplicaBindDN: cn=sync user,cn=config >>>>> nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA== >>>>> nsDS5ReplicaTransportInfo: TLS >>>>> winSyncInterval: 1200 >>>>> >>>>> On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson wrote: >>>>> >>>>>> On 01/20/2012 01:08 PM, Jimmy wrote: >>>>>> >>>>>> That was it! I have passwords syncing, *BUT*(at the risk of sounding >>>>>> stupid)-- is it not possible to also sync(add) the users from AD to DS? >>>>>> >>>>>> Yes, it is. Just configure IPA Windows Sync >>>>>> >>>>>> I created a new user in AD and it doesn't propogate to DS, just >>>>>> says: >>>>>> >>>>>> attempting to sync password for testuser3 >>>>>> searching for (ntuserdomainid=testuser3) >>>>>> There are no entries that match: testuser3 >>>>>> deferring password change for testuser3 >>>>>> >>>>>> On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson >>>>> > wrote: >>>>>> >>>>>>> On 01/20/2012 12:46 PM, Jimmy wrote: >>>>>>> >>>>>>> Getting close here... Now I see this message in the sync log file: >>>>>>> >>>>>>> attempting to sync password for testuser >>>>>>> searching for (ntuserdomainid=testuser) >>>>>>> ldap error in queryusername >>>>>>> 32: no such object >>>>>>> deferring password change for testuser >>>>>>> >>>>>>> This usually means the search base is incorrect or not found. You >>>>>>> can look at the 389 access log to see what it was using as the search >>>>>>> criteria. >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson < >>>>>>> rmeggins at redhat.com> wrote: >>>>>>> >>>>>>>> On 01/20/2012 10:23 AM, Jimmy wrote: >>>>>>>> >>>>>>>> You are correct. I had installed as an Enterprise root, but the doc >>>>>>>> I was reading(original link) seemed to say that I had to do the certreq >>>>>>>> manually, my bad. I think I'm getting closer I can establish an openssl >>>>>>>> connection from DS to AD but I get these errors: >>>>>>>> >>>>>>>> openssl s_client -connect 192.168.201.150:636 -showcerts -CAfile >>>>>>>> dsca.crt >>>>>>>> CONNECTED(00000003) >>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>>> verify error:num=20:unable to get local issuer certificate >>>>>>>> verify return:1 >>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>>> verify error:num=27:certificate not trusted >>>>>>>> verify return:1 >>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>>> verify error:num=21:unable to verify the first certificate >>>>>>>> verify return:1 >>>>>>>> >>>>>>>> I thought I had imported the cert from AD but it doesn't seem so. >>>>>>>> I'm still researching but if you guys have a suggestion let me know. >>>>>>>> >>>>>>>> Is dsca.crt the CA that issued the DS server cert? If so, that >>>>>>>> won't work. You need the CA cert from the CA that issued the AD server >>>>>>>> cert (i.e. the CA cert from the MS Enterprise Root CA). >>>>>>>> >>>>>>>> -J >>>>>>>> >>>>>>>> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson < >>>>>>>> rmeggins at redhat.com> wrote: >>>>>>>> >>>>>>>>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>>>>>>> >>>>>>>>> ok. I started from scratch this week on this and I think I've got >>>>>>>>> the right doc and understand better where this is going. My problem now is >>>>>>>>> that when configuring SSL on the AD server (step c in this url: >>>>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>>>>>> >>>>>>>>> I get this error: >>>>>>>>> >>>>>>>>> certreq -submit request.req certnew.cer >>>>>>>>> Active Directory Enrollment Policy >>>>>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>>>>>> ldap: >>>>>>>>> RequestId: 3 >>>>>>>>> RequestId: "3" >>>>>>>>> Certificate not issued (Denied) Denied by Policy Module >>>>>>>>> 0x80094801, The request does not contain a certificate template extension >>>>>>>>> or the CertificateTemplate request attribute. >>>>>>>>> The request contains no certificate template information. >>>>>>>>> 0x80094801 (-2146875391) >>>>>>>>> Certificate Request Processor: The request contains no certificate >>>>>>>>> template information. 0x80094801 (-2146875391) >>>>>>>>> Denied by Policy Module 0x80094801, The request does not contain >>>>>>>>> a certificate template extension or the CertificateTemplate request >>>>>>>>> attribute. >>>>>>>>> >>>>>>>>> The RH doc says to use the browser if an error occurs and IIS is >>>>>>>>> running but I'm not running IIS. I researched that error but didn't find >>>>>>>>> anything that helps with FreeIPA and passsync. >>>>>>>>> >>>>>>>>> Hmm - try installing Microsoft Certificate Authority in >>>>>>>>> Enterprise Root CA mode - it will usually automatically create and install >>>>>>>>> the AD server cert. >>>>>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>>>>>> >>>>>>>>> >>>>>>>>> Jimmy >>>>>>>>> >>>>>>>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson < >>>>>>>>> rmeggins at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>>>>>>>> >>>>>>>>>> We need to be able to replicate user/pass between Windows 2008 AD >>>>>>>>>> and FreeIPA. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That's what IPA Windows Sync is supposed to do. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I have followed many different documents and posted here about >>>>>>>>>> it and from what I've read and procedures I've followed we are unable to >>>>>>>>>> accomplish this. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What have you tried, and what problems have you run into? >>>>>>>>>> >>>>>>>>>> It doesn't need to be a full trust. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: >>>>>>>>>> >>>>>>>>>>> > Just wondering if there was anyone listening on the list >>>>>>>>>>> that might be >>>>>>>>>>> > available for little work integrating FreeIPA with Active >>>>>>>>>>> Directory >>>>>>>>>>> > (preferrably in the south east US.) I hope this isn't against >>>>>>>>>>> the list >>>>>>>>>>> > rules, I just thought one of you guys could help or point me >>>>>>>>>>> in the right >>>>>>>>>>> > direction. >>>>>>>>>>> >>>>>>>>>>> If you want some help, it is certainly not against list rules >>>>>>>>>>> ;-) But in that >>>>>>>>>>> case, it would be much better if you asked what exactly do you >>>>>>>>>>> need. >>>>>>>>>>> >>>>>>>>>>> I'm not an AD expert, but a couple tips: If you are looking for >>>>>>>>>>> cross-domain >>>>>>>>>>> (cross-realm) trust, then you might be a bit disappointed, it is >>>>>>>>>>> still in >>>>>>>>>>> development, so it probably won't be 100% functional at this >>>>>>>>>>> moment. >>>>>>>>>>> >>>>>>>>>>> If you are looking for something else, could you be a little >>>>>>>>>>> more specific what >>>>>>>>>>> it is? >>>>>>>>>>> >>>>>>>>>>> I also recommend starting with reading some doc: >>>>>>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Jan >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Jan 24 21:20:57 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 24 Jan 2012 14:20:57 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> <4F1DA80E.2070904@redhat.com> <4F1EF609.2040007@redhat.com> <4F1F14A0.2090901@redhat.com> Message-ID: <4F1F20B9.50509@redhat.com> On 01/24/2012 02:07 PM, Jimmy wrote: > certutil output: > http://fpaste.org/tJDW/ > > pcap output (exported from Wireshark, looks messy): > http://fpaste.org/M3Gr/ hard to tell from the pcap output, but is Serial Number: 68:10:1c:98:3b:5c:e7:8d:43:ec:e3:e7:6a:e7:de:27 Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: "CN=xxxad-xxx-AD-CA,DC=xxxad,DC=xxx,DC=xxx" Validity: Not Before: Thu Jan 19 17:52:07 2012 Not After : Thu Jan 19 18:02:04 2017 Subject: "CN=xxxad-xxx-AD-CA,DC=xxxad,DC=xxx,DC=xxx" the same cert as the cert from the pcap output that is called Distinguished Name: (id-at-commonName=xxxad-XXX-AD-CA,dc=xxxad,dc=xxx,dc=xxx) because this appears to be the AD CA cert sent over from AD as part of the SSL handshake There are a couple of good tools to use to diagnose/debug connection problems between 389 and AD before you attempt to use winsync with ssl. The first is openssl s_client openssl s_client -connect ADhost:636 -CAfile /path/to/adca.cer The second is mozldap ldapsearch: /usr/lib64/mozldap/ldapsearch -h ADHost -p 636 -Z -P /etc/dirsrv/slapd-INST/cert8.db -s base -b "" "objectclass=*" The third is openldap ldapsearch: LDAPTLS_CACERT=/path/to/adca.cer ldapsearch -x -h ADHost -p 636 -s base -b "" "objectclass=*" For the last you can add "-d 1" to get detailed SSL error messages > > On Tue, Jan 24, 2012 at 3:29 PM, Rich Megginson > wrote: > > On 01/24/2012 01:26 PM, Jimmy wrote: >> The sync is still not working so I was going back through the >> docs to see what I missed. I know this is from an older version >> of IPA but I was looking here: >> http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html#sect-Installation_and_Deployment_Guide-Prerequisites-Setting_up_Active_Directory >> >> >> and used this method to get the AD certificate server cert. > You mean "CA cert" not "server cert", right? >> >> 1. >> Navigate to My Network Places and drill down to the CA >> distribution point. On Windows 2003 Server this is >> typically |C:\WINDOWS\system32\certsrv\CertEnroll\| >> 2. >> Double-click the security certificate file (|.crt| file) to >> display the *Certificate* dialog box. >> 3. >> On the *Details* tab, click *Copy to File* to start the >> *Certificate Export Wizard*. >> 4. >> Click *Next*, select *Base-64 encoded X.509 (.CER)* and >> then click *Next*. >> 5. >> Specify a suitable directory and file name for the exported >> file. The file name is not important. Click *Next* to >> export the certificate, and then click *Finish*. You should >> receive a message stating that the export was successful. >> 6. >> Click *OK* to exit the wizard. >> >> But when I run the command to create the sync agreement(pointing >> to the cert I got in the step above) the ssl connection fails and >> if I look at tcpdump of the connection I see that the AD server >> is not sending the cert that I have imported with the sync >> agreement. I have used certutil to verify that I have the same >> cert(same serial number and same public key) in the 389 server as >> the one in the AD server ( >> C:\WINDOWS\system32\certsrv\CertEnroll\). The AD server is >> sending a completely different cert, and I have been unable to >> find the cert in the certificate stores on the AD server so I'm >> not sure where the bogus cert is coming from. Before I added the >> certificate services role the certsrv\certenroll directory was >> not present so I know this was created when I added that role to >> the AD server. >> >> The pcap can be seen here: >> http://www.pcapr.net/view/g17jimmy/2012/0/2/11/ldaps3.pcap.html (sorry, >> registration required on that site, I didn't have anywhere else >> to put it.) > Can you try fpaste.org ? >> >> Any idea why AD would be sending me the wrong cert and where it's >> coming from? Yes, I know this isn't MS just trying to get these 2 >> systems to talk ;). >> >> On Tue, Jan 24, 2012 at 1:18 PM, Rich Megginson >> > wrote: >> >> On 01/24/2012 11:03 AM, Jimmy wrote: >>> Ok, I just realized that I only have passsync and not >>> winsync, stupid oversight, but now that I know it I need to >>> get winsync. Is there a location to download binaries or >>> must I compile from source? I see the binaries for passsync >>> on the directory server project downloads but I don't see >>> the same for winsync. >> winsync is built-in to 389 - there isn't any additional >> component that you need to install. >> >>> >>> Thanks, >>> Jim >>> >>> On Mon, Jan 23, 2012 at 1:33 PM, Rich Megginson >>> > wrote: >>> >>> On 01/23/2012 11:34 AM, Jimmy wrote: >>>> I did create the winsync user and it is an admin. >>>> >>>> I will fix the ip address(change to hostname,) I only >>>> did it that was because this is currently a test system >>>> so I can figure out how to get it all working. >>> ok - once you do that, you can check the 389 errors log >>> at /var/log/dirsrv/slapd-INST/errors to see if winsync >>> is logging any errors >>> >>>> >>>> On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson >>>> > wrote: >>>> >>>> On 01/23/2012 10:52 AM, Jimmy wrote: >>>>> That's what I was thinking, and what I did, but it >>>>> still doesn't replicate new users. This is the >>>>> command I used: >>>>> >>>>> ipa-replica-manage connect --passsync --binddn >>>>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp >>>>> --bindpw=******** --cacert >>>>> /home/winsync/AD-server-cert.cer 192.168.201.150 -v >>>> >>>> Did you create the user >>>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp? And >>>> does this user have the rights to perform sync? >>>> (e.g. has to have replicator rights, or be some >>>> sort of admin) - see >>>> http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx >>>> - the AD user must have replication rights and >>>> write rights. >>>> >>>> In addition, since this process uses SSL, you >>>> cannot use an IP address, you must use a hostname, >>>> or the SSL cert hostname checking (for MITM) will >>>> fail. >>>> >>>>> >>>>> On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson >>>>> > >>>>> wrote: >>>>> >>>>> On 01/23/2012 10:19 AM, Jimmy wrote: >>>>>> Here's what I found in the DS admin guide. Is >>>>>> this all that's needed to create the sync >>>>>> agreement? >>>>> Not with ipa - you should use the >>>>> ipa-replica-manage command instead >>>>> >>>>>> Thanks. >>>>>> >>>>>> add sync agreement: >>>>>> ldapmodify -x -D "cn=Directory Manager" -W >>>>>> Enter LDAP Password: ******* >>>>>> dn: cn=ExampleSyncAgreement,cn=sync >>>>>> replica,cn=dc=example\,dc=com,cn=mapping >>>>>> tree,cn=config >>>>> it should be cn=replica, not cn=sync replica - >>>>> does it use the latter in the Admin Guide? >>>>> >>>>>> changetype: add >>>>>> objectclass: top >>>>>> objectclass: nsDSWindowsReplicationAgreement >>>>>> cn: ExampleSyncAgreement >>>>>> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 >>>>>> nsds7DirectoryReplicaSubtree: >>>>>> ou=People,dc=example,dc=com >>>>>> nsds7NewWinUserSyncEnabled: on >>>>>> nsds7NewWinGroupSyncEnabled: on >>>>>> nsds7WindowsDomain: ad1 >>>>>> nsDS5ReplicaRoot: dc=example,dc=com >>>>>> nsDS5ReplicaHost: ad1.windows-server.com >>>>>> >>>>>> nsDS5ReplicaPort: 389 >>>>>> nsDS5ReplicaBindDN: cn=sync user,cn=config >>>>>> nsDS5ReplicaBindCredentials: >>>>>> {DES}ffGad646dT0nnsT8nJOaMA== >>>>>> nsDS5ReplicaTransportInfo: TLS >>>>>> winSyncInterval: 1200 >>>>>> >>>>>> On Fri, Jan 20, 2012 at 3:28 PM, Rich >>>>>> Megginson >>>>> > wrote: >>>>>> >>>>>> On 01/20/2012 01:08 PM, Jimmy wrote: >>>>>>> That was it! I have passwords syncing, >>>>>>> *BUT*(at the risk of sounding stupid)-- >>>>>>> is it not possible to also sync(add) the >>>>>>> users from AD to DS? >>>>>> Yes, it is. Just configure IPA Windows Sync >>>>>> >>>>>>> I created a new user in AD and it >>>>>>> doesn't propogate to DS, just says: >>>>>>> >>>>>>> attempting to sync password for testuser3 >>>>>>> searching for (ntuserdomainid=testuser3) >>>>>>> There are no entries that match: testuser3 >>>>>>> deferring password change for testuser3 >>>>>>> >>>>>>> On Fri, Jan 20, 2012 at 2:46 PM, Rich >>>>>>> Megginson >>>>>> > wrote: >>>>>>> >>>>>>> On 01/20/2012 12:46 PM, Jimmy wrote: >>>>>>>> Getting close here... Now I see >>>>>>>> this message in the sync log file: >>>>>>>> >>>>>>>> attempting to sync password for >>>>>>>> testuser >>>>>>>> searching for (ntuserdomainid=testuser) >>>>>>>> ldap error in queryusername >>>>>>>> 32: no such object >>>>>>>> deferring password change for testuser >>>>>>> This usually means the search base >>>>>>> is incorrect or not found. You can >>>>>>> look at the 389 access log to see >>>>>>> what it was using as the search >>>>>>> criteria. >>>>>>> >>>>>>>> >>>>>>>> On Fri, Jan 20, 2012 at 12:23 PM, >>>>>>>> Rich Megginson >>>>>>> > wrote: >>>>>>>> >>>>>>>> On 01/20/2012 10:23 AM, Jimmy >>>>>>>> wrote: >>>>>>>>> You are correct. I had >>>>>>>>> installed as an Enterprise >>>>>>>>> root, but the doc I was >>>>>>>>> reading(original link) seemed >>>>>>>>> to say that I had to do the >>>>>>>>> certreq manually, my bad. I >>>>>>>>> think I'm getting closer I can >>>>>>>>> establish an openssl >>>>>>>>> connection from DS to AD but I >>>>>>>>> get these errors: >>>>>>>>> >>>>>>>>> openssl s_client -connect >>>>>>>>> 192.168.201.150:636 >>>>>>>>> >>>>>>>>> -showcerts -CAfile dsca.crt >>>>>>>>> CONNECTED(00000003) >>>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>>>> verify error:num=20:unable to >>>>>>>>> get local issuer certificate >>>>>>>>> verify return:1 >>>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>>>> verify >>>>>>>>> error:num=27:certificate not >>>>>>>>> trusted >>>>>>>>> verify return:1 >>>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>>>> verify error:num=21:unable to >>>>>>>>> verify the first certificate >>>>>>>>> verify return:1 >>>>>>>>> >>>>>>>>> I thought I had imported the >>>>>>>>> cert from AD but it doesn't >>>>>>>>> seem so. I'm still researching >>>>>>>>> but if you guys have a >>>>>>>>> suggestion let me know. >>>>>>>> Is dsca.crt the CA that issued >>>>>>>> the DS server cert? If so, >>>>>>>> that won't work. You need the >>>>>>>> CA cert from the CA that issued >>>>>>>> the AD server cert (i.e. the CA >>>>>>>> cert from the MS Enterprise >>>>>>>> Root CA). >>>>>>>> >>>>>>>>> -J >>>>>>>>> >>>>>>>>> On Thu, Jan 19, 2012 at 5:04 >>>>>>>>> PM, Rich Megginson >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 01/19/2012 02:59 PM, >>>>>>>>> Jimmy wrote: >>>>>>>>>> ok. I started from >>>>>>>>>> scratch this week on this >>>>>>>>>> and I think I've got the >>>>>>>>>> right doc and understand >>>>>>>>>> better where this is >>>>>>>>>> going. My problem now is >>>>>>>>>> that when configuring SSL >>>>>>>>>> on the AD server (step c >>>>>>>>>> in this url: >>>>>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>>>>>>> >>>>>>>>>> I get this error: >>>>>>>>>> >>>>>>>>>> certreq -submit >>>>>>>>>> request.req certnew.cer >>>>>>>>>> Active Directory >>>>>>>>>> Enrollment Policy >>>>>>>>>> >>>>>>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>>>>>>> ldap: >>>>>>>>>> RequestId: 3 >>>>>>>>>> RequestId: "3" >>>>>>>>>> Certificate not issued >>>>>>>>>> (Denied) Denied by Policy >>>>>>>>>> Module 0x80094801, The >>>>>>>>>> request does not contain >>>>>>>>>> a certificate template >>>>>>>>>> extension or the >>>>>>>>>> CertificateTemplate >>>>>>>>>> request attribute. >>>>>>>>>> The request contains no >>>>>>>>>> certificate template >>>>>>>>>> information. 0x80094801 >>>>>>>>>> (-2146875391 >>>>>>>>>> ) >>>>>>>>>> Certificate Request >>>>>>>>>> Processor: The request >>>>>>>>>> contains no certificate >>>>>>>>>> template information. >>>>>>>>>> 0x80094801 (-2146875391 >>>>>>>>>> ) >>>>>>>>>> Denied by Policy Module >>>>>>>>>> 0x80094801, The request >>>>>>>>>> does not contain a >>>>>>>>>> certificate template >>>>>>>>>> extension or the >>>>>>>>>> CertificateTemplate >>>>>>>>>> request attribute. >>>>>>>>>> >>>>>>>>>> The RH doc says to use >>>>>>>>>> the browser if an error >>>>>>>>>> occurs and IIS is running >>>>>>>>>> but I'm not running IIS. >>>>>>>>>> I researched that error >>>>>>>>>> but didn't find anything >>>>>>>>>> that helps with FreeIPA >>>>>>>>>> and passsync. >>>>>>>>> Hmm - try installing >>>>>>>>> Microsoft Certificate >>>>>>>>> Authority in Enterprise >>>>>>>>> Root CA mode - it will >>>>>>>>> usually automatically >>>>>>>>> create and install the AD >>>>>>>>> server cert. >>>>>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Jimmy >>>>>>>>>> >>>>>>>>>> On Wed, Jan 11, 2012 at >>>>>>>>>> 3:32 PM, Rich Megginson >>>>>>>>>> >>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 01/11/2012 11:22 >>>>>>>>>> AM, Jimmy wrote: >>>>>>>>>>> We need to be able >>>>>>>>>>> to replicate >>>>>>>>>>> user/pass between >>>>>>>>>>> Windows 2008 AD and >>>>>>>>>>> FreeIPA. >>>>>>>>>> >>>>>>>>>> That's what IPA >>>>>>>>>> Windows Sync is >>>>>>>>>> supposed to do. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I have followed many >>>>>>>>>>> different documents >>>>>>>>>>> and posted here >>>>>>>>>>> about it and from >>>>>>>>>>> what I've read and >>>>>>>>>>> procedures I've >>>>>>>>>>> followed we are >>>>>>>>>>> unable to accomplish >>>>>>>>>>> this. >>>>>>>>>> >>>>>>>>>> What have you tried, >>>>>>>>>> and what problems >>>>>>>>>> have you run into? >>>>>>>>>> >>>>>>>>>>> It doesn't need to >>>>>>>>>>> be a full trust. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> On Tue, Jan 10, 2012 >>>>>>>>>>> at 3:03 AM, Jan >>>>>>>>>>> Zelen? >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> > Just wondering >>>>>>>>>>> if there was >>>>>>>>>>> anyone listening >>>>>>>>>>> on the list that >>>>>>>>>>> might be >>>>>>>>>>> > available for >>>>>>>>>>> little work >>>>>>>>>>> integrating >>>>>>>>>>> FreeIPA with >>>>>>>>>>> Active Directory >>>>>>>>>>> > (preferrably >>>>>>>>>>> in the south >>>>>>>>>>> east US.) I hope >>>>>>>>>>> this isn't >>>>>>>>>>> against the list >>>>>>>>>>> > rules, I just >>>>>>>>>>> thought one of >>>>>>>>>>> you guys could >>>>>>>>>>> help or point me >>>>>>>>>>> in the right >>>>>>>>>>> > direction. >>>>>>>>>>> >>>>>>>>>>> If you want some >>>>>>>>>>> help, it is >>>>>>>>>>> certainly not >>>>>>>>>>> against list >>>>>>>>>>> rules ;-) But in >>>>>>>>>>> that >>>>>>>>>>> case, it would >>>>>>>>>>> be much better >>>>>>>>>>> if you asked >>>>>>>>>>> what exactly do >>>>>>>>>>> you need. >>>>>>>>>>> >>>>>>>>>>> I'm not an AD >>>>>>>>>>> expert, but a >>>>>>>>>>> couple tips: If >>>>>>>>>>> you are looking >>>>>>>>>>> for cross-domain >>>>>>>>>>> (cross-realm) >>>>>>>>>>> trust, then you >>>>>>>>>>> might be a bit >>>>>>>>>>> disappointed, it >>>>>>>>>>> is still in >>>>>>>>>>> development, so >>>>>>>>>>> it probably >>>>>>>>>>> won't be 100% >>>>>>>>>>> functional at >>>>>>>>>>> this moment. >>>>>>>>>>> >>>>>>>>>>> If you are >>>>>>>>>>> looking for >>>>>>>>>>> something else, >>>>>>>>>>> could you be a >>>>>>>>>>> little more >>>>>>>>>>> specific what >>>>>>>>>>> it is? >>>>>>>>>>> >>>>>>>>>>> I also recommend >>>>>>>>>>> starting with >>>>>>>>>>> reading some doc: >>>>>>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Jan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Freeipa-users mailing list >>>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g17jimmy at gmail.com Tue Jan 24 21:51:05 2012 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 24 Jan 2012 16:51:05 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F1F20B9.50509@redhat.com> References: <4F18935B.6000803@redhat.com> <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> <4F1DA80E.2070904@redhat.com> <4F1EF609.2040007@redhat.com> <4F1F14A0.2090901@redhat.com> <4F1F20B9.50509@redhat.com> Message-ID: The cert I'm using both in the sync agreement and in the openssl command has the serial number: 68:10:1c:98:3b:5c:e7:8d:43:ec:e3:e7:6a:e7:de:27 (AD-server-cert.cer.) The serial number that shows in the pcap coming from AD in both instances is 61:13:fd:30:00:00:00:00:00:04 (line 196 in the fpaste) OpenSSL command: openssl s_client -connect xxx-ad.xxx.xxx:636 -CAfile /home/winsync/AD-server-cert.cer OpenSSL output- http://fpaste.org/Zx5N/ Both the output of openssl and the pcap of the openssl session look successful here. Thanks for your help. Jimmy On Tue, Jan 24, 2012 at 4:20 PM, Rich Megginson wrote: > ** > On 01/24/2012 02:07 PM, Jimmy wrote: > > certutil output: > http://fpaste.org/tJDW/ > > pcap output (exported from Wireshark, looks messy): > http://fpaste.org/M3Gr/ > > hard to tell from the pcap output, but is > > Serial Number: 68:10:1c:98:3b:5c:e7:8d:43:ec:e3:e7:6a:e7:de:27 > Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption > Issuer: "CN=xxxad-xxx-AD-CA,DC=xxxad,DC=xxx,DC=xxx" > Validity: > Not Before: Thu Jan 19 17:52:07 2012 > Not After : Thu Jan 19 18:02:04 2017 > Subject: "CN=xxxad-xxx-AD-CA,DC=xxxad,DC=xxx,DC=xxx" > > the same cert as the cert from the pcap output that is called > Distinguished Name: > (id-at-commonName=xxxad-XXX-AD-CA,dc=xxxad,dc=xxx,dc=xxx) > > because this appears to be the AD CA cert sent over from AD as part of the > SSL handshake > > There are a couple of good tools to use to diagnose/debug connection > problems between 389 and AD before you attempt to use winsync with ssl. > > The first is openssl s_client > openssl s_client -connect ADhost:636 -CAfile /path/to/adca.cer > > The second is mozldap ldapsearch: > /usr/lib64/mozldap/ldapsearch -h ADHost -p 636 -Z -P > /etc/dirsrv/slapd-INST/cert8.db -s base -b "" "objectclass=*" > > The third is openldap ldapsearch: > LDAPTLS_CACERT=/path/to/adca.cer ldapsearch -x -h ADHost -p 636 -s base -b > "" "objectclass=*" > > For the last you can add "-d 1" to get detailed SSL error messages > > > On Tue, Jan 24, 2012 at 3:29 PM, Rich Megginson wrote: > >> On 01/24/2012 01:26 PM, Jimmy wrote: >> >> The sync is still not working so I was going back through the docs to see >> what I missed. I know this is from an older version of IPA but I was >> looking here: >> http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html#sect-Installation_and_Deployment_Guide-Prerequisites-Setting_up_Active_Directory >> >> and used this method to get the AD certificate server cert. >> >> You mean "CA cert" not "server cert", right? >> >> >> 1. Navigate to My Network Places and drill down to the CA >> distribution point. On Windows 2003 Server this is typically >> C:\WINDOWS\system32\certsrv\CertEnroll\ >> 2. Double-click the security certificate file (.crt file) to >> display the *Certificate* dialog box. >> 3. On the *Details* tab, click *Copy to File* to start the *Certificate >> Export Wizard*. >> 4. Click *Next*, select *Base-64 encoded X.509 (.CER)* and then >> click *Next*. >> 5. Specify a suitable directory and file name for the exported >> file. The file name is not important. Click *Next* to export the >> certificate, and then click *Finish*. You should receive a message >> stating that the export was successful. >> 6. Click *OK* to exit the wizard. >> >> But when I run the command to create the sync agreement(pointing to the >> cert I got in the step above) the ssl connection fails and if I look at >> tcpdump of the connection I see that the AD server is not sending the cert >> that I have imported with the sync agreement. I have used certutil to >> verify that I have the same cert(same serial number and same public key) in >> the 389 server as the one in the AD server ( C:\WINDOWS\system32\ >> certsrv\CertEnroll\). The AD server is sending a completely different >> cert, and I have been unable to find the cert in the certificate stores on >> the AD server so I'm not sure where the bogus cert is coming from. Before I >> added the certificate services role the certsrv\certenroll directory was >> not present so I know this was created when I added that role to the AD >> server. >> >> The pcap can be seen here: >> http://www.pcapr.net/view/g17jimmy/2012/0/2/11/ldaps3.pcap.html (sorry, >> registration required on that site, I didn't have anywhere else to put it.) >> >> Can you try fpaste.org? >> >> >> Any idea why AD would be sending me the wrong cert and where it's >> coming from? Yes, I know this isn't MS just trying to get these 2 systems >> to talk ;). >> >> On Tue, Jan 24, 2012 at 1:18 PM, Rich Megginson wrote: >> >>> On 01/24/2012 11:03 AM, Jimmy wrote: >>> >>> Ok, I just realized that I only have passsync and not winsync, stupid >>> oversight, but now that I know it I need to get winsync. Is there a >>> location to download binaries or must I compile from source? I see the >>> binaries for passsync on the directory server project downloads but I don't >>> see the same for winsync. >>> >>> winsync is built-in to 389 - there isn't any additional component that >>> you need to install. >>> >>> >>> Thanks, >>> Jim >>> >>> On Mon, Jan 23, 2012 at 1:33 PM, Rich Megginson wrote: >>> >>>> On 01/23/2012 11:34 AM, Jimmy wrote: >>>> >>>> I did create the winsync user and it is an admin. >>>> >>>> I will fix the ip address(change to hostname,) I only did it that was >>>> because this is currently a test system so I can figure out how to get it >>>> all working. >>>> >>>> ok - once you do that, you can check the 389 errors log at >>>> /var/log/dirsrv/slapd-INST/errors to see if winsync is logging any errors >>>> >>>> >>>> On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson wrote: >>>> >>>>> On 01/23/2012 10:52 AM, Jimmy wrote: >>>>> >>>>> That's what I was thinking, and what I did, but it still doesn't >>>>> replicate new users. This is the command I used: >>>>> >>>>> ipa-replica-manage connect --passsync --binddn >>>>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp --bindpw=******** --cacert >>>>> /home/winsync/AD-server-cert.cer 192.168.201.150 -v >>>>> >>>>> >>>>> Did you create the user cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp? >>>>> And does this user have the rights to perform sync? (e.g. has to have >>>>> replicator rights, or be some sort of admin) - see >>>>> http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx - >>>>> the AD user must have replication rights and write rights. >>>>> >>>>> In addition, since this process uses SSL, you cannot use an IP >>>>> address, you must use a hostname, or the SSL cert hostname checking (for >>>>> MITM) will fail. >>>>> >>>>> >>>>> On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson >>>> > wrote: >>>>> >>>>>> On 01/23/2012 10:19 AM, Jimmy wrote: >>>>>> >>>>>> Here's what I found in the DS admin guide. Is this all that's needed >>>>>> to create the sync agreement? >>>>>> >>>>>> Not with ipa - you should use the ipa-replica-manage command >>>>>> instead >>>>>> >>>>>> Thanks. >>>>>> >>>>>> add sync agreement: >>>>>> ldapmodify -x -D "cn=Directory Manager" -W >>>>>> Enter LDAP Password: ******* >>>>>> dn: cn=ExampleSyncAgreement,cn=sync >>>>>> replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config >>>>>> >>>>>> it should be cn=replica, not cn=sync replica - does it use the >>>>>> latter in the Admin Guide? >>>>>> >>>>>> changetype: add >>>>>> objectclass: top >>>>>> objectclass: nsDSWindowsReplicationAgreement >>>>>> cn: ExampleSyncAgreement >>>>>> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 >>>>>> nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com >>>>>> >>>>>> nsds7NewWinUserSyncEnabled: on >>>>>> nsds7NewWinGroupSyncEnabled: on >>>>>> nsds7WindowsDomain: ad1 >>>>>> nsDS5ReplicaRoot: dc=example,dc=com >>>>>> nsDS5ReplicaHost: ad1.windows-server.com >>>>>> nsDS5ReplicaPort: 389 >>>>>> nsDS5ReplicaBindDN: cn=sync user,cn=config >>>>>> nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA== >>>>>> nsDS5ReplicaTransportInfo: TLS >>>>>> winSyncInterval: 1200 >>>>>> >>>>>> On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson >>>>> > wrote: >>>>>> >>>>>>> On 01/20/2012 01:08 PM, Jimmy wrote: >>>>>>> >>>>>>> That was it! I have passwords syncing, *BUT*(at the risk of sounding >>>>>>> stupid)-- is it not possible to also sync(add) the users from AD to DS? >>>>>>> >>>>>>> Yes, it is. Just configure IPA Windows Sync >>>>>>> >>>>>>> I created a new user in AD and it doesn't propogate to DS, just >>>>>>> says: >>>>>>> >>>>>>> attempting to sync password for testuser3 >>>>>>> searching for (ntuserdomainid=testuser3) >>>>>>> There are no entries that match: testuser3 >>>>>>> deferring password change for testuser3 >>>>>>> >>>>>>> On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson < >>>>>>> rmeggins at redhat.com> wrote: >>>>>>> >>>>>>>> On 01/20/2012 12:46 PM, Jimmy wrote: >>>>>>>> >>>>>>>> Getting close here... Now I see this message in the sync log file: >>>>>>>> >>>>>>>> attempting to sync password for testuser >>>>>>>> searching for (ntuserdomainid=testuser) >>>>>>>> ldap error in queryusername >>>>>>>> 32: no such object >>>>>>>> deferring password change for testuser >>>>>>>> >>>>>>>> This usually means the search base is incorrect or not found. >>>>>>>> You can look at the 389 access log to see what it was using as the search >>>>>>>> criteria. >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson < >>>>>>>> rmeggins at redhat.com> wrote: >>>>>>>> >>>>>>>>> On 01/20/2012 10:23 AM, Jimmy wrote: >>>>>>>>> >>>>>>>>> You are correct. I had installed as an Enterprise root, but the >>>>>>>>> doc I was reading(original link) seemed to say that I had to do the certreq >>>>>>>>> manually, my bad. I think I'm getting closer I can establish an openssl >>>>>>>>> connection from DS to AD but I get these errors: >>>>>>>>> >>>>>>>>> openssl s_client -connect 192.168.201.150:636 -showcerts >>>>>>>>> -CAfile dsca.crt >>>>>>>>> CONNECTED(00000003) >>>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>>>> verify error:num=20:unable to get local issuer certificate >>>>>>>>> verify return:1 >>>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>>>> verify error:num=27:certificate not trusted >>>>>>>>> verify return:1 >>>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp >>>>>>>>> verify error:num=21:unable to verify the first certificate >>>>>>>>> verify return:1 >>>>>>>>> >>>>>>>>> I thought I had imported the cert from AD but it doesn't seem >>>>>>>>> so. I'm still researching but if you guys have a suggestion let me know. >>>>>>>>> >>>>>>>>> Is dsca.crt the CA that issued the DS server cert? If so, that >>>>>>>>> won't work. You need the CA cert from the CA that issued the AD server >>>>>>>>> cert (i.e. the CA cert from the MS Enterprise Root CA). >>>>>>>>> >>>>>>>>> -J >>>>>>>>> >>>>>>>>> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson < >>>>>>>>> rmeggins at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> On 01/19/2012 02:59 PM, Jimmy wrote: >>>>>>>>>> >>>>>>>>>> ok. I started from scratch this week on this and I think I've got >>>>>>>>>> the right doc and understand better where this is going. My problem now is >>>>>>>>>> that when configuring SSL on the AD server (step c in this url: >>>>>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>>>>>>> >>>>>>>>>> I get this error: >>>>>>>>>> >>>>>>>>>> certreq -submit request.req certnew.cer >>>>>>>>>> Active Directory Enrollment Policy >>>>>>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>>>>>>> ldap: >>>>>>>>>> RequestId: 3 >>>>>>>>>> RequestId: "3" >>>>>>>>>> Certificate not issued (Denied) Denied by Policy Module >>>>>>>>>> 0x80094801, The request does not contain a certificate template extension >>>>>>>>>> or the CertificateTemplate request attribute. >>>>>>>>>> The request contains no certificate template information. >>>>>>>>>> 0x80094801 (-2146875391) >>>>>>>>>> Certificate Request Processor: The request contains no >>>>>>>>>> certificate template information. 0x80094801 (-2146875391) >>>>>>>>>> Denied by Policy Module 0x80094801, The request does not >>>>>>>>>> contain a certificate template extension or the CertificateTemplate request >>>>>>>>>> attribute. >>>>>>>>>> >>>>>>>>>> The RH doc says to use the browser if an error occurs and IIS >>>>>>>>>> is running but I'm not running IIS. I researched that error but didn't find >>>>>>>>>> anything that helps with FreeIPA and passsync. >>>>>>>>>> >>>>>>>>>> Hmm - try installing Microsoft Certificate Authority in >>>>>>>>>> Enterprise Root CA mode - it will usually automatically create and install >>>>>>>>>> the AD server cert. >>>>>>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Jimmy >>>>>>>>>> >>>>>>>>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson < >>>>>>>>>> rmeggins at redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> On 01/11/2012 11:22 AM, Jimmy wrote: >>>>>>>>>>> >>>>>>>>>>> We need to be able to replicate user/pass between Windows 2008 >>>>>>>>>>> AD and FreeIPA. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> That's what IPA Windows Sync is supposed to do. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I have followed many different documents and posted here about >>>>>>>>>>> it and from what I've read and procedures I've followed we are unable to >>>>>>>>>>> accomplish this. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> What have you tried, and what problems have you run into? >>>>>>>>>>> >>>>>>>>>>> It doesn't need to be a full trust. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> > Just wondering if there was anyone listening on the list >>>>>>>>>>>> that might be >>>>>>>>>>>> > available for little work integrating FreeIPA with Active >>>>>>>>>>>> Directory >>>>>>>>>>>> > (preferrably in the south east US.) I hope this isn't against >>>>>>>>>>>> the list >>>>>>>>>>>> > rules, I just thought one of you guys could help or point me >>>>>>>>>>>> in the right >>>>>>>>>>>> > direction. >>>>>>>>>>>> >>>>>>>>>>>> If you want some help, it is certainly not against list >>>>>>>>>>>> rules ;-) But in that >>>>>>>>>>>> case, it would be much better if you asked what exactly do you >>>>>>>>>>>> need. >>>>>>>>>>>> >>>>>>>>>>>> I'm not an AD expert, but a couple tips: If you are looking for >>>>>>>>>>>> cross-domain >>>>>>>>>>>> (cross-realm) trust, then you might be a bit disappointed, it >>>>>>>>>>>> is still in >>>>>>>>>>>> development, so it probably won't be 100% functional at this >>>>>>>>>>>> moment. >>>>>>>>>>>> >>>>>>>>>>>> If you are looking for something else, could you be a little >>>>>>>>>>>> more specific what >>>>>>>>>>>> it is? >>>>>>>>>>>> >>>>>>>>>>>> I also recommend starting with reading some doc: >>>>>>>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Jan >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Jan 24 22:00:47 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 24 Jan 2012 15:00:47 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> <4F1DA80E.2070904@redhat.com> <4F1EF609.2040007@redhat.com> <4F1F14A0.2090901@redhat.com> <4F1F20B9.50509@redhat.com> Message-ID: <4F1F2A0F.9030908@redhat.com> On 01/24/2012 02:51 PM, Jimmy wrote: > The cert I'm using both in the sync agreement and in the openssl > command has the serial > number: 68:10:1c:98:3b:5c:e7:8d:43:ec:e3:e7:6a:e7:de:27 > (AD-server-cert.cer.) The serial number that shows in the pcap coming > from AD in both instances is 61:13:fd:30:00:00:00:00:00:04 (line 196 > in the fpaste) 61:13:fd:30:00:00:00:00:00:04 looks like the AD server cert, not the AD CA cert: 193. Certificate (id-at-commonName=xxx-ad.xxxad.xxx.xxx) the one at line 217 looks like the AD CA cert, but unfortunately the serial number nor any other identifying information is in the pcap output 217. Distinguished Name: (id-at-commonName=xxxad-XXX-AD-CA,dc=xxxad,dc=xxx,dc=xxx) which corresponds to this from the s_client output: 51. Acceptable client certificate CA names 52. /DC=xxx/DC=xxx/DC=xxxad/CN=xxxad-xxx-AD-CA You can use openssl s_client -connect xxx-ad.xxx.xxx:636 -showcerts -CAfile /home/winsync/AD-server-cert.cer which will show the contents of all of the certs, not just the AD server cert > > OpenSSL command: openssl s_client -connect xxx-ad.xxx.xxx:636 -CAfile > /home/winsync/AD-server-cert.cer > OpenSSL output- http://fpaste.org/Zx5N/ > > Both the output of openssl and the pcap of the openssl session look > successful here. What about the ldapsearch commands? > > Thanks for your help. > Jimmy > > On Tue, Jan 24, 2012 at 4:20 PM, Rich Megginson > wrote: > > On 01/24/2012 02:07 PM, Jimmy wrote: >> certutil output: >> http://fpaste.org/tJDW/ >> >> pcap output (exported from Wireshark, looks messy): >> http://fpaste.org/M3Gr/ > hard to tell from the pcap output, but is > > Serial Number: 68:10:1c:98:3b:5c:e7:8d:43:ec:e3:e7:6a:e7:de:27 > Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption > Issuer: "CN=xxxad-xxx-AD-CA,DC=xxxad,DC=xxx,DC=xxx" > Validity: > Not Before: Thu Jan 19 17:52:07 2012 > Not After : Thu Jan 19 18:02:04 2017 > Subject: "CN=xxxad-xxx-AD-CA,DC=xxxad,DC=xxx,DC=xxx" > > the same cert as the cert from the pcap output that is called > Distinguished Name: > (id-at-commonName=xxxad-XXX-AD-CA,dc=xxxad,dc=xxx,dc=xxx) > > because this appears to be the AD CA cert sent over from AD as > part of the SSL handshake > > There are a couple of good tools to use to diagnose/debug > connection problems between 389 and AD before you attempt to use > winsync with ssl. > > The first is openssl s_client > openssl s_client -connect ADhost:636 -CAfile /path/to/adca.cer > > The second is mozldap ldapsearch: > /usr/lib64/mozldap/ldapsearch -h ADHost -p 636 -Z -P > /etc/dirsrv/slapd-INST/cert8.db -s base -b "" "objectclass=*" > > The third is openldap ldapsearch: > LDAPTLS_CACERT=/path/to/adca.cer ldapsearch -x -h ADHost -p 636 -s > base -b "" "objectclass=*" > > For the last you can add "-d 1" to get detailed SSL error messages >> >> On Tue, Jan 24, 2012 at 3:29 PM, Rich Megginson >> > wrote: >> >> On 01/24/2012 01:26 PM, Jimmy wrote: >>> The sync is still not working so I was going back through >>> the docs to see what I missed. I know this is from an older >>> version of IPA but I was looking here: >>> http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html#sect-Installation_and_Deployment_Guide-Prerequisites-Setting_up_Active_Directory >>> >>> >>> and used this method to get the AD certificate server cert. >> You mean "CA cert" not "server cert", right? >>> >>> 1. >>> Navigate to My Network Places and drill down to the CA >>> distribution point. On Windows 2003 Server this is >>> typically |C:\WINDOWS\system32\certsrv\CertEnroll\| >>> 2. >>> Double-click the security certificate file >>> (|.crt| file) to display the *Certificate* dialog box. >>> 3. >>> On the *Details* tab, click *Copy to File* to start >>> the *Certificate Export Wizard*. >>> 4. >>> Click *Next*, select *Base-64 encoded X.509 >>> (.CER)* and then click *Next*. >>> 5. >>> Specify a suitable directory and file name for the >>> exported file. The file name is not important. Click >>> *Next* to export the certificate, and then click >>> *Finish*. You should receive a message stating that >>> the export was successful. >>> 6. >>> Click *OK* to exit the wizard. >>> >>> But when I run the command to create the sync >>> agreement(pointing to the cert I got in the step above) the >>> ssl connection fails and if I look at tcpdump of the >>> connection I see that the AD server is not sending the cert >>> that I have imported with the sync agreement. I have used >>> certutil to verify that I have the same cert(same serial >>> number and same public key) in the 389 server as the one in >>> the AD server ( >>> C:\WINDOWS\system32\certsrv\CertEnroll\). The AD server is >>> sending a completely different cert, and I have been unable >>> to find the cert in the certificate stores on the AD server >>> so I'm not sure where the bogus cert is coming from. Before >>> I added the certificate services role the certsrv\certenroll >>> directory was not present so I know this was created when I >>> added that role to the AD server. >>> >>> The pcap can be seen here: >>> http://www.pcapr.net/view/g17jimmy/2012/0/2/11/ldaps3.pcap.html (sorry, >>> registration required on that site, I didn't have anywhere >>> else to put it.) >> Can you try fpaste.org ? >>> >>> Any idea why AD would be sending me the wrong cert and where >>> it's coming from? Yes, I know this isn't MS just trying to >>> get these 2 systems to talk ;). >>> >>> On Tue, Jan 24, 2012 at 1:18 PM, Rich Megginson >>> > wrote: >>> >>> On 01/24/2012 11:03 AM, Jimmy wrote: >>>> Ok, I just realized that I only have passsync and not >>>> winsync, stupid oversight, but now that I know it I >>>> need to get winsync. Is there a location to download >>>> binaries or must I compile from source? I see the >>>> binaries for passsync on the directory server project >>>> downloads but I don't see the same for winsync. >>> winsync is built-in to 389 - there isn't any additional >>> component that you need to install. >>> >>>> >>>> Thanks, >>>> Jim >>>> >>>> On Mon, Jan 23, 2012 at 1:33 PM, Rich Megginson >>>> > wrote: >>>> >>>> On 01/23/2012 11:34 AM, Jimmy wrote: >>>>> I did create the winsync user and it is an admin. >>>>> >>>>> I will fix the ip address(change to hostname,) I >>>>> only did it that was because this is currently a >>>>> test system so I can figure out how to get it all >>>>> working. >>>> ok - once you do that, you can check the 389 errors >>>> log at /var/log/dirsrv/slapd-INST/errors to see if >>>> winsync is logging any errors >>>> >>>>> >>>>> On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson >>>>> > >>>>> wrote: >>>>> >>>>> On 01/23/2012 10:52 AM, Jimmy wrote: >>>>>> That's what I was thinking, and what I did, >>>>>> but it still doesn't replicate new users. >>>>>> This is the command I used: >>>>>> >>>>>> ipa-replica-manage connect --passsync >>>>>> --binddn >>>>>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp >>>>>> --bindpw=******** --cacert >>>>>> /home/winsync/AD-server-cert.cer >>>>>> 192.168.201.150 -v >>>>> >>>>> Did you create the user >>>>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp? >>>>> And does this user have the rights to perform >>>>> sync? (e.g. has to have replicator rights, or >>>>> be some sort of admin) - see >>>>> http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx >>>>> - the AD user must have replication rights and >>>>> write rights. >>>>> >>>>> In addition, since this process uses SSL, you >>>>> cannot use an IP address, you must use a >>>>> hostname, or the SSL cert hostname checking >>>>> (for MITM) will fail. >>>>> >>>>>> >>>>>> On Mon, Jan 23, 2012 at 12:30 PM, Rich >>>>>> Megginson >>>>> > wrote: >>>>>> >>>>>> On 01/23/2012 10:19 AM, Jimmy wrote: >>>>>>> Here's what I found in the DS admin >>>>>>> guide. Is this all that's needed to >>>>>>> create the sync agreement? >>>>>> Not with ipa - you should use the >>>>>> ipa-replica-manage command instead >>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> add sync agreement: >>>>>>> ldapmodify -x -D "cn=Directory Manager" -W >>>>>>> Enter LDAP Password: ******* >>>>>>> dn: cn=ExampleSyncAgreement,cn=sync >>>>>>> replica,cn=dc=example\,dc=com,cn=mapping >>>>>>> tree,cn=config >>>>>> it should be cn=replica, not cn=sync >>>>>> replica - does it use the latter in the >>>>>> Admin Guide? >>>>>> >>>>>>> changetype: add >>>>>>> objectclass: top >>>>>>> objectclass: nsDSWindowsReplicationAgreement >>>>>>> cn: ExampleSyncAgreement >>>>>>> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 >>>>>>> nsds7DirectoryReplicaSubtree: >>>>>>> ou=People,dc=example,dc=com >>>>>>> nsds7NewWinUserSyncEnabled: on >>>>>>> nsds7NewWinGroupSyncEnabled: on >>>>>>> nsds7WindowsDomain: ad1 >>>>>>> nsDS5ReplicaRoot: dc=example,dc=com >>>>>>> nsDS5ReplicaHost: ad1.windows-server.com >>>>>>> >>>>>>> nsDS5ReplicaPort: 389 >>>>>>> nsDS5ReplicaBindDN: cn=sync user,cn=config >>>>>>> nsDS5ReplicaBindCredentials: >>>>>>> {DES}ffGad646dT0nnsT8nJOaMA== >>>>>>> nsDS5ReplicaTransportInfo: TLS >>>>>>> winSyncInterval: 1200 >>>>>>> >>>>>>> On Fri, Jan 20, 2012 at 3:28 PM, Rich >>>>>>> Megginson >>>>>> > wrote: >>>>>>> >>>>>>> On 01/20/2012 01:08 PM, Jimmy wrote: >>>>>>>> That was it! I have passwords >>>>>>>> syncing, *BUT*(at the risk of >>>>>>>> sounding stupid)-- is it not >>>>>>>> possible to also sync(add) the >>>>>>>> users from AD to DS? >>>>>>> Yes, it is. Just configure IPA >>>>>>> Windows Sync >>>>>>> >>>>>>>> I created a new user in AD and it >>>>>>>> doesn't propogate to DS, just says: >>>>>>>> >>>>>>>> attempting to sync password for >>>>>>>> testuser3 >>>>>>>> searching for >>>>>>>> (ntuserdomainid=testuser3) >>>>>>>> There are no entries that match: >>>>>>>> testuser3 >>>>>>>> deferring password change for testuser3 >>>>>>>> >>>>>>>> On Fri, Jan 20, 2012 at 2:46 PM, >>>>>>>> Rich Megginson >>>>>>> > wrote: >>>>>>>> >>>>>>>> On 01/20/2012 12:46 PM, Jimmy >>>>>>>> wrote: >>>>>>>>> Getting close here... Now I >>>>>>>>> see this message in the sync >>>>>>>>> log file: >>>>>>>>> >>>>>>>>> attempting to sync password >>>>>>>>> for testuser >>>>>>>>> searching for >>>>>>>>> (ntuserdomainid=testuser) >>>>>>>>> ldap error in queryusername >>>>>>>>> 32: no such object >>>>>>>>> deferring password change for >>>>>>>>> testuser >>>>>>>> This usually means the search >>>>>>>> base is incorrect or not >>>>>>>> found. You can look at the 389 >>>>>>>> access log to see what it was >>>>>>>> using as the search criteria. >>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jan 20, 2012 at 12:23 >>>>>>>>> PM, Rich Megginson >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 01/20/2012 10:23 AM, >>>>>>>>> Jimmy wrote: >>>>>>>>>> You are correct. I had >>>>>>>>>> installed as an >>>>>>>>>> Enterprise root, but the >>>>>>>>>> doc I was >>>>>>>>>> reading(original link) >>>>>>>>>> seemed to say that I had >>>>>>>>>> to do the certreq >>>>>>>>>> manually, my bad. I think >>>>>>>>>> I'm getting closer I can >>>>>>>>>> establish an openssl >>>>>>>>>> connection from DS to AD >>>>>>>>>> but I get these errors: >>>>>>>>>> >>>>>>>>>> openssl s_client >>>>>>>>>> -connect >>>>>>>>>> 192.168.201.150:636 >>>>>>>>>> >>>>>>>>>> -showcerts -CAfile dsca.crt >>>>>>>>>> CONNECTED(00000003) >>>>>>>>>> depth=0 CN = >>>>>>>>>> csp-ad.cspad.pdh.csp >>>>>>>>>> verify >>>>>>>>>> error:num=20:unable to >>>>>>>>>> get local issuer certificate >>>>>>>>>> verify return:1 >>>>>>>>>> depth=0 CN = >>>>>>>>>> csp-ad.cspad.pdh.csp >>>>>>>>>> verify >>>>>>>>>> error:num=27:certificate >>>>>>>>>> not trusted >>>>>>>>>> verify return:1 >>>>>>>>>> depth=0 CN = >>>>>>>>>> csp-ad.cspad.pdh.csp >>>>>>>>>> verify >>>>>>>>>> error:num=21:unable to >>>>>>>>>> verify the first certificate >>>>>>>>>> verify return:1 >>>>>>>>>> >>>>>>>>>> I thought I had imported >>>>>>>>>> the cert from AD but it >>>>>>>>>> doesn't seem so. I'm >>>>>>>>>> still researching but if >>>>>>>>>> you guys have a >>>>>>>>>> suggestion let me know. >>>>>>>>> Is dsca.crt the CA that >>>>>>>>> issued the DS server >>>>>>>>> cert? If so, that won't >>>>>>>>> work. You need the CA >>>>>>>>> cert from the CA that >>>>>>>>> issued the AD server cert >>>>>>>>> (i.e. the CA cert from the >>>>>>>>> MS Enterprise Root CA). >>>>>>>>> >>>>>>>>>> -J >>>>>>>>>> >>>>>>>>>> On Thu, Jan 19, 2012 at >>>>>>>>>> 5:04 PM, Rich Megginson >>>>>>>>>> >>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 01/19/2012 02:59 >>>>>>>>>> PM, Jimmy wrote: >>>>>>>>>>> ok. I started from >>>>>>>>>>> scratch this week on >>>>>>>>>>> this and I think >>>>>>>>>>> I've got the right >>>>>>>>>>> doc and understand >>>>>>>>>>> better where this is >>>>>>>>>>> going. My problem >>>>>>>>>>> now is that when >>>>>>>>>>> configuring SSL on >>>>>>>>>>> the AD server (step >>>>>>>>>>> c in this url: >>>>>>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >>>>>>>>>>> >>>>>>>>>>> I get this error: >>>>>>>>>>> >>>>>>>>>>> certreq -submit >>>>>>>>>>> request.req certnew.cer >>>>>>>>>>> Active Directory >>>>>>>>>>> Enrollment Policy >>>>>>>>>>> >>>>>>>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >>>>>>>>>>> ldap: >>>>>>>>>>> RequestId: 3 >>>>>>>>>>> RequestId: "3" >>>>>>>>>>> Certificate not >>>>>>>>>>> issued (Denied) >>>>>>>>>>> Denied by Policy >>>>>>>>>>> Module 0x80094801, >>>>>>>>>>> The request does not >>>>>>>>>>> contain a >>>>>>>>>>> certificate template >>>>>>>>>>> extension or the >>>>>>>>>>> CertificateTemplate >>>>>>>>>>> request attribute. >>>>>>>>>>> The request >>>>>>>>>>> contains no >>>>>>>>>>> certificate template >>>>>>>>>>> information. >>>>>>>>>>> 0x80094801 >>>>>>>>>>> (-2146875391 >>>>>>>>>>> ) >>>>>>>>>>> Certificate Request >>>>>>>>>>> Processor: The >>>>>>>>>>> request contains no >>>>>>>>>>> certificate template >>>>>>>>>>> information. >>>>>>>>>>> 0x80094801 >>>>>>>>>>> (-2146875391 >>>>>>>>>>> ) >>>>>>>>>>> Denied by Policy >>>>>>>>>>> Module 0x80094801, >>>>>>>>>>> The request does not >>>>>>>>>>> contain a >>>>>>>>>>> certificate template >>>>>>>>>>> extension or the >>>>>>>>>>> CertificateTemplate >>>>>>>>>>> request attribute. >>>>>>>>>>> >>>>>>>>>>> The RH doc says to >>>>>>>>>>> use the browser if >>>>>>>>>>> an error occurs and >>>>>>>>>>> IIS is running but >>>>>>>>>>> I'm not running IIS. >>>>>>>>>>> I researched that >>>>>>>>>>> error but didn't >>>>>>>>>>> find anything that >>>>>>>>>>> helps with FreeIPA >>>>>>>>>>> and passsync. >>>>>>>>>> Hmm - try installing >>>>>>>>>> Microsoft Certificate >>>>>>>>>> Authority in >>>>>>>>>> Enterprise Root CA >>>>>>>>>> mode - it will >>>>>>>>>> usually automatically >>>>>>>>>> create and install >>>>>>>>>> the AD server cert. >>>>>>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Jimmy >>>>>>>>>>> >>>>>>>>>>> On Wed, Jan 11, 2012 >>>>>>>>>>> at 3:32 PM, Rich >>>>>>>>>>> Megginson >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On 01/11/2012 >>>>>>>>>>> 11:22 AM, Jimmy >>>>>>>>>>> wrote: >>>>>>>>>>>> We need to be >>>>>>>>>>>> able to >>>>>>>>>>>> replicate >>>>>>>>>>>> user/pass >>>>>>>>>>>> between Windows >>>>>>>>>>>> 2008 AD and >>>>>>>>>>>> FreeIPA. >>>>>>>>>>> >>>>>>>>>>> That's what IPA >>>>>>>>>>> Windows Sync is >>>>>>>>>>> supposed to do. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I have followed >>>>>>>>>>>> many different >>>>>>>>>>>> documents and >>>>>>>>>>>> posted here >>>>>>>>>>>> about it and >>>>>>>>>>>> from what I've >>>>>>>>>>>> read and >>>>>>>>>>>> procedures I've >>>>>>>>>>>> followed we are >>>>>>>>>>>> unable to >>>>>>>>>>>> accomplish this. >>>>>>>>>>> >>>>>>>>>>> What have you >>>>>>>>>>> tried, and what >>>>>>>>>>> problems have >>>>>>>>>>> you run into? >>>>>>>>>>> >>>>>>>>>>>> It doesn't need >>>>>>>>>>>> to be a full >>>>>>>>>>>> trust. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jan 10, >>>>>>>>>>>> 2012 at 3:03 >>>>>>>>>>>> AM, Jan Zelen? >>>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> > Just >>>>>>>>>>>> wondering >>>>>>>>>>>> if there >>>>>>>>>>>> was anyone >>>>>>>>>>>> listening >>>>>>>>>>>> on the list >>>>>>>>>>>> that might be >>>>>>>>>>>> > available >>>>>>>>>>>> for little >>>>>>>>>>>> work >>>>>>>>>>>> integrating >>>>>>>>>>>> FreeIPA >>>>>>>>>>>> with Active >>>>>>>>>>>> Directory >>>>>>>>>>>> > >>>>>>>>>>>> (preferrably in >>>>>>>>>>>> the south >>>>>>>>>>>> east US.) I >>>>>>>>>>>> hope this >>>>>>>>>>>> isn't >>>>>>>>>>>> against the >>>>>>>>>>>> list >>>>>>>>>>>> > rules, I >>>>>>>>>>>> just >>>>>>>>>>>> thought one >>>>>>>>>>>> of you guys >>>>>>>>>>>> could help >>>>>>>>>>>> or point me >>>>>>>>>>>> in the right >>>>>>>>>>>> > direction. >>>>>>>>>>>> >>>>>>>>>>>> If you want >>>>>>>>>>>> some help, >>>>>>>>>>>> it is >>>>>>>>>>>> certainly >>>>>>>>>>>> not against >>>>>>>>>>>> list rules >>>>>>>>>>>> ;-) But in that >>>>>>>>>>>> case, it >>>>>>>>>>>> would be >>>>>>>>>>>> much better >>>>>>>>>>>> if you >>>>>>>>>>>> asked what >>>>>>>>>>>> exactly do >>>>>>>>>>>> you need. >>>>>>>>>>>> >>>>>>>>>>>> I'm not an >>>>>>>>>>>> AD expert, >>>>>>>>>>>> but a >>>>>>>>>>>> couple >>>>>>>>>>>> tips: If >>>>>>>>>>>> you are >>>>>>>>>>>> looking for >>>>>>>>>>>> cross-domain >>>>>>>>>>>> (cross-realm) >>>>>>>>>>>> trust, then >>>>>>>>>>>> you might >>>>>>>>>>>> be a bit >>>>>>>>>>>> disappointed, >>>>>>>>>>>> it is still in >>>>>>>>>>>> development, so >>>>>>>>>>>> it probably >>>>>>>>>>>> won't be >>>>>>>>>>>> 100% >>>>>>>>>>>> functional >>>>>>>>>>>> at this moment. >>>>>>>>>>>> >>>>>>>>>>>> If you are >>>>>>>>>>>> looking for >>>>>>>>>>>> something >>>>>>>>>>>> else, could >>>>>>>>>>>> you be a >>>>>>>>>>>> little more >>>>>>>>>>>> specific what >>>>>>>>>>>> it is? >>>>>>>>>>>> >>>>>>>>>>>> I also >>>>>>>>>>>> recommend >>>>>>>>>>>> starting >>>>>>>>>>>> with >>>>>>>>>>>> reading >>>>>>>>>>>> some doc: >>>>>>>>>>>> http://freeipa.org/page/DocumentationPortal >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Jan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Freeipa-users mailing list >>>>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From i.am.stack at gmail.com Wed Jan 25 01:30:21 2012 From: i.am.stack at gmail.com (~Stack~) Date: Tue, 24 Jan 2012 19:30:21 -0600 Subject: [Freeipa-users] Using DHCPD with IPA Message-ID: <4F1F5B2D.10500@gmail.com> Hello everyone! Short update for those who have been helping me along both on and off the list. For the last week or so I have had problems getting IPA to integrate into my network setup. It has been frustrating but I have learned so much doing it. Today, I finally had that moment where things just clicked and I realized I was trying to force IPA and BIND (named) to do things that it was already trying to do. That was the source of all my problems. By managing my DNS system *through* the IPA interface *instead* of named.conf the vast majority of my problems went away. I don't know why it took me so long to realize that IPA was /managing/ BIND and not just /adding to/ BIND but it did. Current questions that have me stumped at the moment. 1) Where are the BIND configurations for IPA? The problems I have been having stemmed from the fact that IPA adds just a small blurb at the end of a very vanilla named.conf. Even though IPA is managing my DNS zone and reverse zone, there is nothing in named.conf. Therefore, when I tried to force-cram add my zones to BIND I got lots of errors. As long as I manage my zones from the CLI or web interface, things work, but when I tinker around with the vanilla named.conf file (which does *not* list my IPA configured zones) things break. I poked around but couldn't figure out where this information was stored. This was particularly confusing to me (I am not a named/dhcpd expert by any means) since named.conf didn't include the zone information and I was under the impression I had to include it so that I could share my rndc-key between dhcpd and named (next question). This very frustrating misunderstanding led to all my problems. Back to the point of this question, where does IPA store its zone information for named? I never found any good information in the docs on this subject and would like to know for future reference. 2) How do I get dhcpd to update DNS? Since I can't find the place to add rndc-keys to BIND, right now I have to add every host manually in the web interface because dhcpd isn't updating named. This is time consuming and a pain when dealing with large amounts of systems. If I could figure out where the named zones are stored in IPA I should be able to add my rndc-key and be OK, but that gets back into question 1. My /etc/dhcp/dhcpd.conf file is pretty basic but all the PXE clients have host entries to match their MAC with the group that allows PXE booting (ex: host pxe001.project.local{hardware ethernet 00:16:17:AB:E9:88; fixed-address 172.31.203.1}). Unless I mange both this file and the IPA interface, the nodes have issues figuring out their name. One or the other and the node has issues; both and it works. I would really prefer not to manage two locations for all these nodes. The normal way for dhcpd to talk to BIND(named) is by having a rndc-key. However, me fighting with named.conf was the big part of my problems before so I am hoping there is a simple way of doing this inside IPA. Any ideas? I did see an email in the list a few months back saying that adding dhcpd to IPA was probably not going to happen because IPA isn't a network manager, but I am pretty sure if you ask most people dhcp and dns kinda go hand-in-hand. It should at least be easier to work with the two if IPA is going to completely manage DNS. I found very little in my search of the answer. Maybe I am still just too dumb in these matters to figure it out right now. :-) At least I am learning new stuff! 3) The very first time when I PXEBoot/tftp/kickstart a machine and it auto installs, everything works great. The ipa-client-install runs with all my parameters and it just works. However, the second time the node boots and installs, I get complaints that the system is already registered. (fresh install) # ipa-client-install --mkhomedir ...[snip]... Joining realm failed: Host is already joined. Installation failed. Rolling back changes. IPA client is not configured on this system. If I try to -f force it, I get errors and nothing seems to work. # ipa-client-install --mkhomedir -f ...[snip]... Joining realm failed: Host is already joined. Use ipa-getkeytab to obtain a host principle for this server. ...[snip]... Unable to find 'admin' user with 'getent passwd admin'! For PXEboot nodes that may/will end up with a fresh install, how do I best configure them in IPA? Automatically would be best. Thanks! ~Stack~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From simo at redhat.com Wed Jan 25 01:46:38 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Jan 2012 20:46:38 -0500 Subject: [Freeipa-users] Using DHCPD with IPA In-Reply-To: <4F1F5B2D.10500@gmail.com> References: <4F1F5B2D.10500@gmail.com> Message-ID: <1327455998.13963.141.camel@willson.li.ssimo.org> On Tue, 2012-01-24 at 19:30 -0600, ~Stack~ wrote: > Hello everyone! > > Short update for those who have been helping me along both on and off > the list. > For the last week or so I have had problems getting IPA to integrate > into my network setup. It has been frustrating but I have learned so > much doing it. Today, I finally had that moment where things just > clicked and I realized I was trying to force IPA and BIND (named) to do > things that it was already trying to do. That was the source of all my > problems. By managing my DNS system *through* the IPA interface > *instead* of named.conf the vast majority of my problems went away. I > don't know why it took me so long to realize that IPA was /managing/ > BIND and not just /adding to/ BIND but it did. > > Current questions that have me stumped at the moment. > > 1) Where are the BIND configurations for IPA? They are stored in the LDAP server. > The problems I have been having stemmed from the fact that IPA adds just > a small blurb at the end of a very vanilla named.conf. Even though IPA > is managing my DNS zone and reverse zone, there is nothing in > named.conf. Therefore, when I tried to force-cram add my zones to BIND I > got lots of errors. As long as I manage my zones from the CLI or web > interface, things work, but when I tinker around with the vanilla > named.conf file (which does *not* list my IPA configured zones) things > break. > > I poked around but couldn't figure out where this information was > stored. This was particularly confusing to me (I am not a named/dhcpd > expert by any means) since named.conf didn't include the zone > information and I was under the impression I had to include it so that I > could share my rndc-key between dhcpd and named (next question). This > very frustrating misunderstanding led to all my problems. > > Back to the point of this question, where does IPA store its zone > information for named? I never found any good information in the docs on > this subject and would like to know for future reference. > > 2) How do I get dhcpd to update DNS? The first question is: why do you need DHCP to do that, why don't you let clients securely do it ? We do register a client in the DNS in ipa-client-install. > Since I can't find the place to add rndc-keys to BIND, right now I have > to add every host manually in the web interface because dhcpd isn't > updating named. This is time consuming and a pain when dealing with > large amounts of systems. If I could figure out where the named zones > are stored in IPA I should be able to add my rndc-key and be OK, but > that gets back into question 1. > > My /etc/dhcp/dhcpd.conf file is pretty basic but all the PXE clients > have host entries to match their MAC with the group that allows PXE > booting (ex: host pxe001.project.local{hardware ethernet > 00:16:17:AB:E9:88; fixed-address 172.31.203.1}). Unless I mange both > this file and the IPA interface, the nodes have issues figuring out > their name. One or the other and the node has issues; both and it works. > I would really prefer not to manage two locations for all these nodes. > > The normal way for dhcpd to talk to BIND(named) is by having a rndc-key. > However, me fighting with named.conf was the big part of my problems > before so I am hoping there is a simple way of doing this inside IPA. > > Any ideas? > > I did see an email in the list a few months back saying that adding > dhcpd to IPA was probably not going to happen because IPA isn't a > network manager, but I am pretty sure if you ask most people dhcp and > dns kinda go hand-in-hand. It should at least be easier to work with the > two if IPA is going to completely manage DNS. I found very little in my > search of the answer. Maybe I am still just too dumb in these matters to > figure it out right now. :-) At least I am learning new stuff! > > > 3) The very first time when I PXEBoot/tftp/kickstart a machine and it > auto installs, everything works great. The ipa-client-install runs with > all my parameters and it just works. However, the second time the node > boots and installs, I get complaints that the system is already registered. Install is a one time thing, it creates a record in IPA and gices the machine a keytab. this is data that needs to be preserved across reboots. > (fresh install) > # ipa-client-install --mkhomedir > ...[snip]... > Joining realm failed: Host is already joined. > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > If I try to -f force it, I get errors and nothing seems to work. > # ipa-client-install --mkhomedir -f > ...[snip]... > Joining realm failed: Host is already joined. > Use ipa-getkeytab to obtain a host principle for this server. > ...[snip]... > Unable to find 'admin' user with 'getent passwd admin'! I would say this is expected. > For PXEboot nodes that may/will end up with a fresh install, how do I > best configure them in IPA? Automatically would be best. You have to keep some configuration, ipa-client-install is not compatible with a machine that loses all state at each reboot. You can manage to have machines still fetch data from IPA, but they can't be full fledged clients if you can't preserve the keytab and some other configuration. Note: You could reset the machine account from the IPA interface before a reboot, but requiring admin credentials at each reboot to re-enroll machines is not something I can recommend. Simo. -- Simo Sorce * Red Hat, Inc * New York From i.am.stack at gmail.com Wed Jan 25 02:11:07 2012 From: i.am.stack at gmail.com (~Stack~) Date: Tue, 24 Jan 2012 20:11:07 -0600 Subject: [Freeipa-users] Using DHCPD with IPA In-Reply-To: <1327455998.13963.141.camel@willson.li.ssimo.org> References: <4F1F5B2D.10500@gmail.com> <1327455998.13963.141.camel@willson.li.ssimo.org> Message-ID: <4F1F64BB.7010104@gmail.com> On 01/24/2012 07:46 PM, Simo Sorce wrote: > On Tue, 2012-01-24 at 19:30 -0600, ~Stack~ wrote: [snip] >> 2) How do I get dhcpd to update DNS? > > The first question is: why do you need DHCP to do that, why don't you > let clients securely do it ? > We do register a client in the DNS in ipa-client-install. I have nodes being PXEbooted and the MAC address to distinguish them from other nodes is in the dhcpd.conf. Which means they have to be defined in the dhcpd.conf file. However, if the reverse DNS entry is not enabled when the PXEboot client launches, it doesn't get a hostname and it stalls out long before the ipa-client-install even runs to put an entry into the IPA DNS. [snip] >> 3) The very first time when I PXEBoot/tftp/kickstart a machine and it >> auto installs, everything works great. The ipa-client-install runs with >> all my parameters and it just works. However, the second time the node >> boots and installs, I get complaints that the system is already registered. > > Install is a one time thing, it creates a record in IPA and gices the > machine a keytab. this is data that needs to be preserved across > reboots. Crud. This looks like it could be difficult. I don't preserve anything on those machines. At least not right now... >> (fresh install) >> # ipa-client-install --mkhomedir >> ...[snip]... >> Joining realm failed: Host is already joined. >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> If I try to -f force it, I get errors and nothing seems to work. >> # ipa-client-install --mkhomedir -f >> ...[snip]... >> Joining realm failed: Host is already joined. >> Use ipa-getkeytab to obtain a host principle for this server. >> ...[snip]... >> Unable to find 'admin' user with 'getent passwd admin'! > > I would say this is expected. > >> For PXEboot nodes that may/will end up with a fresh install, how do I >> best configure them in IPA? Automatically would be best. > > You have to keep some configuration, ipa-client-install is not > compatible with a machine that loses all state at each reboot. > > You can manage to have machines still fetch data from IPA, but they > can't be full fledged clients if you can't preserve the keytab and some > other configuration. As long as I can have a user log into the box and run a process, I don't really care if they are a full client or not. Theses systems are never logged into directly, but through a ssh connection so if the users can still authenticate into them I might be good on this. How do I configure this? > Note: You could reset the machine account from the IPA interface before > a reboot, but requiring admin credentials at each reboot to re-enroll > machines is not something I can recommend. I agree. I may have to rethink this. Thank you for your response! ~Stack~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From sgallagh at redhat.com Wed Jan 25 12:27:23 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 25 Jan 2012 07:27:23 -0500 Subject: [Freeipa-users] Using DHCPD with IPA In-Reply-To: <4F1F64BB.7010104@gmail.com> References: <4F1F5B2D.10500@gmail.com> <1327455998.13963.141.camel@willson.li.ssimo.org> <4F1F64BB.7010104@gmail.com> Message-ID: <1327494443.2250.203.camel@sgallagh520.sgallagh.bos.redhat.com> On Tue, 2012-01-24 at 20:11 -0600, ~Stack~ wrote: > > You can manage to have machines still fetch data from IPA, but they > > can't be full fledged clients if you can't preserve the keytab and some > > other configuration. > > As long as I can have a user log into the box and run a process, I don't > really care if they are a full client or not. Theses systems are never > logged into directly, but through a ssh connection so if the users can > still authenticate into them I might be good on this. How do I configure > this? You can set the clients up as pure LDAP+KRB5 clients in SSSD, but the catch is that you lose the ability to configure them with HBAC rules. (You need to do more traditional forms of access-control logic in that case). Only fully-enrolled clients will honor HBAC rules at this time. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From shelltoesuperstar at gmail.com Wed Jan 25 14:28:05 2012 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Wed, 25 Jan 2012 14:28:05 +0000 Subject: [Freeipa-users] A couple of issues found with ipa-2.1.3-9 during setup/early use Message-ID: Hi I've been testing our potential new IPA server before roll out and while setting up a replica with ipa-server-2.1.3-9 I encountered the following issues during installation [root at ipa2 ~]# ipa-replica-install --setup-dns --no-forwarders --no-ntp /var/lib/ipa/replica-info-ipa2.test.net.gpg Directory Manager (existing master) password:**** ** ** Run connection check to master**** Check connection from replica to remote master 'ipa1.test.net':**** Directory Service: Unsecure port (389): OK**** Directory Service: Secure port (636): OK**** Kerberos KDC: TCP (88): OK**** Kerberos KDC: UDP (88): OK**** Kerberos Kpasswd: TCP (464): OK**** Kerberos Kpasswd: UDP (464): OK**** HTTP Server: port 80 (80): OK**** HTTP Server: port 443(https) (443): OK**** ** ** Connection from replica to master is OK.**** Start listening on required ports for remote master check**** Exception in thread Thread-2:**** Traceback (most recent call last):**** File "/usr/lib64/python2.6/threading.py", line 532, in __bootstrap_inner** ** self.run()**** File "/usr/sbin/ipa-replica-conncheck", line 238, in run**** self.socket_timeout, responder_data="FreeIPA") File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line 1134, in bind_port_responder**** raise e**** error: [Errno 97] Address family not supported by protocol The same error runs across all threads. Turning on debug I can see that it happens when this command is passed to the server ipa-replica-conncheck --master ipa1.test.net --auto-master-check --realm TEST.NET --principal admin --hostname ipa2.test.net I got round that by running --skip-conncheck during the replica-install but was suprised I've heard no-one else has mentioned the issue is there anyway I can get some lower level debug info to find out the root cause of the issue? The other thing I noticed is when hosts enroll no timestamp appears in the "Enrolled?" column on the webui, it's not a major problem but my guys quite liked using it as a visual aid to work though the servers they had configured. I've looked at the 2.1.4 change log and nothing was mentioned regarding fixes for either issue. Cheers, Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From g17jimmy at gmail.com Wed Jan 25 15:13:57 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 25 Jan 2012 10:13:57 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F1F2A0F.9030908@redhat.com> References: <4F19A320.8080501@redhat.com> <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> <4F1DA80E.2070904@redhat.com> <4F1EF609.2040007@redhat.com> <4F1F14A0.2090901@redhat.com> <4F1F20B9.50509@redhat.com> <4F1F2A0F.9030908@redhat.com> Message-ID: Here is the showcerts output: http://fpaste.org/AkOC/ I'll do the ldapsearch commands in a sec. Thanks- Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Jan 25 15:19:43 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 25 Jan 2012 08:19:43 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <4F19C499.5090803@redhat.com> <4F19CE6D.6010101@redhat.com> <4F1D9953.7060408@redhat.com> <4F1DA196.3070808@redhat.com> <4F1DA80E.2070904@redhat.com> <4F1EF609.2040007@redhat.com> <4F1F14A0.2090901@redhat.com> <4F1F20B9.50509@redhat.com> <4F1F2A0F.9030908@redhat.com> Message-ID: <4F201D8F.4070305@redhat.com> On 01/25/2012 08:13 AM, Jimmy wrote: > Here is the showcerts output: > > http://fpaste.org/AkOC/ > Looks like pcap output, not openssl s_client output - I have no idea if there is a showcerts option for pcap, or how it works, but it looks like it didn't work > I'll do the ldapsearch commands in a sec. > Thanks- > Jimmy From rcritten at redhat.com Wed Jan 25 16:52:04 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Jan 2012 11:52:04 -0500 Subject: [Freeipa-users] A couple of issues found with ipa-2.1.3-9 during setup/early use In-Reply-To: References: Message-ID: <4F203334.3090004@redhat.com> Charlie Derwent wrote: > Hi > I've been testing our potential new IPA server before roll out and while > setting up a replica with ipa-server-2.1.3-9 I encountered the following > issues during installation > [root at ipa2 ~]# ipa-replica-install --setup-dns --no-forwarders --no-ntp > /var/lib/ipa/replica-info-ipa2.test.net.gpg > > Directory Manager (existing master) password:____ > > __ __ > > Run connection check to master____ > > Check connection from replica to remote master 'ipa1.test.net > ':____ > > Directory Service: Unsecure port (389): OK____ > > Directory Service: Secure port (636): OK____ > > Kerberos KDC: TCP (88): OK____ > > Kerberos KDC: UDP (88): OK____ > > Kerberos Kpasswd: TCP (464): OK____ > > Kerberos Kpasswd: UDP (464): OK____ > > HTTP Server: port 80 (80): OK____ > > HTTP Server: port 443(https) (443): OK____ > > __ __ > > Connection from replica to master is OK.____ > > Start listening on required ports for remote master check____ > > Exception in thread Thread-2:____ > > Traceback (most recent call last):____ > > File "/usr/lib64/python2.6/threading.py", line 532, in > __bootstrap_inner____ > > self.run()____ > > File "/usr/sbin/ipa-replica-conncheck", line 238, in run____ > > self.socket_timeout, responder_data="FreeIPA") > > File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line > 1134, in bind_port_responder____ > > raise e____ > > error: [Errno 97] Address family not supported by protocol > The same error runs across all threads. Turning on debug I can see that > it happens when this command is passed to the server > ipa-replica-conncheck --master ipa1.test.net > --auto-master-check --realm TEST.NET --principal admin > --hostname ipa2.test.net Hmm, what does your network config look like? IPv4-only, IPv6-only or a mix? > I got round that by running --skip-conncheck during the replica-install > but was suprised I've heard no-one else has mentioned the issue is there > anyway I can get some lower level debug info to find out the root cause > of the issue? The other thing I noticed is when hosts enroll no > timestamp appears in the "Enrolled?" column on the webui, it's not a > major problem but my guys quite liked using it as a visual aid to work > though the servers they had configured. I've looked at the 2.1.4 change > log and nothing was mentioned regarding fixes for either issue. IIRC the UI was using the date of the last host service principal password change as the date of enrollment and this could be misleading so we changed it to a simple yes/no. rob From sylvainangers at gmail.com Wed Jan 25 18:00:54 2012 From: sylvainangers at gmail.com (Sylvain Angers) Date: Wed, 25 Jan 2012 13:00:54 -0500 Subject: [Freeipa-users] Aix client configuration Message-ID: Hello In our lab, we are testing latest ipa on redhat and we are now configuring/testing an IBM/AIX client 6.1 Here is the ipa server command that we used *ipa-server-install -a ipa123 --hostname=mtl-ipa01d.cnppd.lab -n cnppd.lab -p ldap123 -r CNPPD.LAB * We are following your documentation for AIX client and have some issue getting through the step we had to install these fileset and we still fight modcrypt lslpp -L | grep idsldap idsldap.clt32bit61.rte 6.1.0.34 C F Directory Server - 32 bit idsldap.clt64bit61.rte 6.1.0.34 C F Directory Server - 64 bit idsldap.cltbase61.adt 6.1.0.34 C F Directory Server - Base Client idsldap.cltbase61.rte 6.1.0.34 C F Directory Server - Base Client lslpp -L | grep krb krb5.client.rte 1.5.0.2 C F Network Authentication Service krb5.client.samples 1.5.0.2 C F Network Authentication Service krb5.doc.en_US.html 1.5.0.2 C F Network Auth Service HTML krb5.doc.en_US.pdf 1.5.0.2 C F Network Auth Service PDF krb5.lic 1.5.0.2 C F Network Authentication Service krb5.msg.en_US.client.rte 1.5.0.2 C F Network Auth Service Client krb5.server.rte 1.5.0.2 C F Network Authentication Service ww did run the mksecldap command, as follow *mksecldap -c -h mtl-ipa01d.cnppd.lab -d cn=accounts,dc=cnppd,dc=lab -a uid=nss,cn=sysaccounts,cn=etc,dc=cnppd,dc=lab -p abc123* and we got : Invalid bind DN or bind passwd. Client presetup check failed. Do we need to customize further this command if so, what are we missing? also as we have not yet succeed to make modcrypt works on our AIX 6.1, we wonder if we will need (temporary) to do some ldapmodify on the ipa server to disable ssl? Thank you for your assistance! appreciate -- Sylvain Angers -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Jan 25 18:30:10 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Jan 2012 13:30:10 -0500 Subject: [Freeipa-users] Aix client configuration In-Reply-To: References: Message-ID: <4F204A32.4070602@redhat.com> Sylvain Angers wrote: > Hello > In our lab, we are testing latest ipa on redhat and we are now > configuring/testing an IBM/AIX client 6.1 > > Here is the ipa server command that we used > *ipa-server-install -a ipa123 --hostname=mtl-ipa01d.cnppd.lab -n > cnppd.lab -p ldap123 -r CNPPD.LAB * > > We are following your documentation for AIX client and have some issue > getting through the step > > we had to install these fileset and we still fight modcrypt > > lslpp -L | grep idsldap > idsldap.clt32bit61.rte 6.1.0.34 C F Directory Server - 32 bit > idsldap.clt64bit61.rte 6.1.0.34 C F Directory Server - 64 bit > idsldap.cltbase61.adt 6.1.0.34 C F Directory Server - > Base Client > idsldap.cltbase61.rte 6.1.0.34 C F Directory Server - > Base Client > > > lslpp -L | grep krb > krb5.client.rte 1.5.0.2 C F Network > Authentication Service > krb5.client.samples 1.5.0.2 C F Network > Authentication Service > krb5.doc.en_US.html 1.5.0.2 C F Network Auth Service HTML > krb5.doc.en_US.pdf 1.5.0.2 C F Network Auth Service PDF > krb5.lic 1.5.0.2 C F Network > Authentication Service > krb5.msg.en_US.client.rte 1.5.0.2 C F Network Auth Service > Client > krb5.server.rte 1.5.0.2 C F Network > Authentication Service > > ww did run the mksecldap command, as follow > > *mksecldap -c -h mtl-ipa01d.cnppd.lab -d cn=accounts,dc=cnppd,dc=lab -a > uid=nss,cn=sysaccounts,cn=etc,dc=cnppd,dc=lab -p abc123* > > and we got : Invalid bind DN or bind passwd. Client presetup check failed. > > Do we need to customize further this command if so, what are we missing? > also as we have not yet succeed to make modcrypt works on our AIX 6.1, > we wonder if we will need (temporary) to do some ldapmodify on the ipa > server to disable ssl? > > Thank you for your assistance! Did you create the entry uid=nss,cn=sysaccounts,cn=etc,... ? You can test that the password is correct independently with ldapsearch and the 389-ds access log may have additional information on the bind failure. rob From g17jimmy at gmail.com Wed Jan 25 19:07:10 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 25 Jan 2012 14:07:10 -0500 Subject: [Freeipa-users] consulting? In-Reply-To: <4F18935B.6000803@redhat.com> References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> Message-ID: Found the reason for the ldap search not working- when I created the AD certificate role, I accidentally entered a new sub-domain so in stead of the FQDN in the cert being csp-ad.pdh.csp it came out csp-ad.cspad.pdh.csp. I updated DNS and now the ldap search seems to work- ldif output-- http://fpaste.org/xbOC/ debug- http://fpaste.org/6g8q/ I guess I need to redo the sync agreement to fix the server DNS name. I will be traveling for work for the next couple days but should still be working on this issue some. I'll take VM's of the servers on my laptop to be able to keep working. -Jimmy On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson wrote: > ** > On 01/19/2012 02:59 PM, Jimmy wrote: > > ok. I started from scratch this week on this and I think I've got the > right doc and understand better where this is going. My problem now is that > when configuring SSL on the AD server (step c in this url: > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) > > I get this error: > > certreq -submit request.req certnew.cer > Active Directory Enrollment Policy > {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} > ldap: > RequestId: 3 > RequestId: "3" > Certificate not issued (Denied) Denied by Policy Module 0x80094801, The > request does not contain a certificate template extension or the > CertificateTemplate request attribute. > The request contains no certificate template information. 0x80094801 > (-2146875391) > Certificate Request Processor: The request contains no certificate > template information. 0x80094801 (-2146875391) > Denied by Policy Module 0x80094801, The request does not contain a > certificate template extension or the CertificateTemplate request attribute. > > The RH doc says to use the browser if an error occurs and IIS is running > but I'm not running IIS. I researched that error but didn't find anything > that helps with FreeIPA and passsync. > > Hmm - try installing Microsoft Certificate Authority in Enterprise Root CA > mode - it will usually automatically create and install the AD server > cert. http://directory.fedoraproject.org/wiki/Howto:WindowsSync > > > Jimmy > > On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson wrote: > >> On 01/11/2012 11:22 AM, Jimmy wrote: >> >> We need to be able to replicate user/pass between Windows 2008 AD and >> FreeIPA. >> >> >> That's what IPA Windows Sync is supposed to do. >> >> >> I have followed many different documents and posted here about it and >> from what I've read and procedures I've followed we are unable to >> accomplish this. >> >> >> What have you tried, and what problems have you run into? >> >> It doesn't need to be a full trust. >> >> Thanks >> >> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? wrote: >> >>> > Just wondering if there was anyone listening on the list that might >>> be >>> > available for little work integrating FreeIPA with Active Directory >>> > (preferrably in the south east US.) I hope this isn't against the list >>> > rules, I just thought one of you guys could help or point me in the >>> right >>> > direction. >>> >>> If you want some help, it is certainly not against list rules ;-) But >>> in that >>> case, it would be much better if you asked what exactly do you need. >>> >>> I'm not an AD expert, but a couple tips: If you are looking for >>> cross-domain >>> (cross-realm) trust, then you might be a bit disappointed, it is still in >>> development, so it probably won't be 100% functional at this moment. >>> >>> If you are looking for something else, could you be a little more >>> specific what >>> it is? >>> >>> I also recommend starting with reading some doc: >>> http://freeipa.org/page/DocumentationPortal >>> >>> Thanks >>> Jan >>> >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Jan 25 19:14:47 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 25 Jan 2012 12:14:47 -0700 Subject: [Freeipa-users] consulting? In-Reply-To: References: <201201100903.22597.jzeleny@redhat.com> <4F0DF1C3.2020506@redhat.com> <4F18935B.6000803@redhat.com> Message-ID: <4F2054A7.3010300@redhat.com> On 01/25/2012 12:07 PM, Jimmy wrote: > Found the reason for the ldap search not working- when I created the > AD certificate role, I accidentally entered a new sub-domain so in > stead of the FQDN in the cert being csp-ad.pdh.csp it came out > csp-ad.cspad.pdh.csp. I updated DNS and now the ldap search seems to > work- > > ldif output-- http://fpaste.org/xbOC/ > debug- http://fpaste.org/6g8q/ > > I guess I need to redo the sync agreement to fix the server DNS name. Yep. When using TLS/SSL you have to pay close attention to hostnames. > > I will be traveling for work for the next couple days but should still > be working on this issue some. I'll take VM's of the servers on my > laptop to be able to keep working. > -Jimmy > > On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson > wrote: > > On 01/19/2012 02:59 PM, Jimmy wrote: >> ok. I started from scratch this week on this and I think I've got >> the right doc and understand better where this is going. My >> problem now is that when configuring SSL on the AD server (step c >> in this url: >> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service ) >> >> I get this error: >> >> certreq -submit request.req certnew.cer >> Active Directory Enrollment Policy >> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42} >> ldap: >> RequestId: 3 >> RequestId: "3" >> Certificate not issued (Denied) Denied by Policy Module >> 0x80094801, The request does not contain a certificate template >> extension or the CertificateTemplate request attribute. >> The request contains no certificate template information. >> 0x80094801 (-2146875391 ) >> Certificate Request Processor: The request contains no >> certificate template information. 0x80094801 (-2146875391 >> ) >> Denied by Policy Module 0x80094801, The request does not contain >> a certificate template extension or the CertificateTemplate >> request attribute. >> >> The RH doc says to use the browser if an error occurs and IIS is >> running but I'm not running IIS. I researched that error but >> didn't find anything that helps with FreeIPA and passsync. > Hmm - try installing Microsoft Certificate Authority in Enterprise > Root CA mode - it will usually automatically create and install > the AD server cert. > http://directory.fedoraproject.org/wiki/Howto:WindowsSync > >> >> Jimmy >> >> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson >> > wrote: >> >> On 01/11/2012 11:22 AM, Jimmy wrote: >>> We need to be able to replicate user/pass between Windows >>> 2008 AD and FreeIPA. >> >> That's what IPA Windows Sync is supposed to do. >> >> >>> I have followed many different documents and posted here >>> about it and from what I've read and procedures I've >>> followed we are unable to accomplish this. >> >> What have you tried, and what problems have you run into? >> >>> It doesn't need to be a full trust. >>> >>> Thanks >>> >>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelen? >>> > wrote: >>> >>> > Just wondering if there was anyone listening on the >>> list that might be >>> > available for little work integrating FreeIPA with >>> Active Directory >>> > (preferrably in the south east US.) I hope this isn't >>> against the list >>> > rules, I just thought one of you guys could help or >>> point me in the right >>> > direction. >>> >>> If you want some help, it is certainly not against list >>> rules ;-) But in that >>> case, it would be much better if you asked what exactly >>> do you need. >>> >>> I'm not an AD expert, but a couple tips: If you are >>> looking for cross-domain >>> (cross-realm) trust, then you might be a bit >>> disappointed, it is still in >>> development, so it probably won't be 100% functional at >>> this moment. >>> >>> If you are looking for something else, could you be a >>> little more specific what >>> it is? >>> >>> I also recommend starting with reading some doc: >>> http://freeipa.org/page/DocumentationPortal >>> >>> Thanks >>> Jan >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvainangers at gmail.com Wed Jan 25 21:58:42 2012 From: sylvainangers at gmail.com (Sylvain Angers) Date: Wed, 25 Jan 2012 16:58:42 -0500 Subject: [Freeipa-users] Aix client configuration In-Reply-To: <4F204A32.4070602@redhat.com> References: <4F204A32.4070602@redhat.com> Message-ID: 2012/1/25 Rob Crittenden > Sylvain Angers wrote: > >> Hello >> In our lab, we are testing latest ipa on redhat and we are now >> configuring/testing an IBM/AIX client 6.1 >> >> Here is the ipa server command that we used >> *ipa-server-install -a ipa123 --hostname=mtl-ipa01d.cnppd.**lab -n >> cnppd.lab -p ldap123 -r CNPPD.LAB * >> >> >> We are following your documentation for AIX client and have some issue >> getting through the step >> >> we had to install these fileset and we still fight modcrypt >> >> lslpp -L | grep idsldap >> idsldap.clt32bit61.rte 6.1.0.34 C F Directory Server - 32 >> bit >> idsldap.clt64bit61.rte 6.1.0.34 C F Directory Server - 64 >> bit >> idsldap.cltbase61.adt 6.1.0.34 C F Directory Server - >> Base Client >> idsldap.cltbase61.rte 6.1.0.34 C F Directory Server - >> Base Client >> >> >> lslpp -L | grep krb >> krb5.client.rte 1.5.0.2 C F Network >> Authentication Service >> krb5.client.samples 1.5.0.2 C F Network >> Authentication Service >> krb5.doc.en_US.html 1.5.0.2 C F Network Auth Service >> HTML >> krb5.doc.en_US.pdf 1.5.0.2 C F Network Auth Service PDF >> krb5.lic 1.5.0.2 C F Network >> Authentication Service >> krb5.msg.en_US.client.rte 1.5.0.2 C F Network Auth Service >> Client >> krb5.server.rte 1.5.0.2 C F Network >> Authentication Service >> >> ww did run the mksecldap command, as follow >> >> *mksecldap -c -h mtl-ipa01d.cnppd.lab -d cn=accounts,dc=cnppd,dc=lab -a >> uid=nss,cn=sysaccounts,cn=etc,**dc=cnppd,dc=lab -p abc123* >> >> >> and we got : Invalid bind DN or bind passwd. Client presetup check >> failed. >> >> Do we need to customize further this command if so, what are we missing? >> also as we have not yet succeed to make modcrypt works on our AIX 6.1, >> we wonder if we will need (temporary) to do some ldapmodify on the ipa >> server to disable ssl? >> >> Thank you for your assistance! >> > > Did you create the entry uid=nss,cn=sysaccounts,cn=etc,**... ? > > You can test that the password is correct independently with ldapsearch > and the 389-ds access log may have additional information on the bind > failure. > > rob > Hello Rob, All I see at the moment is uid=sudo,cn=sysaccounts,cn=etc,dc=cnppd,dc=lab uid=kdc,cn=sysaccounts,cn=etc,dc=cnppd,dc=lab whenever I create new users, it get under uid=nss,cn=users,cn=accounts,dc=cnppd,dc=lab How do we create uid=nss,cn=sysaccounts,cn=etc,**dc=cnppd,dc=lab ? is this something we have to manually do via ldapadd? about the nss password will the ldapadd be part of the command? Thanks -- Sylvain Angers -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Wed Jan 25 23:18:24 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 26 Jan 2012 00:18:24 +0100 Subject: [Freeipa-users] Using DHCPD with IPA In-Reply-To: <4F1F5B2D.10500@gmail.com> References: <4F1F5B2D.10500@gmail.com> Message-ID: <4F208DC0.6030602@nixtra.com> On 01/25/2012 02:30 AM, ~Stack~ wrote: > 2) How do I get dhcpd to update DNS? > > Since I can't find the place to add rndc-keys to BIND, right now I have > to add every host manually in the web interface because dhcpd isn't > updating named. This is time consuming and a pain when dealing with > large amounts of systems. If I could figure out where the named zones > are stored in IPA I should be able to add my rndc-key and be OK, but > that gets back into question 1. > > My /etc/dhcp/dhcpd.conf file is pretty basic but all the PXE clients > have host entries to match their MAC with the group that allows PXE > booting (ex: host pxe001.project.local{hardware ethernet > 00:16:17:AB:E9:88; fixed-address 172.31.203.1}). Unless I mange both > this file and the IPA interface, the nodes have issues figuring out > their name. One or the other and the node has issues; both and it works. > I would really prefer not to manage two locations for all these nodes. > > The normal way for dhcpd to talk to BIND(named) is by having a rndc-key. > However, me fighting with named.conf was the big part of my problems > before so I am hoping there is a simple way of doing this inside IPA. > > Any ideas? This is what I have done to work around issues similar to yours. Over a few years I have developed a pxe boot toolbox called OneClickKick. OCK manages DHCPD by generating config files based upon information looked up from naming sources such as Mysql, NIS, or LDAP (IPA). It also creates the PXE boot files in tftpboot/pxelinux.cfg, and serves kickstart files when PXE booting clients. I have integrated OCK with IPA to make IPA keep records of the MAC address, and base my DHCP config upon the information I get from IPA. For your configuration, the steps for adding a new client would be the following: 1. Add the host to IPA, specify an IP address so that forward and reverse DNS records are created for the host 2. The host will appear in OneClickKick, select modify, add the MAC address (this is being written to the host object in IPA), and select it for PXE boot / kickstart. This will generate the DHCP config file, reload dhcpd, and create the required files in the tftpboot/pxelinux.cfg directory (if you enabled it for PXE booting). 3. PXE boot the client. By doing this you eliminate the need for dhcpd to update the DNS server, because the records are already there. The MAC addresses stored in IPA can also be used by normal Linux and Solaris (Jumpstart) clients by utilizing their "ethers" table in nsswitch.conf. Have a look at the link below to read more and download if you think OneClickKick could suit your environment. http://sourceforge.net/projects/oneclickkick/ Regards, Siggi From i.am.stack at gmail.com Thu Jan 26 00:38:22 2012 From: i.am.stack at gmail.com (~Stack~) Date: Wed, 25 Jan 2012 18:38:22 -0600 Subject: [Freeipa-users] Using DHCPD with IPA In-Reply-To: <4F208DC0.6030602@nixtra.com> References: <4F1F5B2D.10500@gmail.com> <4F208DC0.6030602@nixtra.com> Message-ID: <4F20A07E.8070801@gmail.com> On 01/25/2012 05:18 PM, Sigbjorn Lie wrote: > On 01/25/2012 02:30 AM, ~Stack~ wrote: >> 2) How do I get dhcpd to update DNS? >> >> Since I can't find the place to add rndc-keys to BIND, right now I have >> to add every host manually in the web interface because dhcpd isn't >> updating named. This is time consuming and a pain when dealing with >> large amounts of systems. If I could figure out where the named zones >> are stored in IPA I should be able to add my rndc-key and be OK, but >> that gets back into question 1. >> >> My /etc/dhcp/dhcpd.conf file is pretty basic but all the PXE clients >> have host entries to match their MAC with the group that allows PXE >> booting (ex: host pxe001.project.local{hardware ethernet >> 00:16:17:AB:E9:88; fixed-address 172.31.203.1}). Unless I mange both >> this file and the IPA interface, the nodes have issues figuring out >> their name. One or the other and the node has issues; both and it works. >> I would really prefer not to manage two locations for all these nodes. >> >> The normal way for dhcpd to talk to BIND(named) is by having a rndc-key. >> However, me fighting with named.conf was the big part of my problems >> before so I am hoping there is a simple way of doing this inside IPA. >> >> Any ideas? > > This is what I have done to work around issues similar to yours. > > Over a few years I have developed a pxe boot toolbox called > OneClickKick. OCK manages DHCPD by generating config files based upon > information looked up from naming sources such as Mysql, NIS, or LDAP > (IPA). It also creates the PXE boot files in tftpboot/pxelinux.cfg, and > serves kickstart files when PXE booting clients. > > I have integrated OCK with IPA to make IPA keep records of the MAC > address, and base my DHCP config upon the information I get from IPA. > For your configuration, the steps for adding a new client would be the > following: > > 1. Add the host to IPA, specify an IP address so that forward and > reverse DNS records are created for the host > 2. The host will appear in OneClickKick, select modify, add the MAC > address (this is being written to the host object in IPA), and select it > for PXE boot / kickstart. This will generate the DHCP config file, > reload dhcpd, and create the required files in the tftpboot/pxelinux.cfg > directory (if you enabled it for PXE booting). > 3. PXE boot the client. > > By doing this you eliminate the need for dhcpd to update the DNS server, > because the records are already there. > > The MAC addresses stored in IPA can also be used by normal Linux and > Solaris (Jumpstart) clients by utilizing their "ethers" table in > nsswitch.conf. > > Have a look at the link below to read more and download if you think > OneClickKick could suit your environment. > > http://sourceforge.net/projects/oneclickkick/ Thank you! I will take a look at it tomorrow. ~Stack~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Thu Jan 26 14:02:50 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Jan 2012 09:02:50 -0500 Subject: [Freeipa-users] Aix client configuration In-Reply-To: References: <4F204A32.4070602@redhat.com> Message-ID: <4F215D0A.2010803@redhat.com> Sylvain Angers wrote: > > > 2012/1/25 Rob Crittenden > > > Sylvain Angers wrote: > > Hello > In our lab, we are testing latest ipa on redhat and we are now > configuring/testing an IBM/AIX client 6.1 > > Here is the ipa server command that we used > *ipa-server-install -a ipa123 --hostname=mtl-ipa01d.cnppd.__lab -n > cnppd.lab -p ldap123 -r CNPPD.LAB * > > > We are following your documentation for AIX client and have some > issue > getting through the step > > we had to install these fileset and we still fight modcrypt > > lslpp -L | grep idsldap > idsldap.clt32bit61.rte 6.1.0.34 C F Directory > Server - 32 bit > idsldap.clt64bit61.rte 6.1.0.34 C F Directory > Server - 64 bit > idsldap.cltbase61.adt 6.1.0.34 C F Directory > Server - > Base Client > idsldap.cltbase61.rte 6.1.0.34 C F Directory > Server - > Base Client > > > lslpp -L | grep krb > krb5.client.rte 1.5.0.2 C F Network > Authentication Service > krb5.client.samples 1.5.0.2 C F Network > Authentication Service > krb5.doc.en_US.html 1.5.0.2 C F Network Auth > Service HTML > krb5.doc.en_US.pdf 1.5.0.2 C F Network Auth > Service PDF > krb5.lic 1.5.0.2 C F Network > Authentication Service > krb5.msg.en_US.client.rte 1.5.0.2 C F Network Auth > Service > Client > krb5.server.rte 1.5.0.2 C F Network > Authentication Service > > ww did run the mksecldap command, as follow > > *mksecldap -c -h mtl-ipa01d.cnppd.lab -d > cn=accounts,dc=cnppd,dc=lab -a > uid=nss,cn=sysaccounts,cn=etc,__dc=cnppd,dc=lab -p abc123* > > > and we got : Invalid bind DN or bind passwd. Client presetup > check failed. > > Do we need to customize further this command if so, what are we > missing? > also as we have not yet succeed to make modcrypt works on our > AIX 6.1, > we wonder if we will need (temporary) to do some ldapmodify on > the ipa > server to disable ssl? > > Thank you for your assistance! > > > Did you create the entry uid=nss,cn=sysaccounts,cn=etc,__... ? > > You can test that the password is correct independently with > ldapsearch and the 389-ds access log may have additional information > on the bind failure. > > rob > > Hello Rob, > > All I see at the moment is > uid=sudo,cn=sysaccounts,cn=etc,dc=cnppd,dc=lab > uid=kdc,cn=sysaccounts,cn=etc,dc=cnppd,dc=lab > > whenever I create new users, it get under > > uid=nss,cn=users,cn=accounts,dc=cnppd,dc=lab > > How do we create uid=nss,cn=sysaccounts,cn=etc,__dc=cnppd,dc=lab ? > > is this something we have to manually do via ldapadd? > about the nss password will the ldapadd be part of the command? > > Thanks > > -- > Sylvain Angers > Use ldapmodify to create this entry: # ldapmodify -D "cn=directory manager" -w secret -p 389 -h ipaserver.example.com -x -a dn: uid=nss,cn=sysaccounts,cn=etc,dc=example,dc=com objectClass: account objectClass: simplesecurityobject objectClass: top uid: nss userPassword: secretpassword This is documented at http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_AIX.html rob From ayoung at redhat.com Thu Jan 26 14:54:23 2012 From: ayoung at redhat.com (Adam Young) Date: Thu, 26 Jan 2012 09:54:23 -0500 Subject: [Freeipa-users] Using DHCPD with IPA In-Reply-To: <4F1F64BB.7010104@gmail.com> References: <4F1F5B2D.10500@gmail.com> <1327455998.13963.141.camel@willson.li.ssimo.org> <4F1F64BB.7010104@gmail.com> Message-ID: <4F21691F.4060007@redhat.com> On 01/24/2012 09:11 PM, ~Stack~ wrote: > Crud. This looks like it could be difficult. I don't preserve anything > on those machines. At least not right now... It is a boot strap issue. For a shared nothing boot like you are doing, there needs to be a way for the new machine to securely get its identity. Ideally, PXE boot would give you the option to somehow store a private key in the BIOS and present a certificate during boot. If it did that, you could then set up a secure way to tell the IPA server "I am still who I claimed I was before" and fetch all of your secure data during the start up process. Assuming your data center is locked down and a rouge machine cannot PXE boot on your local interface, what you would need is probably a way to push down a one time password to the booting machine so that it could then use that to refetch its keytab from the IPA server. Not something currently supported (only happens during register). You can unregister and then register the machines when you reboot them. I am pretty sure that you don't really want to do that, though. From i.am.stack at gmail.com Fri Jan 27 03:59:19 2012 From: i.am.stack at gmail.com (~Stack~) Date: Thu, 26 Jan 2012 21:59:19 -0600 Subject: [Freeipa-users] Using DHCPD with IPA In-Reply-To: <4F21691F.4060007@redhat.com> References: <4F1F5B2D.10500@gmail.com> <1327455998.13963.141.camel@willson.li.ssimo.org> <4F1F64BB.7010104@gmail.com> <4F21691F.4060007@redhat.com> Message-ID: <4F222117.5080706@gmail.com> On 01/26/2012 08:54 AM, Adam Young wrote: > On 01/24/2012 09:11 PM, ~Stack~ wrote: >> Crud. This looks like it could be difficult. I don't preserve anything >> on those machines. At least not right now... > It is a boot strap issue. For a shared nothing boot like you are > doing, there needs to be a way for the new machine to securely get its > identity. > > Ideally, PXE boot would give you the option to somehow store a private > key in the BIOS and present a certificate during boot. If it did that, > you could then set up a secure way to tell the IPA server "I am still > who I claimed I was before" and fetch all of your secure data during the > start up process. > > Assuming your data center is locked down and a rouge machine cannot PXE > boot on your local interface, what you would need is probably a way to > push down a one time password to the booting machine so that it could > then use that to refetch its keytab from the IPA server. Not something > currently supported (only happens during register). > > You can unregister and then register the machines when you reboot them. > I am pretty sure that you don't really want to do that, though. Thanks for the reply. I actually had a spark pop into my head last night as I was trying to doze off to sleep. Tried it today and it works rather well. I realize there are probably a few security risks here, but it is the best I have come up with so far and I have done my best to mitigate the obvious ones. I have declared in my dhcpd that only certain MAC addresses can PXEboot. This is working well and non-defined MAC's are not able to PXEboot. In my kickstart file, that is pushed out over the PXEboot, I have an SSH key inside. That key only authenticates against an account that is configured with scponly[1] and the account is locked down for read only. During the kickstart post script section, I have the box pull down the settings it needs from a `hostname`.tgz file over scp. [1] https://github.com/scponly/scponly/wiki I haven't figured out all the settings that IPA needs, but pulling the host identifiers, the ntp config, ect works really well for the time being. Is there a handy list of conf files that I need to bundle up? I looked for such a list and saw mention of various files in various places but not a complete list. Have I just missed that in my search-fu? Thanks again! ~Stack~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From sigbjorn at nixtra.com Fri Jan 27 14:11:23 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 27 Jan 2012 15:11:23 +0100 (CET) Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available Message-ID: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> Hi The first naming context returned from the LDAP server is always chosen when using migrate-ds. This makes my import fail when I attempt to import users and groups from a previous LDAP server having more than 1 naming contexts available. The migrate-ds script should accept an option to specify what base_dn I would like to import from. Is there such an option today? I cannot find it... Regards, Siggi From sgallagh at redhat.com Fri Jan 27 14:17:12 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 27 Jan 2012 09:17:12 -0500 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> Message-ID: <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: > Hi > > The first naming context returned from the LDAP server is always chosen > when using migrate-ds. This makes my import fail when I attempt to > import users and groups from a previous LDAP server having more than 1 > naming contexts available. > > The migrate-ds script should accept an option to specify what base_dn I > would like to import from. > > Is there such an option today? I cannot find it... Just to add to this request, if the original LDAP server has a defaultNamingContext attribute, it should be honored for auto-detecting which base to migrate. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sigbjorn at nixtra.com Fri Jan 27 14:30:53 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 27 Jan 2012 15:30:53 +0100 (CET) Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <35806.81.166.38.135.1327674653.squirrel@www.nixtra.com> On Fri, January 27, 2012 15:17, Stephen Gallagher wrote: > On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: > >> Hi >> >> >> The first naming context returned from the LDAP server is always chosen >> when using migrate-ds. This makes my import fail when I attempt to import users and groups from a >> previous LDAP server having more than 1 naming contexts available. >> >> The migrate-ds script should accept an option to specify what base_dn I >> would like to import from. >> >> Is there such an option today? I cannot find it... >> > > Just to add to this request, if the original LDAP server has a > defaultNamingContext attribute, it should be honored for auto-detecting which base to migrate. > _______________________________________________ The defaultNamingContext is not available, and I'm unable to add it. "Object class violation". This is a Sun DS 7.0. Is there a way to manually specify what base_dn to import from? Rgds, Siggi From rcritten at redhat.com Fri Jan 27 14:37:40 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Jan 2012 09:37:40 -0500 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4F22B6B4.5040502@redhat.com> Stephen Gallagher wrote: > On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: >> Hi >> >> The first naming context returned from the LDAP server is always chosen >> when using migrate-ds. This makes my import fail when I attempt to >> import users and groups from a previous LDAP server having more than 1 >> naming contexts available. >> >> The migrate-ds script should accept an option to specify what base_dn I >> would like to import from. >> >> Is there such an option today? I cannot find it... Not currently. I noticed this earlier in the week and opened a ticket on it, https://fedorahosted.org/freeipa/ticket/2314 > > Just to add to this request, if the original LDAP server has a > defaultNamingContext attribute, it should be honored for auto-detecting > which base to migrate. I'll update the 2314 to ensure we don't forget about this. 389-ds just added support for defaultNamingContext. rob From sigbjorn at nixtra.com Fri Jan 27 14:50:24 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 27 Jan 2012 15:50:24 +0100 (CET) Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <4F22B6B4.5040502@redhat.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> Message-ID: <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> On Fri, January 27, 2012 15:37, Rob Crittenden wrote: > Stephen Gallagher wrote: > >> On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: >> >>> Hi >>> >>> >>> The first naming context returned from the LDAP server is always chosen >>> when using migrate-ds. This makes my import fail when I attempt to import users and groups from >>> a previous LDAP server having more than 1 naming contexts available. >>> >>> The migrate-ds script should accept an option to specify what base_dn I >>> would like to import from. >>> >>> Is there such an option today? I cannot find it... >>> > > Not currently. I noticed this earlier in the week and opened a ticket on > it, https://fedorahosted.org/freeipa/ticket/2314 > >> >> Just to add to this request, if the original LDAP server has a >> defaultNamingContext attribute, it should be honored for auto-detecting which base to migrate. > > I'll update the 2314 to ensure we don't forget about this. 389-ds just > added support for defaultNamingContext. > Ok, thank you. Anything I can do to work around this issue today? I suppose there is just a file that need to be hacked to set a set a value instead of the auto-detected value... ? From rcritten at redhat.com Fri Jan 27 14:55:59 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Jan 2012 09:55:59 -0500 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> Message-ID: <4F22BAFF.5000100@redhat.com> Sigbjorn Lie wrote: > > On Fri, January 27, 2012 15:37, Rob Crittenden wrote: >> Stephen Gallagher wrote: >> >>> On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: >>> >>>> Hi >>>> >>>> >>>> The first naming context returned from the LDAP server is always chosen >>>> when using migrate-ds. This makes my import fail when I attempt to import users and groups from >>>> a previous LDAP server having more than 1 naming contexts available. >>>> >>>> The migrate-ds script should accept an option to specify what base_dn I >>>> would like to import from. >>>> >>>> Is there such an option today? I cannot find it... >>>> >> >> Not currently. I noticed this earlier in the week and opened a ticket on >> it, https://fedorahosted.org/freeipa/ticket/2314 >> >>> >>> Just to add to this request, if the original LDAP server has a >>> defaultNamingContext attribute, it should be honored for auto-detecting which base to migrate. >> >> I'll update the 2314 to ensure we don't forget about this. 389-ds just >> added support for defaultNamingContext. >> > > Ok, thank you. > > Anything I can do to work around this issue today? I suppose there is just a file that need to be > hacked to set a set a value instead of the auto-detected value... ? > /usr/lib/python*/site-packages/ipalib/plugins/migration.py ~line 620 you'll see a block starting with the comment "retrieve DS base DN". Comment out the next 8 lines by prefixing them with # (these query to get the namingContext then pull the first value out). Add: ds_base_dn = 'dc=yourbasedn,dc=com' Alternatively you could always just add the above line to override what is detected. Commenting out just saves an LDAP lookup. Restart Apache. rob From danieljamesscott at gmail.com Fri Jan 27 15:36:42 2012 From: danieljamesscott at gmail.com (Dan Scott) Date: Fri, 27 Jan 2012 10:36:42 -0500 Subject: [Freeipa-users] Fedora 16 client not getting group names Message-ID: Hi, I have a Fedora 16 client running sssd-client-1.6.4-1.fc16.x86_64. When I run, e.g. id djscott, I do not get the names of the groups: -bash-4.2$ id djscott uid=768(djscott) gid=1002(legacy-group) groups=1002(legacy-group),1134,1130,1118,1103,1108,1113,789600001(ipausers),1102,1109,1129,1111 Is this because they have low GIDs? (These were migrated over from my old FreeIPA 1 installation and I'd rather not re-number them all). Can someone help me to figure out how to retrieve the group names? This is working fine on the Fedora 15 clients (sssd-1.5.x). Thanks, Dan Scott From sgallagh at redhat.com Fri Jan 27 15:48:17 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 27 Jan 2012 10:48:17 -0500 Subject: [Freeipa-users] Fedora 16 client not getting group names In-Reply-To: References: Message-ID: <1327679297.2131.49.camel@sgallagh520.sgallagh.bos.redhat.com> On Fri, 2012-01-27 at 10:36 -0500, Dan Scott wrote: > Hi, > > I have a Fedora 16 client running sssd-client-1.6.4-1.fc16.x86_64. > > When I run, e.g. id djscott, I do not get the names of the groups: > > -bash-4.2$ id djscott > uid=768(djscott) gid=1002(legacy-group) > groups=1002(legacy-group),1134,1130,1118,1103,1108,1113,789600001(ipausers),1102,1109,1129,1111 > > Is this because they have low GIDs? (These were migrated over from my > old FreeIPA 1 installation and I'd rather not re-number them all). > > Can someone help me to figure out how to retrieve the group names? > This is working fine on the Fedora 15 clients (sssd-1.5.x). This looks to me like you didn't migrate all of the groups. GIF 1002 and 789600001 are both reporting the names correctly, so clearly the client is able to access the FreeIPA server and retrieve groups. Please try the following and report the results: getent group 1134 and also getent group where is the name that is SUPPOSED to match GID 1134. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From danieljamesscott at gmail.com Fri Jan 27 16:47:01 2012 From: danieljamesscott at gmail.com (Dan Scott) Date: Fri, 27 Jan 2012 11:47:01 -0500 Subject: [Freeipa-users] Fedora 16 client not getting group names In-Reply-To: <1327679297.2131.49.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1327679297.2131.49.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: Hi, On Fri, Jan 27, 2012 at 10:48, Stephen Gallagher wrote: > On Fri, 2012-01-27 at 10:36 -0500, Dan Scott wrote: >> Hi, >> >> I have a Fedora 16 client running sssd-client-1.6.4-1.fc16.x86_64. >> >> When I run, e.g. id djscott, I do not get the names of the groups: >> >> -bash-4.2$ id djscott >> uid=768(djscott) gid=1002(legacy-group) >> groups=1002(legacy-group),1134,1130,1118,1103,1108,1113,789600001(ipausers),1102,1109,1129,1111 >> >> Is this because they have low GIDs? (These were migrated over from my >> old FreeIPA 1 installation and I'd rather not re-number them all). >> >> Can someone help me to figure out how to retrieve the group names? >> This is working fine on the Fedora 15 clients (sssd-1.5.x). > > > This looks to me like you didn't migrate all of the groups. GIF 1002 and > 789600001 are both reporting the names correctly, so clearly the client > is able to access the FreeIPA server and retrieve groups. It's working fine with Fedora 15 clients, so I think that the groups were migrated OK. > Please try the following and report the results: > > getent group 1134 > > and also > getent group > > where is the name that is SUPPOSED to match GID 1134. I've just realised that once I've manually looked up the group using the name, the id command is 'fixed': [root at newton ~]# getent group 1134 [root at newton ~]# getent group svn-wfdb-swig-matlab svn-wfdb-swig-matlab:*:1134:ikaro,djscott [root at newton ~]# getent group 1134 svn-wfdb-swig-matlab:*:1134:ikaro,djscott [root at newton ~]# id djscott uid=768(djscott) gid=1002(legacy-group) groups=1002(legacy-group),1134(svn-wfdb-swig-matlab),1130,1118,1103,1108,1113,789600001(ipausers),1102,1109,1129,1111 The initial getent returned no data. But the group info seems OK once I've done one lookup. Maybe the sssd cache is corrupt/out-of-date? How can I refresh it? Thanks, Dan From jhrozek at redhat.com Fri Jan 27 16:57:17 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 27 Jan 2012 17:57:17 +0100 Subject: [Freeipa-users] Fedora 16 client not getting group names In-Reply-To: References: <1327679297.2131.49.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <20120127165717.GD12744@hendrix.redhat.com> On Fri, Jan 27, 2012 at 11:47:01AM -0500, Dan Scott wrote: > Hi, > > On Fri, Jan 27, 2012 at 10:48, Stephen Gallagher wrote: > > On Fri, 2012-01-27 at 10:36 -0500, Dan Scott wrote: > >> Hi, > >> > >> I have a Fedora 16 client running sssd-client-1.6.4-1.fc16.x86_64. > >> > >> When I run, e.g. id djscott, I do not get the names of the groups: > >> > >> -bash-4.2$ id djscott > >> uid=768(djscott) gid=1002(legacy-group) > >> groups=1002(legacy-group),1134,1130,1118,1103,1108,1113,789600001(ipausers),1102,1109,1129,1111 > >> > >> Is this because they have low GIDs? (These were migrated over from my > >> old FreeIPA 1 installation and I'd rather not re-number them all). > >> > >> Can someone help me to figure out how to retrieve the group names? > >> This is working fine on the Fedora 15 clients (sssd-1.5.x). > > > > > > This looks to me like you didn't migrate all of the groups. GIF 1002 and > > 789600001 are both reporting the names correctly, so clearly the client > > is able to access the FreeIPA server and retrieve groups. > > It's working fine with Fedora 15 clients, so I think that the groups > were migrated OK. > > > Please try the following and report the results: > > > > getent group 1134 > > > > and also > > getent group > > > > where is the name that is SUPPOSED to match GID 1134. > > I've just realised that once I've manually looked up the group using > the name, the id command is 'fixed': > > [root at newton ~]# getent group 1134 > [root at newton ~]# getent group svn-wfdb-swig-matlab > svn-wfdb-swig-matlab:*:1134:ikaro,djscott > [root at newton ~]# getent group 1134 > svn-wfdb-swig-matlab:*:1134:ikaro,djscott > [root at newton ~]# id djscott > uid=768(djscott) gid=1002(legacy-group) > groups=1002(legacy-group),1134(svn-wfdb-swig-matlab),1130,1118,1103,1108,1113,789600001(ipausers),1102,1109,1129,1111 > > The initial getent returned no data. But the group info seems OK once > I've done one lookup. > That's weird, id runs getgrgid() on each of the returned group GIDs > Maybe the sssd cache is corrupt/out-of-date? How can I refresh it? WARNING: removing the cache would remove the cached passwords service sssd stop rm -f /var/lib/sss/db/cache*.ldb service sssd start If the group names still wouldn't show up, can you post logs when performing the id command? SSSD 1.7 contains a much more user-friendly way to just mark the entries in cache as expired using the sss_cache command. > > Thanks, > > Dan > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sigbjorn at nixtra.com Fri Jan 27 17:15:42 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 27 Jan 2012 18:15:42 +0100 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <4F22BAFF.5000100@redhat.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> Message-ID: <4F22DBBE.10502@nixtra.com> On 01/27/2012 03:55 PM, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> >> On Fri, January 27, 2012 15:37, Rob Crittenden wrote: >>> Stephen Gallagher wrote: >>> >>>> On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: >>>> >>>>> Hi >>>>> >>>>> >>>>> The first naming context returned from the LDAP server is always >>>>> chosen >>>>> when using migrate-ds. This makes my import fail when I attempt to >>>>> import users and groups from >>>>> a previous LDAP server having more than 1 naming contexts available. >>>>> >>>>> The migrate-ds script should accept an option to specify what >>>>> base_dn I >>>>> would like to import from. >>>>> >>>>> Is there such an option today? I cannot find it... >>>>> >>> >>> Not currently. I noticed this earlier in the week and opened a >>> ticket on >>> it, https://fedorahosted.org/freeipa/ticket/2314 >>> >>>> >>>> Just to add to this request, if the original LDAP server has a >>>> defaultNamingContext attribute, it should be honored for >>>> auto-detecting which base to migrate. >>> >>> I'll update the 2314 to ensure we don't forget about this. 389-ds just >>> added support for defaultNamingContext. >>> >> >> Ok, thank you. >> >> Anything I can do to work around this issue today? I suppose there is >> just a file that need to be >> hacked to set a set a value instead of the auto-detected value... ? >> > > /usr/lib/python*/site-packages/ipalib/plugins/migration.py > > ~line 620 you'll see a block starting with the comment "retrieve DS > base DN". > > Comment out the next 8 lines by prefixing them with # (these query to > get the namingContext then pull the first value out). > > Add: > > ds_base_dn = 'dc=yourbasedn,dc=com' > > Alternatively you could always just add the above line to override > what is detected. Commenting out just saves an LDAP lookup. > > Restart Apache. I already found that file and did that earlier today, however I was restarting tomcat6, not httpd... my bad. :) I have to specify --group-objectclass=posixGroup to get groups imported, that's fine. But I only get a few users imported. I see that by default it seem to be looking for objectclass=person. Only a few user accounts have that objectclass associated, so I add --user-objectclass=posixAccount as all users have this objectclass associated with their account. $ ipa migrate-ds --user-container='ou=people' --group-container='ou=group' --bind-dn='cn=directory manager' --user-objectclass=account --group-objectclass=posixGroup --schema=RFC2307 --continue ldap://ldapserver:399 ipa: ERROR: an internal error has occurred Not good. I look in the /var/log/httpd/error_log file, and I find: [Fri Jan 27 18:12:51 2012] [error] ipa: INFO: admin at NONE: ping(): SUCCESS [Fri Jan 27 18:12:52 2012] [error] ipa: ERROR: non-public: UnicodeDecodeError: 'utf8' codec can't decode byte 0xe5 in position 1: invalid continuation byte [Fri Jan 27 18:12:52 2012] [error] Traceback (most recent call last): [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 228, in wsgi_execute [Fri Jan 27 18:12:52 2012] [error] result = self.Command[name](*args, **options) [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 432, in __call__ [Fri Jan 27 18:12:52 2012] [error] ret = self.run(*args, **options) [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 738, in run [Fri Jan 27 18:12:52 2012] [error] return self.execute(*args, **options) [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", line 634, in execute [Fri Jan 27 18:12:52 2012] [error] ldap, config, ds_ldap, ds_base_dn, options [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", line 513, in migrate [Fri Jan 27 18:12:52 2012] [error] search_refs=True # migrated DS may contain search references [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 188, in new_f [Fri Jan 27 18:12:52 2012] [error] return f(*new_args, **kwargs) [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 199, in new_f [Fri Jan 27 18:12:52 2012] [error] return args[0].decode(f(*args, **kwargs)) [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in decode [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m in var) [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m in var) [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 137, in decode [Fri Jan 27 18:12:52 2012] [error] return [self.decode(m) for m in var] [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in decode [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m in var) [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m in var) [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 157, in decode [Fri Jan 27 18:12:52 2012] [error] dct[k] = self._decode_dict_val(k, v) [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 64, in _decode_dict_val [Fri Jan 27 18:12:52 2012] [error] return self.decode(val) [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 137, in decode [Fri Jan 27 18:12:52 2012] [error] return [self.decode(m) for m in var] [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 132, in decode [Fri Jan 27 18:12:52 2012] [error] var.decode(self.encoder_settings.decode_from) [Fri Jan 27 18:12:52 2012] [error] File "/usr/lib64/python2.6/encodings/utf_8.py", line 16, in decode [Fri Jan 27 18:12:52 2012] [error] return codecs.utf_8_decode(input, errors, True) [Fri Jan 27 18:12:52 2012] [error] UnicodeDecodeError: 'utf8' codec can't decode byte 0xe5 in position 1: invalid continuation byte [Fri Jan 27 18:12:52 2012] [error] ipa: INFO: admin at NONE: migrate_ds(u'ldap://svg-p-idm02.none:389', u'********', binddn=u'cn=directory manager', usercontainer=u'ou=people', groupcontainer=u'ou=group', userobjectclass=(u'account',), groupobjectclass=(u'posixGroup',), userignoreobjectclass=None, userignoreattribute=None, groupignoreobjectclass=None, groupignoreattribute=None, groupoverwritegid=False, schema=u'RFC2307', continue=False, exclude_groups=None, exclude_users=None): UnicodeDecodeError Any suggestions? From sigbjorn at nixtra.com Fri Jan 27 17:44:58 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 27 Jan 2012 18:44:58 +0100 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <4F22DBBE.10502@nixtra.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> <4F22DBBE.10502@nixtra.com> Message-ID: <4F22E29A.9050709@nixtra.com> On 01/27/2012 06:15 PM, Sigbjorn Lie wrote: > On 01/27/2012 03:55 PM, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >>> >>> On Fri, January 27, 2012 15:37, Rob Crittenden wrote: >>>> Stephen Gallagher wrote: >>>> >>>>> On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> >>>>>> The first naming context returned from the LDAP server is always >>>>>> chosen >>>>>> when using migrate-ds. This makes my import fail when I attempt >>>>>> to import users and groups from >>>>>> a previous LDAP server having more than 1 naming contexts available. >>>>>> >>>>>> The migrate-ds script should accept an option to specify what >>>>>> base_dn I >>>>>> would like to import from. >>>>>> >>>>>> Is there such an option today? I cannot find it... >>>>>> >>>> >>>> Not currently. I noticed this earlier in the week and opened a >>>> ticket on >>>> it, https://fedorahosted.org/freeipa/ticket/2314 >>>> >>>>> >>>>> Just to add to this request, if the original LDAP server has a >>>>> defaultNamingContext attribute, it should be honored for >>>>> auto-detecting which base to migrate. >>>> >>>> I'll update the 2314 to ensure we don't forget about this. 389-ds just >>>> added support for defaultNamingContext. >>>> >>> >>> Ok, thank you. >>> >>> Anything I can do to work around this issue today? I suppose there >>> is just a file that need to be >>> hacked to set a set a value instead of the auto-detected value... ? >>> >> >> /usr/lib/python*/site-packages/ipalib/plugins/migration.py >> >> ~line 620 you'll see a block starting with the comment "retrieve DS >> base DN". >> >> Comment out the next 8 lines by prefixing them with # (these query to >> get the namingContext then pull the first value out). >> >> Add: >> >> ds_base_dn = 'dc=yourbasedn,dc=com' >> >> Alternatively you could always just add the above line to override >> what is detected. Commenting out just saves an LDAP lookup. >> >> Restart Apache. > > > I already found that file and did that earlier today, however I was > restarting tomcat6, not httpd... my bad. :) > > I have to specify --group-objectclass=posixGroup to get groups > imported, that's fine. But I only get a few users imported. I see that > by default it seem to be looking for objectclass=person. Only a few > user accounts have that objectclass associated, so I add > --user-objectclass=posixAccount as all users have this objectclass > associated with their account. > > $ ipa migrate-ds --user-container='ou=people' > --group-container='ou=group' --bind-dn='cn=directory manager' > --user-objectclass=account --group-objectclass=posixGroup > --schema=RFC2307 --continue ldap://ldapserver:399 > ipa: ERROR: an internal error has occurred > > Not good. I look in the /var/log/httpd/error_log file, and I find: > > [Fri Jan 27 18:12:51 2012] [error] ipa: INFO: admin at NONE: ping(): SUCCESS > [Fri Jan 27 18:12:52 2012] [error] ipa: ERROR: non-public: > UnicodeDecodeError: 'utf8' codec can't decode byte 0xe5 in position 1: > invalid continuation byte > [Fri Jan 27 18:12:52 2012] [error] Traceback (most recent call last): > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 228, > in wsgi_execute > [Fri Jan 27 18:12:52 2012] [error] result = > self.Command[name](*args, **options) > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 432, in > __call__ > [Fri Jan 27 18:12:52 2012] [error] ret = self.run(*args, **options) > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 738, in run > [Fri Jan 27 18:12:52 2012] [error] return self.execute(*args, > **options) > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", line > 634, in execute > [Fri Jan 27 18:12:52 2012] [error] ldap, config, ds_ldap, > ds_base_dn, options > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", line > 513, in migrate > [Fri Jan 27 18:12:52 2012] [error] search_refs=True # migrated > DS may contain search references > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 188, in new_f > [Fri Jan 27 18:12:52 2012] [error] return f(*new_args, **kwargs) > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 199, in new_f > [Fri Jan 27 18:12:52 2012] [error] return args[0].decode(f(*args, > **kwargs)) > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in decode > [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for > m in var) > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in > > [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for > m in var) > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 137, in decode > [Fri Jan 27 18:12:52 2012] [error] return [self.decode(m) for m in > var] > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in decode > [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for > m in var) > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in > > [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for > m in var) > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 157, in decode > [Fri Jan 27 18:12:52 2012] [error] dct[k] = > self._decode_dict_val(k, v) > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 64, in > _decode_dict_val > [Fri Jan 27 18:12:52 2012] [error] return self.decode(val) > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 137, in decode > [Fri Jan 27 18:12:52 2012] [error] return [self.decode(m) for m in > var] > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 132, in decode > [Fri Jan 27 18:12:52 2012] [error] > var.decode(self.encoder_settings.decode_from) > [Fri Jan 27 18:12:52 2012] [error] File > "/usr/lib64/python2.6/encodings/utf_8.py", line 16, in decode > [Fri Jan 27 18:12:52 2012] [error] return > codecs.utf_8_decode(input, errors, True) > [Fri Jan 27 18:12:52 2012] [error] UnicodeDecodeError: 'utf8' codec > can't decode byte 0xe5 in position 1: invalid continuation byte > [Fri Jan 27 18:12:52 2012] [error] ipa: INFO: admin at NONE: > migrate_ds(u'ldap://svg-p-idm02.none:389', u'********', > binddn=u'cn=directory manager', usercontainer=u'ou=people', > groupcontainer=u'ou=group', userobjectclass=(u'account',), > groupobjectclass=(u'posixGroup',), userignoreobjectclass=None, > userignoreattribute=None, groupignoreobjectclass=None, > groupignoreattribute=None, groupoverwritegid=False, schema=u'RFC2307', > continue=False, exclude_groups=None, exclude_users=None): > UnicodeDecodeError > > > Any suggestions? > > Oh yes and of course I've already looked for accounts with any non-utf8 chars in any of the output of an ldapsearch of the same ldap tree I'm trying to import from... From sgallagh at redhat.com Fri Jan 27 18:17:51 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 27 Jan 2012 13:17:51 -0500 Subject: [Freeipa-users] Fedora 16 client not getting group names In-Reply-To: <20120127165717.GD12744@hendrix.redhat.com> References: <1327679297.2131.49.camel@sgallagh520.sgallagh.bos.redhat.com> <20120127165717.GD12744@hendrix.redhat.com> Message-ID: <1327688271.2131.53.camel@sgallagh520.sgallagh.bos.redhat.com> On Fri, 2012-01-27 at 17:57 +0100, Jakub Hrozek wrote: > On Fri, Jan 27, 2012 at 11:47:01AM -0500, Dan Scott wrote: > > Hi, > > > > On Fri, Jan 27, 2012 at 10:48, Stephen Gallagher wrote: > > > On Fri, 2012-01-27 at 10:36 -0500, Dan Scott wrote: > > >> Hi, > > >> > > >> I have a Fedora 16 client running sssd-client-1.6.4-1.fc16.x86_64. > > >> > > >> When I run, e.g. id djscott, I do not get the names of the groups: > > >> > > >> -bash-4.2$ id djscott > > >> uid=768(djscott) gid=1002(legacy-group) > > >> groups=1002(legacy-group),1134,1130,1118,1103,1108,1113,789600001(ipausers),1102,1109,1129,1111 > > >> > > >> Is this because they have low GIDs? (These were migrated over from my > > >> old FreeIPA 1 installation and I'd rather not re-number them all). > > >> > > >> Can someone help me to figure out how to retrieve the group names? > > >> This is working fine on the Fedora 15 clients (sssd-1.5.x). > > > > > > > > > This looks to me like you didn't migrate all of the groups. GIF 1002 and > > > 789600001 are both reporting the names correctly, so clearly the client > > > is able to access the FreeIPA server and retrieve groups. > > > > It's working fine with Fedora 15 clients, so I think that the groups > > were migrated OK. > > > > > Please try the following and report the results: > > > > > > getent group 1134 > > > > > > and also > > > getent group > > > > > > where is the name that is SUPPOSED to match GID 1134. > > > > I've just realised that once I've manually looked up the group using > > the name, the id command is 'fixed': > > > > [root at newton ~]# getent group 1134 > > [root at newton ~]# getent group svn-wfdb-swig-matlab > > svn-wfdb-swig-matlab:*:1134:ikaro,djscott > > [root at newton ~]# getent group 1134 > > svn-wfdb-swig-matlab:*:1134:ikaro,djscott > > [root at newton ~]# id djscott > > uid=768(djscott) gid=1002(legacy-group) > > groups=1002(legacy-group),1134(svn-wfdb-swig-matlab),1130,1118,1103,1108,1113,789600001(ipausers),1102,1109,1129,1111 > > > > The initial getent returned no data. But the group info seems OK once > > I've done one lookup. > > > > That's weird, id runs getgrgid() on each of the returned group GIDs > I know what's going on here. It was a stupid glibc screw-up in Fedora 16. Remove the line starting with "initgroups: " from your /etc/nsswitch.conf file. See https://bugzilla.redhat.com/show_bug.cgi?id=751450 for more details. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From rcritten at redhat.com Fri Jan 27 18:42:21 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Jan 2012 13:42:21 -0500 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <4F22E29A.9050709@nixtra.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> <4F22DBBE.10502@nixtra.com> <4F22E29A.9050709@nixtra.com> Message-ID: <4F22F00D.3000006@redhat.com> Sigbjorn Lie wrote: > On 01/27/2012 06:15 PM, Sigbjorn Lie wrote: >> On 01/27/2012 03:55 PM, Rob Crittenden wrote: >>> Sigbjorn Lie wrote: >>>> >>>> On Fri, January 27, 2012 15:37, Rob Crittenden wrote: >>>>> Stephen Gallagher wrote: >>>>> >>>>>> On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> >>>>>>> The first naming context returned from the LDAP server is always >>>>>>> chosen >>>>>>> when using migrate-ds. This makes my import fail when I attempt >>>>>>> to import users and groups from >>>>>>> a previous LDAP server having more than 1 naming contexts available. >>>>>>> >>>>>>> The migrate-ds script should accept an option to specify what >>>>>>> base_dn I >>>>>>> would like to import from. >>>>>>> >>>>>>> Is there such an option today? I cannot find it... >>>>>>> >>>>> >>>>> Not currently. I noticed this earlier in the week and opened a >>>>> ticket on >>>>> it, https://fedorahosted.org/freeipa/ticket/2314 >>>>> >>>>>> >>>>>> Just to add to this request, if the original LDAP server has a >>>>>> defaultNamingContext attribute, it should be honored for >>>>>> auto-detecting which base to migrate. >>>>> >>>>> I'll update the 2314 to ensure we don't forget about this. 389-ds just >>>>> added support for defaultNamingContext. >>>>> >>>> >>>> Ok, thank you. >>>> >>>> Anything I can do to work around this issue today? I suppose there >>>> is just a file that need to be >>>> hacked to set a set a value instead of the auto-detected value... ? >>>> >>> >>> /usr/lib/python*/site-packages/ipalib/plugins/migration.py >>> >>> ~line 620 you'll see a block starting with the comment "retrieve DS >>> base DN". >>> >>> Comment out the next 8 lines by prefixing them with # (these query to >>> get the namingContext then pull the first value out). >>> >>> Add: >>> >>> ds_base_dn = 'dc=yourbasedn,dc=com' >>> >>> Alternatively you could always just add the above line to override >>> what is detected. Commenting out just saves an LDAP lookup. >>> >>> Restart Apache. >> >> >> I already found that file and did that earlier today, however I was >> restarting tomcat6, not httpd... my bad. :) >> >> I have to specify --group-objectclass=posixGroup to get groups >> imported, that's fine. But I only get a few users imported. I see that >> by default it seem to be looking for objectclass=person. Only a few >> user accounts have that objectclass associated, so I add >> --user-objectclass=posixAccount as all users have this objectclass >> associated with their account. >> >> $ ipa migrate-ds --user-container='ou=people' >> --group-container='ou=group' --bind-dn='cn=directory manager' >> --user-objectclass=account --group-objectclass=posixGroup >> --schema=RFC2307 --continue ldap://ldapserver:399 >> ipa: ERROR: an internal error has occurred >> >> Not good. I look in the /var/log/httpd/error_log file, and I find: >> >> [Fri Jan 27 18:12:51 2012] [error] ipa: INFO: admin at NONE: ping(): SUCCESS >> [Fri Jan 27 18:12:52 2012] [error] ipa: ERROR: non-public: >> UnicodeDecodeError: 'utf8' codec can't decode byte 0xe5 in position 1: >> invalid continuation byte >> [Fri Jan 27 18:12:52 2012] [error] Traceback (most recent call last): >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 228, >> in wsgi_execute >> [Fri Jan 27 18:12:52 2012] [error] result = self.Command[name](*args, >> **options) >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 432, in >> __call__ >> [Fri Jan 27 18:12:52 2012] [error] ret = self.run(*args, **options) >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 738, in run >> [Fri Jan 27 18:12:52 2012] [error] return self.execute(*args, **options) >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", line >> 634, in execute >> [Fri Jan 27 18:12:52 2012] [error] ldap, config, ds_ldap, ds_base_dn, >> options >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", line >> 513, in migrate >> [Fri Jan 27 18:12:52 2012] [error] search_refs=True # migrated DS may >> contain search references >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 188, in new_f >> [Fri Jan 27 18:12:52 2012] [error] return f(*new_args, **kwargs) >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 199, in new_f >> [Fri Jan 27 18:12:52 2012] [error] return args[0].decode(f(*args, >> **kwargs)) >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in decode >> [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m >> in var) >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in >> >> [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m >> in var) >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 137, in decode >> [Fri Jan 27 18:12:52 2012] [error] return [self.decode(m) for m in var] >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in decode >> [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m >> in var) >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in >> >> [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m >> in var) >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 157, in decode >> [Fri Jan 27 18:12:52 2012] [error] dct[k] = self._decode_dict_val(k, v) >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 64, in >> _decode_dict_val >> [Fri Jan 27 18:12:52 2012] [error] return self.decode(val) >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 137, in decode >> [Fri Jan 27 18:12:52 2012] [error] return [self.decode(m) for m in var] >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 132, in decode >> [Fri Jan 27 18:12:52 2012] [error] >> var.decode(self.encoder_settings.decode_from) >> [Fri Jan 27 18:12:52 2012] [error] File >> "/usr/lib64/python2.6/encodings/utf_8.py", line 16, in decode >> [Fri Jan 27 18:12:52 2012] [error] return codecs.utf_8_decode(input, >> errors, True) >> [Fri Jan 27 18:12:52 2012] [error] UnicodeDecodeError: 'utf8' codec >> can't decode byte 0xe5 in position 1: invalid continuation byte >> [Fri Jan 27 18:12:52 2012] [error] ipa: INFO: admin at NONE: >> migrate_ds(u'ldap://svg-p-idm02.none:389', u'********', >> binddn=u'cn=directory manager', usercontainer=u'ou=people', >> groupcontainer=u'ou=group', userobjectclass=(u'account',), >> groupobjectclass=(u'posixGroup',), userignoreobjectclass=None, >> userignoreattribute=None, groupignoreobjectclass=None, >> groupignoreattribute=None, groupoverwritegid=False, schema=u'RFC2307', >> continue=False, exclude_groups=None, exclude_users=None): >> UnicodeDecodeError >> >> >> Any suggestions? >> >> > Oh yes and of course I've already looked for accounts with any non-utf8 > chars in any of the output of an ldapsearch of the same ldap tree I'm > trying to import from... This came up yesterday internally too. I don't believe a bug or ticket has been filed yet. My best guess on what is happening, based on what I saw with our own case, is this: A migrated attribute is coming in that IPA doesn't know about. We default to treating all attributes that don't require special treatment (like binary values) as utf-8. I'm guessing that an unknown binary attribute is being migrated, we try to utf-8 encode it and kablooey. There is no easy workaround for the above problem right now because that happens before the --ignore* options are considered. One idea that has come to mind but is untested is to grab the missing schema in the form of a discrete 389-ds-compatible schema file. Stop dirsrv, drop the file into /etc/dirsrv/slapd-YOURINSTANCE/schema, start dirsrv Then retry the migration. Use --ignore* if you don't want/need these attributes, then you stop dirsrv, remove the schema file, start dirsrv. regards rob From sgallagh at redhat.com Fri Jan 27 18:52:57 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 27 Jan 2012 13:52:57 -0500 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <4F22F00D.3000006@redhat.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> <4F22DBBE.10502@nixtra.com> <4F22E29A.9050709@nixtra.com> <4F22F00D.3000006@redhat.com> Message-ID: <1327690377.2131.57.camel@sgallagh520.sgallagh.bos.redhat.com> On Fri, 2012-01-27 at 13:42 -0500, Rob Crittenden wrote: > > This came up yesterday internally too. I don't believe a bug or ticket > has been filed yet. > > My best guess on what is happening, based on what I saw with our own > case, is this: > > A migrated attribute is coming in that IPA doesn't know about. We > default to treating all attributes that don't require special treatment > (like binary values) as utf-8. I'm guessing that an unknown binary > attribute is being migrated, we try to utf-8 encode it and kablooey. > > There is no easy workaround for the above problem right now because that > happens before the --ignore* options are considered. > Why don't we just base64-encode unknown attributes instead of treating them like UTF-8? The LDAP server is *supposed* to be able to handle this implicitly. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sigbjorn at nixtra.com Fri Jan 27 19:01:37 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 27 Jan 2012 20:01:37 +0100 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <4F22F00D.3000006@redhat.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> <4F22DBBE.10502@nixtra.com> <4F22E29A.9050709@nixtra.com> <4F22F00D.3000006@redhat.com> Message-ID: <4F22F491.3040305@nixtra.com> On 01/27/2012 07:42 PM, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> On 01/27/2012 06:15 PM, Sigbjorn Lie wrote: >>> On 01/27/2012 03:55 PM, Rob Crittenden wrote: >>>> Sigbjorn Lie wrote: >>>>> >>>>> On Fri, January 27, 2012 15:37, Rob Crittenden wrote: >>>>>> Stephen Gallagher wrote: >>>>>> >>>>>>> On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: >>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> >>>>>>>> The first naming context returned from the LDAP server is always >>>>>>>> chosen >>>>>>>> when using migrate-ds. This makes my import fail when I attempt >>>>>>>> to import users and groups from >>>>>>>> a previous LDAP server having more than 1 naming contexts >>>>>>>> available. >>>>>>>> >>>>>>>> The migrate-ds script should accept an option to specify what >>>>>>>> base_dn I >>>>>>>> would like to import from. >>>>>>>> >>>>>>>> Is there such an option today? I cannot find it... >>>>>>>> >>>>>> >>>>>> Not currently. I noticed this earlier in the week and opened a >>>>>> ticket on >>>>>> it, https://fedorahosted.org/freeipa/ticket/2314 >>>>>> >>>>>>> >>>>>>> Just to add to this request, if the original LDAP server has a >>>>>>> defaultNamingContext attribute, it should be honored for >>>>>>> auto-detecting which base to migrate. >>>>>> >>>>>> I'll update the 2314 to ensure we don't forget about this. 389-ds >>>>>> just >>>>>> added support for defaultNamingContext. >>>>>> >>>>> >>>>> Ok, thank you. >>>>> >>>>> Anything I can do to work around this issue today? I suppose there >>>>> is just a file that need to be >>>>> hacked to set a set a value instead of the auto-detected value... ? >>>>> >>>> >>>> /usr/lib/python*/site-packages/ipalib/plugins/migration.py >>>> >>>> ~line 620 you'll see a block starting with the comment "retrieve DS >>>> base DN". >>>> >>>> Comment out the next 8 lines by prefixing them with # (these query to >>>> get the namingContext then pull the first value out). >>>> >>>> Add: >>>> >>>> ds_base_dn = 'dc=yourbasedn,dc=com' >>>> >>>> Alternatively you could always just add the above line to override >>>> what is detected. Commenting out just saves an LDAP lookup. >>>> >>>> Restart Apache. >>> >>> >>> I already found that file and did that earlier today, however I was >>> restarting tomcat6, not httpd... my bad. :) >>> >>> I have to specify --group-objectclass=posixGroup to get groups >>> imported, that's fine. But I only get a few users imported. I see that >>> by default it seem to be looking for objectclass=person. Only a few >>> user accounts have that objectclass associated, so I add >>> --user-objectclass=posixAccount as all users have this objectclass >>> associated with their account. >>> >>> $ ipa migrate-ds --user-container='ou=people' >>> --group-container='ou=group' --bind-dn='cn=directory manager' >>> --user-objectclass=account --group-objectclass=posixGroup >>> --schema=RFC2307 --continue ldap://ldapserver:399 >>> ipa: ERROR: an internal error has occurred >>> >>> Not good. I look in the /var/log/httpd/error_log file, and I find: >>> >>> [Fri Jan 27 18:12:51 2012] [error] ipa: INFO: admin at NONE: ping(): >>> SUCCESS >>> [Fri Jan 27 18:12:52 2012] [error] ipa: ERROR: non-public: >>> UnicodeDecodeError: 'utf8' codec can't decode byte 0xe5 in position 1: >>> invalid continuation byte >>> [Fri Jan 27 18:12:52 2012] [error] Traceback (most recent call last): >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 228, >>> in wsgi_execute >>> [Fri Jan 27 18:12:52 2012] [error] result = self.Command[name](*args, >>> **options) >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 432, in >>> __call__ >>> [Fri Jan 27 18:12:52 2012] [error] ret = self.run(*args, **options) >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 738, in run >>> [Fri Jan 27 18:12:52 2012] [error] return self.execute(*args, >>> **options) >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", line >>> 634, in execute >>> [Fri Jan 27 18:12:52 2012] [error] ldap, config, ds_ldap, ds_base_dn, >>> options >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", line >>> 513, in migrate >>> [Fri Jan 27 18:12:52 2012] [error] search_refs=True # migrated DS may >>> contain search references >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 188, in >>> new_f >>> [Fri Jan 27 18:12:52 2012] [error] return f(*new_args, **kwargs) >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 199, in >>> new_f >>> [Fri Jan 27 18:12:52 2012] [error] return args[0].decode(f(*args, >>> **kwargs)) >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in >>> decode >>> [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m >>> in var) >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in >>> >>> [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m >>> in var) >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 137, in >>> decode >>> [Fri Jan 27 18:12:52 2012] [error] return [self.decode(m) for m in var] >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in >>> decode >>> [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m >>> in var) >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in >>> >>> [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m >>> in var) >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 157, in >>> decode >>> [Fri Jan 27 18:12:52 2012] [error] dct[k] = self._decode_dict_val(k, v) >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 64, in >>> _decode_dict_val >>> [Fri Jan 27 18:12:52 2012] [error] return self.decode(val) >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 137, in >>> decode >>> [Fri Jan 27 18:12:52 2012] [error] return [self.decode(m) for m in var] >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 132, in >>> decode >>> [Fri Jan 27 18:12:52 2012] [error] >>> var.decode(self.encoder_settings.decode_from) >>> [Fri Jan 27 18:12:52 2012] [error] File >>> "/usr/lib64/python2.6/encodings/utf_8.py", line 16, in decode >>> [Fri Jan 27 18:12:52 2012] [error] return codecs.utf_8_decode(input, >>> errors, True) >>> [Fri Jan 27 18:12:52 2012] [error] UnicodeDecodeError: 'utf8' codec >>> can't decode byte 0xe5 in position 1: invalid continuation byte >>> [Fri Jan 27 18:12:52 2012] [error] ipa: INFO: admin at NONE: >>> migrate_ds(u'ldap://svg-p-idm02.none:389', u'********', >>> binddn=u'cn=directory manager', usercontainer=u'ou=people', >>> groupcontainer=u'ou=group', userobjectclass=(u'account',), >>> groupobjectclass=(u'posixGroup',), userignoreobjectclass=None, >>> userignoreattribute=None, groupignoreobjectclass=None, >>> groupignoreattribute=None, groupoverwritegid=False, schema=u'RFC2307', >>> continue=False, exclude_groups=None, exclude_users=None): >>> UnicodeDecodeError >>> >>> >>> Any suggestions? >>> >>> >> Oh yes and of course I've already looked for accounts with any non-utf8 >> chars in any of the output of an ldapsearch of the same ldap tree I'm >> trying to import from... > > This came up yesterday internally too. I don't believe a bug or ticket > has been filed yet. > > My best guess on what is happening, based on what I saw with our own > case, is this: > > A migrated attribute is coming in that IPA doesn't know about. We > default to treating all attributes that don't require special > treatment (like binary values) as utf-8. I'm guessing that an unknown > binary attribute is being migrated, we try to utf-8 encode it and > kablooey. > > There is no easy workaround for the above problem right now because > that happens before the --ignore* options are considered. > > One idea that has come to mind but is untested is to grab the missing > schema in the form of a discrete 389-ds-compatible schema file. Stop > dirsrv, drop the file into /etc/dirsrv/slapd-YOURINSTANCE/schema, > start dirsrv > > Then retry the migration. > > Use --ignore* if you don't want/need these attributes, then you stop > dirsrv, remove the schema file, start dirsrv. > I did use the ignore flags, ended up with: --user-ignore-attribute=memberOf,mail,telephoneNumber,userPassword --user-ignore-objectclass=organizationalPerson,posixAccount,shadowAccount,inetOrgPerson,organizationalPerson Still no luck, same error. According to your testing: is there still some value that should have been ignored I've overlooked ? On the other hand, I've only been looking at entries within the ou's that contains users and groups. Will this issue also occur if there is non-UTF8 chars in other parts of the directory? Regards, Siggi From dpal at redhat.com Fri Jan 27 19:21:42 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 27 Jan 2012 14:21:42 -0500 Subject: [Freeipa-users] Using DHCPD with IPA In-Reply-To: <4F20A07E.8070801@gmail.com> References: <4F1F5B2D.10500@gmail.com> <4F208DC0.6030602@nixtra.com> <4F20A07E.8070801@gmail.com> Message-ID: <4F22F946.2030200@redhat.com> On 01/25/2012 07:38 PM, ~Stack~ wrote: > On 01/25/2012 05:18 PM, Sigbjorn Lie wrote: >> On 01/25/2012 02:30 AM, ~Stack~ wrote: >>> 2) How do I get dhcpd to update DNS? >>> >>> Since I can't find the place to add rndc-keys to BIND, right now I have >>> to add every host manually in the web interface because dhcpd isn't >>> updating named. This is time consuming and a pain when dealing with >>> large amounts of systems. If I could figure out where the named zones >>> are stored in IPA I should be able to add my rndc-key and be OK, but >>> that gets back into question 1. >>> >>> My /etc/dhcp/dhcpd.conf file is pretty basic but all the PXE clients >>> have host entries to match their MAC with the group that allows PXE >>> booting (ex: host pxe001.project.local{hardware ethernet >>> 00:16:17:AB:E9:88; fixed-address 172.31.203.1}). Unless I mange both >>> this file and the IPA interface, the nodes have issues figuring out >>> their name. One or the other and the node has issues; both and it works. >>> I would really prefer not to manage two locations for all these nodes. >>> >>> The normal way for dhcpd to talk to BIND(named) is by having a rndc-key. >>> However, me fighting with named.conf was the big part of my problems >>> before so I am hoping there is a simple way of doing this inside IPA. >>> >>> Any ideas? >> This is what I have done to work around issues similar to yours. >> >> Over a few years I have developed a pxe boot toolbox called >> OneClickKick. OCK manages DHCPD by generating config files based upon >> information looked up from naming sources such as Mysql, NIS, or LDAP >> (IPA). It also creates the PXE boot files in tftpboot/pxelinux.cfg, and >> serves kickstart files when PXE booting clients. >> >> I have integrated OCK with IPA to make IPA keep records of the MAC >> address, and base my DHCP config upon the information I get from IPA. >> For your configuration, the steps for adding a new client would be the >> following: >> >> 1. Add the host to IPA, specify an IP address so that forward and >> reverse DNS records are created for the host >> 2. The host will appear in OneClickKick, select modify, add the MAC >> address (this is being written to the host object in IPA), and select it >> for PXE boot / kickstart. This will generate the DHCP config file, >> reload dhcpd, and create the required files in the tftpboot/pxelinux.cfg >> directory (if you enabled it for PXE booting). >> 3. PXE boot the client. >> >> By doing this you eliminate the need for dhcpd to update the DNS server, >> because the records are already there. >> >> The MAC addresses stored in IPA can also be used by normal Linux and >> Solaris (Jumpstart) clients by utilizing their "ethers" table in >> nsswitch.conf. >> >> Have a look at the link below to read more and download if you think >> OneClickKick could suit your environment. >> >> http://sourceforge.net/projects/oneclickkick/ > Thank you! I will take a look at it tomorrow. > > ~Stack~ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users What Adam was trying to say is that if you want a little bit more security to this enrollment process you need when you register host with IPA ask IPA for generated OTP (or provide your own). This OTP needs then to be seeded into the kickstart file. As the Kickstart file is processed the ipa-client-install command will be called with this OTP as one of the parameters. The ipa-client will authenticate to IPA server and finish the configuration of the system provisioning the keys. When the machine is rebooted you need to do the same sequence except you need to delete and re add the host or clean its keytab and status (both options would work). The OTP capability was specifically added to address automatic provisioning like this in a secure way. Would it work for you? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Jan 27 19:28:32 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 27 Jan 2012 14:28:32 -0500 Subject: [Freeipa-users] Using DHCPD with IPA In-Reply-To: <4F22F946.2030200@redhat.com> References: <4F1F5B2D.10500@gmail.com> <4F208DC0.6030602@nixtra.com> <4F20A07E.8070801@gmail.com> <4F22F946.2030200@redhat.com> Message-ID: <1327692512.13963.222.camel@willson.li.ssimo.org> On Fri, 2012-01-27 at 14:21 -0500, Dmitri Pal wrote: > On 01/25/2012 07:38 PM, ~Stack~ wrote: > > On 01/25/2012 05:18 PM, Sigbjorn Lie wrote: > > > On 01/25/2012 02:30 AM, ~Stack~ wrote: > > > > 2) How do I get dhcpd to update DNS? > > > > > > > > Since I can't find the place to add rndc-keys to BIND, right now I have > > > > to add every host manually in the web interface because dhcpd isn't > > > > updating named. This is time consuming and a pain when dealing with > > > > large amounts of systems. If I could figure out where the named zones > > > > are stored in IPA I should be able to add my rndc-key and be OK, but > > > > that gets back into question 1. > > > > > > > > My /etc/dhcp/dhcpd.conf file is pretty basic but all the PXE clients > > > > have host entries to match their MAC with the group that allows PXE > > > > booting (ex: host pxe001.project.local{hardware ethernet > > > > 00:16:17:AB:E9:88; fixed-address 172.31.203.1}). Unless I mange both > > > > this file and the IPA interface, the nodes have issues figuring out > > > > their name. One or the other and the node has issues; both and it works. > > > > I would really prefer not to manage two locations for all these nodes. > > > > > > > > The normal way for dhcpd to talk to BIND(named) is by having a rndc-key. > > > > However, me fighting with named.conf was the big part of my problems > > > > before so I am hoping there is a simple way of doing this inside IPA. > > > > > > > > Any ideas? > > > This is what I have done to work around issues similar to yours. > > > > > > Over a few years I have developed a pxe boot toolbox called > > > OneClickKick. OCK manages DHCPD by generating config files based upon > > > information looked up from naming sources such as Mysql, NIS, or LDAP > > > (IPA). It also creates the PXE boot files in tftpboot/pxelinux.cfg, and > > > serves kickstart files when PXE booting clients. > > > > > > I have integrated OCK with IPA to make IPA keep records of the MAC > > > address, and base my DHCP config upon the information I get from IPA. > > > For your configuration, the steps for adding a new client would be the > > > following: > > > > > > 1. Add the host to IPA, specify an IP address so that forward and > > > reverse DNS records are created for the host > > > 2. The host will appear in OneClickKick, select modify, add the MAC > > > address (this is being written to the host object in IPA), and select it > > > for PXE boot / kickstart. This will generate the DHCP config file, > > > reload dhcpd, and create the required files in the tftpboot/pxelinux.cfg > > > directory (if you enabled it for PXE booting). > > > 3. PXE boot the client. > > > > > > By doing this you eliminate the need for dhcpd to update the DNS server, > > > because the records are already there. > > > > > > The MAC addresses stored in IPA can also be used by normal Linux and > > > Solaris (Jumpstart) clients by utilizing their "ethers" table in > > > nsswitch.conf. > > > > > > Have a look at the link below to read more and download if you think > > > OneClickKick could suit your environment. > > > > > > http://sourceforge.net/projects/oneclickkick/ > > Thank you! I will take a look at it tomorrow. > > > > ~Stack~ > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > What Adam was trying to say is that if you want a little bit more > security to this enrollment process you need when you register host > with IPA ask IPA for generated OTP (or provide your own). This OTP > needs then to be seeded into the kickstart file. As the Kickstart file > is processed the ipa-client-install command will be called with this > OTP as one of the parameters. The ipa-client will authenticate to IPA > server and finish the configuration of the system provisioning the > keys. > > When the machine is rebooted you need to do the same sequence except > you need to delete and re add the host or clean its keytab and status > (both options would work). > > The OTP capability was specifically added to address automatic > provisioning like this in a secure way. > > Would it work for you? This needs some more explanation. Recycling the keytab very often can lead to connection errors (users may have valid tickets for the machine, and the machine will not longer recognize them). Keeping around the keytab for these host would be safer, even if you end up refreshing the keytab using the OTP method, although if you keep around the keytab then using the OTP seem more burden than anything. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Jan 27 21:25:01 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 27 Jan 2012 16:25:01 -0500 Subject: [Freeipa-users] Using DHCPD with IPA In-Reply-To: <1327692512.13963.222.camel@willson.li.ssimo.org> References: <4F1F5B2D.10500@gmail.com> <4F208DC0.6030602@nixtra.com> <4F20A07E.8070801@gmail.com> <4F22F946.2030200@redhat.com> <1327692512.13963.222.camel@willson.li.ssimo.org> Message-ID: <4F23162D.9000600@redhat.com> On 01/27/2012 02:28 PM, Simo Sorce wrote: > On Fri, 2012-01-27 at 14:21 -0500, Dmitri Pal wrote: >> On 01/25/2012 07:38 PM, ~Stack~ wrote: >>> On 01/25/2012 05:18 PM, Sigbjorn Lie wrote: >>>> On 01/25/2012 02:30 AM, ~Stack~ wrote: >>>>> 2) How do I get dhcpd to update DNS? >>>>> >>>>> Since I can't find the place to add rndc-keys to BIND, right now I have >>>>> to add every host manually in the web interface because dhcpd isn't >>>>> updating named. This is time consuming and a pain when dealing with >>>>> large amounts of systems. If I could figure out where the named zones >>>>> are stored in IPA I should be able to add my rndc-key and be OK, but >>>>> that gets back into question 1. >>>>> >>>>> My /etc/dhcp/dhcpd.conf file is pretty basic but all the PXE clients >>>>> have host entries to match their MAC with the group that allows PXE >>>>> booting (ex: host pxe001.project.local{hardware ethernet >>>>> 00:16:17:AB:E9:88; fixed-address 172.31.203.1}). Unless I mange both >>>>> this file and the IPA interface, the nodes have issues figuring out >>>>> their name. One or the other and the node has issues; both and it works. >>>>> I would really prefer not to manage two locations for all these nodes. >>>>> >>>>> The normal way for dhcpd to talk to BIND(named) is by having a rndc-key. >>>>> However, me fighting with named.conf was the big part of my problems >>>>> before so I am hoping there is a simple way of doing this inside IPA. >>>>> >>>>> Any ideas? >>>> This is what I have done to work around issues similar to yours. >>>> >>>> Over a few years I have developed a pxe boot toolbox called >>>> OneClickKick. OCK manages DHCPD by generating config files based upon >>>> information looked up from naming sources such as Mysql, NIS, or LDAP >>>> (IPA). It also creates the PXE boot files in tftpboot/pxelinux.cfg, and >>>> serves kickstart files when PXE booting clients. >>>> >>>> I have integrated OCK with IPA to make IPA keep records of the MAC >>>> address, and base my DHCP config upon the information I get from IPA. >>>> For your configuration, the steps for adding a new client would be the >>>> following: >>>> >>>> 1. Add the host to IPA, specify an IP address so that forward and >>>> reverse DNS records are created for the host >>>> 2. The host will appear in OneClickKick, select modify, add the MAC >>>> address (this is being written to the host object in IPA), and select it >>>> for PXE boot / kickstart. This will generate the DHCP config file, >>>> reload dhcpd, and create the required files in the tftpboot/pxelinux.cfg >>>> directory (if you enabled it for PXE booting). >>>> 3. PXE boot the client. >>>> >>>> By doing this you eliminate the need for dhcpd to update the DNS server, >>>> because the records are already there. >>>> >>>> The MAC addresses stored in IPA can also be used by normal Linux and >>>> Solaris (Jumpstart) clients by utilizing their "ethers" table in >>>> nsswitch.conf. >>>> >>>> Have a look at the link below to read more and download if you think >>>> OneClickKick could suit your environment. >>>> >>>> http://sourceforge.net/projects/oneclickkick/ >>> Thank you! I will take a look at it tomorrow. >>> >>> ~Stack~ >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> What Adam was trying to say is that if you want a little bit more >> security to this enrollment process you need when you register host >> with IPA ask IPA for generated OTP (or provide your own). This OTP >> needs then to be seeded into the kickstart file. As the Kickstart file >> is processed the ipa-client-install command will be called with this >> OTP as one of the parameters. The ipa-client will authenticate to IPA >> server and finish the configuration of the system provisioning the >> keys. >> >> When the machine is rebooted you need to do the same sequence except >> you need to delete and re add the host or clean its keytab and status >> (both options would work). >> >> The OTP capability was specifically added to address automatic >> provisioning like this in a secure way. >> >> Would it work for you? > This needs some more explanation. > > Recycling the keytab very often can lead to connection errors (users may > have valid tickets for the machine, and the machine will not longer > recognize them). > > Keeping around the keytab for these host would be safer, even if you end > up refreshing the keytab using the OTP method, although if you keep > around the keytab then using the OTP seem more burden than anything. > > Simo. > This depends on the assumption about the infrastructure. If the reboot means that it is a completely new entity may be the tickets should actually not be valid any more. But then the name should probably be different too and reboot would be = provisioning. With the stateless systems it is really hard to draw the line between the two. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From JR.Aquino at citrix.com Sat Jan 28 01:31:33 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Sat, 28 Jan 2012 01:31:33 +0000 Subject: [Freeipa-users] WebUI With Windows, Firefox, and MIT Kerberos Message-ID: <4A3F2452-B056-45A8-A3C5-BBA4D02BD391@citrixonline.com> Has anyone successfully gotten firefox in windows with firefox and mit kerberos? I've followed several how to's, but i cant get firefox to take/pass my tgt. -Jr From JR.Aquino at citrix.com Sat Jan 28 01:53:10 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Sat, 28 Jan 2012 01:53:10 +0000 Subject: [Freeipa-users] WebUI With Windows, Firefox, and MIT Kerberos In-Reply-To: <4A3F2452-B056-45A8-A3C5-BBA4D02BD391@citrixonline.com> References: <4A3F2452-B056-45A8-A3C5-BBA4D02BD391@citrixonline.com> Message-ID: On Jan 27, 2012, at 5:31 PM, Jr Aquino wrote: Has anyone successfully gotten firefox in windows with firefox and mit kerberos? I've followed several how to's, but i cant get firefox to take/pass my tgt. The Key to success: network.negotiate-auth.gsslib: C:\Program Files\MIT\Kerberos\bin\gssapi32.dll I had been previously using lib\i386/gssapi32.lib and thats what was breaking it. The rest of the documentation on the FreeIPA site is sound. We could probably stand to add that 1 line to the doc at http://freeipa.com/page/ClientConfigurationGuide From boot.iso at gmail.com Sat Jan 28 17:22:01 2012 From: boot.iso at gmail.com (Ranjandas A P) Date: Sat, 28 Jan 2012 17:22:01 +0000 Subject: [Freeipa-users] FreeIPA Ubuntu Client Message-ID: Hi All, Is there anybody who is woking on packaging IPA Client for Ubuntu 10.04? I am trying to build ipa-client for Ubuntu but, stuck with Mozldap dependency. Thanks & Regards Ranjandas A P -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Sat Jan 28 18:47:09 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Sat, 28 Jan 2012 13:47:09 -0500 Subject: [Freeipa-users] FreeIPA Ubuntu Client In-Reply-To: References: Message-ID: <1327776429.2131.64.camel@sgallagh520.sgallagh.bos.redhat.com> On Sat, 2012-01-28 at 17:22 +0000, Ranjandas A P wrote: > Hi All, > > Is there anybody who is woking on packaging IPA Client for Ubuntu > 10.04? > > I am trying to build ipa-client for Ubuntu but, stuck with Mozldap > dependency. Timo Aaltonen has been working on this. (CCed). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From erinn.looneytriggs at gmail.com Sat Jan 28 18:53:19 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Sat, 28 Jan 2012 09:53:19 -0900 Subject: [Freeipa-users] WebUI With Windows, Firefox, and MIT Kerberos In-Reply-To: References: <4A3F2452-B056-45A8-A3C5-BBA4D02BD391@citrixonline.com> Message-ID: <4F24441F.2080902@gmail.com> On 1/27/2012 4:53 PM, JR Aquino wrote: > > On Jan 27, 2012, at 5:31 PM, Jr Aquino wrote: > > Has anyone successfully gotten firefox in windows with firefox and mit kerberos? > > I've followed several how to's, but i cant get firefox to take/pass my tgt. > > > The Key to success: > > network.negotiate-auth.gsslib: C:\Program Files\MIT\Kerberos\bin\gssapi32.dll > > I had been previously using lib\i386/gssapi32.lib and thats what was breaking it. > > The rest of the documentation on the FreeIPA site is sound. > > We could probably stand to add that 1 line to the doc at http://freeipa.com/page/ClientConfigurationGuide > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The only other thing I would add here, at least for me, was on an x86_64 install of windows I needed to use: C:\Program Files (x86)\MIT\Kerberos\bin\gssapi32.dll -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From tjaalton at ubuntu.com Sun Jan 29 09:43:15 2012 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Sun, 29 Jan 2012 11:43:15 +0200 Subject: [Freeipa-users] FreeIPA Ubuntu Client In-Reply-To: <1327776429.2131.64.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1327776429.2131.64.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4F2514B3.5070601@ubuntu.com> 28.01.2012 20:47, Stephen Gallagher kirjoitti: > On Sat, 2012-01-28 at 17:22 +0000, Ranjandas A P wrote: >> Hi All, >> >> Is there anybody who is woking on packaging IPA Client for Ubuntu >> 10.04? >> >> I am trying to build ipa-client for Ubuntu but, stuck with Mozldap >> dependency. Hi, I'm concentrating on getting the pieces ready for the next LTS (12.04). Packages can be backported, but only after they've proven to work on the new release, so backporting will be a low priority for me at least for now. -- t From Steven.Jones at vuw.ac.nz Mon Jan 30 01:03:02 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 30 Jan 2012 01:03:02 +0000 Subject: [Freeipa-users] unable to install or uninstall ipa Message-ID: <833D8E48405E064EBC54C84EC6B36E404CB7A19E@STAWINCOX10MBX1.staff.vuw.ac.nz> I have a failed install with lots of critical failures... :( When I try to re-install it says its installed but when I try to --uninstall it will not..... How do I clean it up manually? ======== [root at vuwunicoipam001 ~]# ipa-server-install --uninstall This is a NON REVERSIBLE operation and will delete all data and configuration! Are you sure you want to continue with the uninstall procedure? [no]: yes Shutting down all IPA services Removing IPA client configuration Unconfiguring directory server Unexpected error - see ipaserver-uninstall.log for details: [Errno 2] No such file or directory: '/etc/dirsrv/slapd-UNIX-VUW-AC-NZ' [root at vuwunicoipam001 ~]# ======== regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaserver-uninstall.log Type: application/octet-stream Size: 10921 bytes Desc: ipaserver-uninstall.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaserver-install.log Type: application/octet-stream Size: 733 bytes Desc: ipaserver-install.log URL: From Steven.Jones at vuw.ac.nz Mon Jan 30 01:11:20 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 30 Jan 2012 01:11:20 +0000 Subject: [Freeipa-users] unable to install or uninstall ipa In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CB7A19E@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CB7A19E@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CB7A1BF@STAWINCOX10MBX1.staff.vuw.ac.nz> Example of install failure messages, ====== Warning: skipping DNS resolution of host vuwunicoipam001.unix.vuw.ac.nz The IPA Master Server will be configured with Hostname: vuwunicoipam001.unix.vuw.ac.nz IP address: 10.70.3.10 Domain name: unix.vuw.ac.nz The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring ntpd [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd done configuring ntpd. Configuring directory server: Estimated time 1 minute [1/35]: creating directory server user [2/35]: creating directory server instance [3/35]: adding default schema [4/35]: enabling memberof plugin root : CRITICAL Failed to load memberof-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/memberof-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpkbE724' returned non-zero exit status 255 [5/35]: enabling referential integrity plugin root : CRITICAL Failed to load referint-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/referint-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpExKKnk' returned non-zero exit status 255 [6/35]: enabling winsync plugin root : CRITICAL Failed to load ipa-winsync-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/ipa-winsync-conf.ldif -x -D cn=Directory Manager -y /tmp/tmppChSx9' returned non-zero exit status 255 [7/35]: configuring replication version plugin root : CRITICAL Failed to load version-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/version-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpqy9Fkp' returned non-zero exit status 255 [8/35]: enabling IPA enrollment plugin root : CRITICAL Failed to load enrollment-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpoWPpcO -x -D cn=Directory Manager -y /tmp/tmpxbRGyx' returned non-zero exit status 255 [9/35]: enabling ldapi root : CRITICAL Failed to load ldapi.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpVSJoE2 -x -D cn=Directory Manager -y /tmp/tmpqsK_aD' returned non-zero exit status 255 [10/35]: configuring uniqueness plugin root : CRITICAL Failed to load unique-attributes.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpWJEh76 -x -D cn=Directory Manager -y /tmp/tmpzxvY9u' returned non-zero exit status 255 [11/35]: configuring uuid plugin root : CRITICAL Failed to load uuid-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/uuid-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpdYNh2T' returned non-zero exit status 255 root : CRITICAL Failed to load uuid-ipauniqueid.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpkEOmk2 -x -D cn=Directory Manager -y /tmp/tmp9ZDoXY' returned non-zero exit status 255 [12/35]: configuring modrdn plugin root : CRITICAL Failed to load modrdn-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/modrdn-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpofFRs8' returned non-zero exit status 255 root : CRITICAL Failed to load modrdn-krbprinc.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpDxRP25 -x -D cn=Directory Manager -y /tmp/tmpUexNQN' returned non-zero exit status 255 [13/35]: enabling entryUSN plugin root : CRITICAL Failed to load entryusn.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/entryusn.ldif -x -D cn=Directory Manager -y /tmp/tmpgsBw1B' returned non-zero exit status 255 ========= regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Monday, 30 January 2012 2:03 p.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] unable to install or uninstall ipa I have a failed install with lots of critical failures... :( When I try to re-install it says its installed but when I try to --uninstall it will not..... How do I clean it up manually? ======== [root at vuwunicoipam001 ~]# ipa-server-install --uninstall This is a NON REVERSIBLE operation and will delete all data and configuration! Are you sure you want to continue with the uninstall procedure? [no]: yes Shutting down all IPA services Removing IPA client configuration Unconfiguring directory server Unexpected error - see ipaserver-uninstall.log for details: [Errno 2] No such file or directory: '/etc/dirsrv/slapd-UNIX-VUW-AC-NZ' [root at vuwunicoipam001 ~]# ======== regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ From dale at themacartneyclan.com Mon Jan 30 12:16:47 2012 From: dale at themacartneyclan.com (Dale Macartney) Date: Mon, 30 Jan 2012 12:16:47 +0000 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos Message-ID: <4F268A2F.5050408@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all I'm working on a test lab setup at the moment with RHEL 6.2 running IPA 2.1 and experimenting with simple mail server setups. . I have mail being received base on pam lookups from IPA. The mail server is tapped into IPA via the ipa-client-install. I am using a default install of the dovecot rpm from RHN, and dovecot is listening via imap/imaps, however all authentication requests fail when attempting to login via imap.. I added the necessary keytabs for imap/mail.example.com and imaps/mail.example.com to /etc/krb5.keytab but this hasn't allowed authentication. has anyone set up dovecot through IPA before? Any recommendations? thanks all Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPJoodAAoJEAJsWS61tB+qgfAQALXxeXRMbC+8n6+ixmqYPOL3 q1YkUQ9YgCfbCpGQcNiR0g4lDWavTZkZSMUhR485qH858PpZ7Pmf7Wu1vE6xCWPB 2v2mdcwkhO9tdpYMiUCn4TN+cgxJcdpr4YlPECAA/K60ZoeSFFNtfjQnYUoMByn/ OCf19cw84sNFuJlCeBOGiCGWDKQWhOy2eXj68o0P1u8eZioOi+pAOD/c31p/JXXC 3jeG3d6l8wDrIXT5xHIbiXwx45k8Fg2kIAdAcZsbxUBC39QH558iQMUOkwIJ9UAi msOu60wfmoC8f99KZl1hRb6OAG59uPnMmzirVKyCfyRub/2mgUfThON59zyy8eb7 OLHzj5XDIX5Wb6+WyvP7X0QaPxLK75f/qzDoFONQrotVCa0JLb6zji6lt3SfVnFT s47ynT8pQznq1/wk3MkYPTDHTHYbOAwdPwlBD1R7UBY2gL2zXu6ixnypF5R1kaRY 5jnDeXF3vqOoOrdMBMX/fre4Dpx3wW3zSB4MsR4n9OZpooTkzIiRR6/3Qe7PZFNT CELaUi5jkwrVwk4datqGPcIestLc74bosVU+rJsMTGTRGFIBqP7L6w2dwVj2ZnHT okMySzEn2U2jIvxu4HAsFCjxZ5qmAY4S/yZsemKzqbyinyT9VdeEroqeUXDY5Y7o 9PG1gWdqAiZsGKBHTXDP =FOu6 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 5790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From ondrejv at s3group.cz Mon Jan 30 12:45:43 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Mon, 30 Jan 2012 13:45:43 +0100 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F268A2F.5050408@themacartneyclan.com> References: <4F268A2F.5050408@themacartneyclan.com> Message-ID: <4F2690F7.2000600@s3group.cz> Dovecot is not running as root -> can't read your krb5.keytab...? On 01/30/2012 01:16 PM, Dale Macartney wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all > > I'm working on a test lab setup at the moment with RHEL 6.2 running IPA > 2.1 and experimenting with simple mail server setups. . > > I have mail being received base on pam lookups from IPA. The mail server > is tapped into IPA via the ipa-client-install. > > I am using a default install of the dovecot rpm from RHN, and dovecot is > listening via imap/imaps, however all authentication requests fail when > attempting to login via imap.. > > I added the necessary keytabs for imap/mail.example.com and > imaps/mail.example.com to /etc/krb5.keytab but this hasn't allowed > authentication. > > has anyone set up dovecot through IPA before? Any recommendations? > > > thanks all > > Dale > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPJoodAAoJEAJsWS61tB+qgfAQALXxeXRMbC+8n6+ixmqYPOL3 > q1YkUQ9YgCfbCpGQcNiR0g4lDWavTZkZSMUhR485qH858PpZ7Pmf7Wu1vE6xCWPB > 2v2mdcwkhO9tdpYMiUCn4TN+cgxJcdpr4YlPECAA/K60ZoeSFFNtfjQnYUoMByn/ > OCf19cw84sNFuJlCeBOGiCGWDKQWhOy2eXj68o0P1u8eZioOi+pAOD/c31p/JXXC > 3jeG3d6l8wDrIXT5xHIbiXwx45k8Fg2kIAdAcZsbxUBC39QH558iQMUOkwIJ9UAi > msOu60wfmoC8f99KZl1hRb6OAG59uPnMmzirVKyCfyRub/2mgUfThON59zyy8eb7 > OLHzj5XDIX5Wb6+WyvP7X0QaPxLK75f/qzDoFONQrotVCa0JLb6zji6lt3SfVnFT > s47ynT8pQznq1/wk3MkYPTDHTHYbOAwdPwlBD1R7UBY2gL2zXu6ixnypF5R1kaRY > 5jnDeXF3vqOoOrdMBMX/fre4Dpx3wW3zSB4MsR4n9OZpooTkzIiRR6/3Qe7PZFNT > CELaUi5jkwrVwk4datqGPcIestLc74bosVU+rJsMTGTRGFIBqP7L6w2dwVj2ZnHT > okMySzEn2U2jIvxu4HAsFCjxZ5qmAY4S/yZsemKzqbyinyT9VdeEroqeUXDY5Y7o > 9PG1gWdqAiZsGKBHTXDP > =FOu6 > -----END PGP SIGNATURE----- > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Proud winners of the prestigious Irish Software Exporter Award 2011 from Irish Exporters Association (IEA). Please, refer to our web site for more details regarding the award. -------- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dale at themacartneyclan.com Mon Jan 30 13:10:47 2012 From: dale at themacartneyclan.com (Dale Macartney) Date: Mon, 30 Jan 2012 13:10:47 +0000 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F2690F7.2000600@s3group.cz> References: <4F268A2F.5050408@themacartneyclan.com> <4F2690F7.2000600@s3group.cz> Message-ID: <4F2696D7.70002@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks Ondrej, although not directly the cause you did manage to get me in the right direction. selinux and permissions were fine, it was actually tailing to locate the mailbox... i went through quite a few logs to find out that the auth requests were actually successful to IPA.. one extra line was needed in dovecot.conf to allow it to work. However this was not an ipa issue at all. mail_location = mbox:~/mail:INBOX=/var/mail/%u Clearly dovecot was looking in the wrong location for a mail file. Cheers Dale On 01/30/2012 12:45 PM, Ondrej Valousek wrote: > Dovecot is not running as root -> can't read your krb5.keytab...? > > On 01/30/2012 01:16 PM, Dale Macartney wrote: > Hi all > > I'm working on a test lab setup at the moment with RHEL 6.2 running IPA > 2.1 and experimenting with simple mail server setups. . > > I have mail being received base on pam lookups from IPA. The mail server > is tapped into IPA via the ipa-client-install. > > I am using a default install of the dovecot rpm from RHN, and dovecot is > listening via imap/imaps, however all authentication requests fail when > attempting to login via imap.. > > I added the necessary keytabs for imap/mail.example.com and > imaps/mail.example.com to /etc/krb5.keytab but this hasn't allowed > authentication. > > has anyone set up dovecot through IPA before? Any recommendations? > > > thanks all > > Dale > > >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > ------------------------- > Proud winners of the prestigious Irish Software Exporter Award 2011 from Irish Exporters Association (IEA). Please, refer to our web site for more details regarding the award. > ------------------------- > The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 > ------------------------- > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPJpbOAAoJEAJsWS61tB+qVr0P+wWAyTGvYAPiTOULdY/zAvyM Tn6Of0Sz+/HMJCiLZuajGuIprnqkJqt9XW7a3pwAN9zrFp3J3hQb2ObljcqcBro/ 7L6WRJQODp3wAG327kyrPOz97GpAY7WSujiO3+9KhASy7To1Lt/9VMUQJ8f4nzT5 6hzRJJG3js+gTNusuXz9dhN+NmsWcJOAfTYIM+n5jf5crg/UqnpzugVb34ZH8n6D NPfG5i/ATWfvTavaF7JsOmBiWaNVAmYZ+zBWEMxjmRdOn2GdWS1ZC2p3+L3fvV2F lkVv2k5RB1dvk6ncYp4BnBUIxRJKVCqeG10ENtMJU+4vY4rjJ0kv9wQOVgFICuhM XyRyNj6U5oVNIcGm25C6j7nphUY7EzTub7Ftg659Ar4KMXV8Db7Rb2moebzFRU4Z Ri/sRal6+Nbwt2VmICVf3yMADXhJ4yPPF/ZMMDG6TlBZ5DfEVJ4PpUQt5nzjXchF hZ4okKyuMuiZqfo1V+8HCmVBSYaGnTHhfJouvJibIdOu5Y72ES8zPnR714siMSRG 0a+/hv9MzDiFW9IKF/tmE2emWk9DK0d1h2N2MnN91BqnqJCNq+Oh7/2FmQsOkBOW +hL3fGiShYgedfCm7yF7B+1vvYLbLTgbu1g3WwiqqISehg5sUGeOehSgGFJyh3dc InOQ0uG0nRKbEJxYQzdB =/A/H -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 5790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From dpal at redhat.com Mon Jan 30 13:46:43 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 30 Jan 2012 08:46:43 -0500 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F268A2F.5050408@themacartneyclan.com> References: <4F268A2F.5050408@themacartneyclan.com> Message-ID: <4F269F43.40607@redhat.com> On 01/30/2012 07:16 AM, Dale Macartney wrote: > > Hi all > > I'm working on a test lab setup at the moment with RHEL 6.2 running IPA > 2.1 and experimenting with simple mail server setups. . > > I have mail being received base on pam lookups from IPA. The mail server > is tapped into IPA via the ipa-client-install. > > I am using a default install of the dovecot rpm from RHN, and dovecot is > listening via imap/imaps, however all authentication requests fail when > attempting to login via imap.. > > I added the necessary keytabs for imap/mail.example.com and > imaps/mail.example.com to /etc/krb5.keytab but this hasn't allowed > authentication. > > has anyone set up dovecot through IPA before? Any recommendations? > > Hi Dale, Will you be so kind to share with the list a little bit more details about how to setup Dovecot with IPA? If you can provide step by step instructions we would publish them on the FreeIPA wiki. Thank you Dmitri > thanks all > > Dale > > _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Jan 30 14:00:52 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 09:00:52 -0500 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <1327690377.2131.57.camel@sgallagh520.sgallagh.bos.redhat.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> <4F22DBBE.10502@nixtra.com> <4F22E29A.9050709@nixtra.com> <4F22F00D.3000006@redhat.com> <1327690377.2131.57.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4F26A294.9090208@redhat.com> Stephen Gallagher wrote: > On Fri, 2012-01-27 at 13:42 -0500, Rob Crittenden wrote: >> >> This came up yesterday internally too. I don't believe a bug or ticket >> has been filed yet. >> >> My best guess on what is happening, based on what I saw with our own >> case, is this: >> >> A migrated attribute is coming in that IPA doesn't know about. We >> default to treating all attributes that don't require special treatment >> (like binary values) as utf-8. I'm guessing that an unknown binary >> attribute is being migrated, we try to utf-8 encode it and kablooey. >> >> There is no easy workaround for the above problem right now because that >> happens before the --ignore* options are considered. >> > > Why don't we just base64-encode unknown attributes instead of treating > them like UTF-8? The LDAP server is *supposed* to be able to handle this > implicitly. For migration we're going to have to reject them outright because the migration will fail eventually anyway. rob From rcritten at redhat.com Mon Jan 30 14:06:34 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 09:06:34 -0500 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <4F22F491.3040305@nixtra.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> <4F22DBBE.10502@nixtra.com> <4F22E29A.9050709@nixtra.com> <4F22F00D.3000006@redhat.com> <4F22F491.3040305@nixtra.com> Message-ID: <4F26A3EA.7080101@redhat.com> Sigbjorn Lie wrote: > On 01/27/2012 07:42 PM, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >>> On 01/27/2012 06:15 PM, Sigbjorn Lie wrote: >>>> On 01/27/2012 03:55 PM, Rob Crittenden wrote: >>>>> Sigbjorn Lie wrote: >>>>>> >>>>>> On Fri, January 27, 2012 15:37, Rob Crittenden wrote: >>>>>>> Stephen Gallagher wrote: >>>>>>> >>>>>>>> On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: >>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> >>>>>>>>> The first naming context returned from the LDAP server is always >>>>>>>>> chosen >>>>>>>>> when using migrate-ds. This makes my import fail when I attempt >>>>>>>>> to import users and groups from >>>>>>>>> a previous LDAP server having more than 1 naming contexts >>>>>>>>> available. >>>>>>>>> >>>>>>>>> The migrate-ds script should accept an option to specify what >>>>>>>>> base_dn I >>>>>>>>> would like to import from. >>>>>>>>> >>>>>>>>> Is there such an option today? I cannot find it... >>>>>>>>> >>>>>>> >>>>>>> Not currently. I noticed this earlier in the week and opened a >>>>>>> ticket on >>>>>>> it, https://fedorahosted.org/freeipa/ticket/2314 >>>>>>> >>>>>>>> >>>>>>>> Just to add to this request, if the original LDAP server has a >>>>>>>> defaultNamingContext attribute, it should be honored for >>>>>>>> auto-detecting which base to migrate. >>>>>>> >>>>>>> I'll update the 2314 to ensure we don't forget about this. 389-ds >>>>>>> just >>>>>>> added support for defaultNamingContext. >>>>>>> >>>>>> >>>>>> Ok, thank you. >>>>>> >>>>>> Anything I can do to work around this issue today? I suppose there >>>>>> is just a file that need to be >>>>>> hacked to set a set a value instead of the auto-detected value... ? >>>>>> >>>>> >>>>> /usr/lib/python*/site-packages/ipalib/plugins/migration.py >>>>> >>>>> ~line 620 you'll see a block starting with the comment "retrieve DS >>>>> base DN". >>>>> >>>>> Comment out the next 8 lines by prefixing them with # (these query to >>>>> get the namingContext then pull the first value out). >>>>> >>>>> Add: >>>>> >>>>> ds_base_dn = 'dc=yourbasedn,dc=com' >>>>> >>>>> Alternatively you could always just add the above line to override >>>>> what is detected. Commenting out just saves an LDAP lookup. >>>>> >>>>> Restart Apache. >>>> >>>> >>>> I already found that file and did that earlier today, however I was >>>> restarting tomcat6, not httpd... my bad. :) >>>> >>>> I have to specify --group-objectclass=posixGroup to get groups >>>> imported, that's fine. But I only get a few users imported. I see that >>>> by default it seem to be looking for objectclass=person. Only a few >>>> user accounts have that objectclass associated, so I add >>>> --user-objectclass=posixAccount as all users have this objectclass >>>> associated with their account. >>>> >>>> $ ipa migrate-ds --user-container='ou=people' >>>> --group-container='ou=group' --bind-dn='cn=directory manager' >>>> --user-objectclass=account --group-objectclass=posixGroup >>>> --schema=RFC2307 --continue ldap://ldapserver:399 >>>> ipa: ERROR: an internal error has occurred >>>> >>>> Not good. I look in the /var/log/httpd/error_log file, and I find: >>>> >>>> [Fri Jan 27 18:12:51 2012] [error] ipa: INFO: admin at NONE: ping(): >>>> SUCCESS >>>> [Fri Jan 27 18:12:52 2012] [error] ipa: ERROR: non-public: >>>> UnicodeDecodeError: 'utf8' codec can't decode byte 0xe5 in position 1: >>>> invalid continuation byte >>>> [Fri Jan 27 18:12:52 2012] [error] Traceback (most recent call last): >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 228, >>>> in wsgi_execute >>>> [Fri Jan 27 18:12:52 2012] [error] result = self.Command[name](*args, >>>> **options) >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 432, in >>>> __call__ >>>> [Fri Jan 27 18:12:52 2012] [error] ret = self.run(*args, **options) >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 738, in run >>>> [Fri Jan 27 18:12:52 2012] [error] return self.execute(*args, >>>> **options) >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", line >>>> 634, in execute >>>> [Fri Jan 27 18:12:52 2012] [error] ldap, config, ds_ldap, ds_base_dn, >>>> options >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", line >>>> 513, in migrate >>>> [Fri Jan 27 18:12:52 2012] [error] search_refs=True # migrated DS may >>>> contain search references >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 188, in >>>> new_f >>>> [Fri Jan 27 18:12:52 2012] [error] return f(*new_args, **kwargs) >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 199, in >>>> new_f >>>> [Fri Jan 27 18:12:52 2012] [error] return args[0].decode(f(*args, >>>> **kwargs)) >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in >>>> decode >>>> [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m >>>> in var) >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in >>>> >>>> [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m >>>> in var) >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 137, in >>>> decode >>>> [Fri Jan 27 18:12:52 2012] [error] return [self.decode(m) for m in var] >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in >>>> decode >>>> [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m >>>> in var) >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 139, in >>>> >>>> [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m >>>> in var) >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 157, in >>>> decode >>>> [Fri Jan 27 18:12:52 2012] [error] dct[k] = self._decode_dict_val(k, v) >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 64, in >>>> _decode_dict_val >>>> [Fri Jan 27 18:12:52 2012] [error] return self.decode(val) >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 137, in >>>> decode >>>> [Fri Jan 27 18:12:52 2012] [error] return [self.decode(m) for m in var] >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 132, in >>>> decode >>>> [Fri Jan 27 18:12:52 2012] [error] >>>> var.decode(self.encoder_settings.decode_from) >>>> [Fri Jan 27 18:12:52 2012] [error] File >>>> "/usr/lib64/python2.6/encodings/utf_8.py", line 16, in decode >>>> [Fri Jan 27 18:12:52 2012] [error] return codecs.utf_8_decode(input, >>>> errors, True) >>>> [Fri Jan 27 18:12:52 2012] [error] UnicodeDecodeError: 'utf8' codec >>>> can't decode byte 0xe5 in position 1: invalid continuation byte >>>> [Fri Jan 27 18:12:52 2012] [error] ipa: INFO: admin at NONE: >>>> migrate_ds(u'ldap://svg-p-idm02.none:389', u'********', >>>> binddn=u'cn=directory manager', usercontainer=u'ou=people', >>>> groupcontainer=u'ou=group', userobjectclass=(u'account',), >>>> groupobjectclass=(u'posixGroup',), userignoreobjectclass=None, >>>> userignoreattribute=None, groupignoreobjectclass=None, >>>> groupignoreattribute=None, groupoverwritegid=False, schema=u'RFC2307', >>>> continue=False, exclude_groups=None, exclude_users=None): >>>> UnicodeDecodeError >>>> >>>> >>>> Any suggestions? >>>> >>>> >>> Oh yes and of course I've already looked for accounts with any non-utf8 >>> chars in any of the output of an ldapsearch of the same ldap tree I'm >>> trying to import from... >> >> This came up yesterday internally too. I don't believe a bug or ticket >> has been filed yet. >> >> My best guess on what is happening, based on what I saw with our own >> case, is this: >> >> A migrated attribute is coming in that IPA doesn't know about. We >> default to treating all attributes that don't require special >> treatment (like binary values) as utf-8. I'm guessing that an unknown >> binary attribute is being migrated, we try to utf-8 encode it and >> kablooey. >> >> There is no easy workaround for the above problem right now because >> that happens before the --ignore* options are considered. >> >> One idea that has come to mind but is untested is to grab the missing >> schema in the form of a discrete 389-ds-compatible schema file. Stop >> dirsrv, drop the file into /etc/dirsrv/slapd-YOURINSTANCE/schema, >> start dirsrv >> >> Then retry the migration. >> >> Use --ignore* if you don't want/need these attributes, then you stop >> dirsrv, remove the schema file, start dirsrv. >> > > I did use the ignore flags, ended up with: > --user-ignore-attribute=memberOf,mail,telephoneNumber,userPassword > --user-ignore-objectclass=organizationalPerson,posixAccount,shadowAccount,inetOrgPerson,organizationalPerson > > > Still no luck, same error. > > According to your testing: is there still some value that should have > been ignored I've overlooked ? > > On the other hand, I've only been looking at entries within the ou's > that contains users and groups. Will this issue also occur if there is > non-UTF8 chars in other parts of the directory? Like I said, this error is triggered before ignore is evaluated so if an unknown binary attribute is getting decoded it will cause this failure. The only solutions we have right now is to either load the schema into IPA temporarily for the migration, rremove it on the remote side or you could modify the query we make to find the remote entries to pull only certain attributes. This last one would be tricky to get right. The code looks like: (entries, truncated) = ds_ldap.find_entries( search_filter, ['*'], search_bases[ldap_obj_name], ds_ldap.SCOPE_ONELEVEL, time_limit=0, size_limit=-1, search_refs=True # migrated DS may contain search references ) You'd want to replace ['*'] with ['attr1','attr2','attr3',...]. It would be a rather long list and would need to cover both users and groups. rob From simo at redhat.com Mon Jan 30 14:23:02 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 30 Jan 2012 09:23:02 -0500 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <4F26A3EA.7080101@redhat.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> <4F22DBBE.10502@nixtra.com> <4F22E29A.9050709@nixtra.com> <4F22F00D.3000006@redhat.com> <4F22F491.3040305@nixtra.com> <4F26A3EA.7080101@redhat.com> Message-ID: <1327933382.13963.242.camel@willson.li.ssimo.org> On Mon, 2012-01-30 at 09:06 -0500, Rob Crittenden wrote: > > Like I said, this error is triggered before ignore is evaluated so > if > an unknown binary attribute is getting decoded it will cause this > failure. The only solutions we have right now is to either load the > schema into IPA temporarily for the migration, rremove it on the > remote > side or you could modify the query we make to find the remote entries > to > pull only certain attributes. This last one would be tricky to get > right. > > The code looks like: > > (entries, truncated) = ds_ldap.find_entries( > search_filter, ['*'], > search_bases[ldap_obj_name], > ds_ldap.SCOPE_ONELEVEL, > time_limit=0, size_limit=-1, > search_refs=True # migrated DS may contain > search references > ) > > You'd want to replace ['*'] with ['attr1','attr2','attr3',...]. It > would > be a rather long list and would need to cover both users and groups. > TBH I think we should turn the code around and do this by default. We have no idea how to manage extra attributes anyway so we shouldn't get them all, only get those we understand. And turn the exclusion list into an inclusion list, so that if someone wants to import more data because they added additional schema to FreeIPA they are free to do so. The current way looks brittle. Simo. -- Simo Sorce * Red Hat, Inc * New York From marco.pizzoli at gmail.com Mon Jan 30 14:47:56 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Mon, 30 Jan 2012 15:47:56 +0100 Subject: [Freeipa-users] FreeIPA 2.2 alpha or beta available somewhere? Message-ID: Hi guys, Next days I'm going to start a test deployment of FreeIPA 2.1 but the following days I'm planning to have a look on the new features FreeIPA 2.2 brings. Are you going to release a alpha/beta package anytime in the future? Thanks in advance Marco -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Mon Jan 30 15:01:53 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 30 Jan 2012 16:01:53 +0100 (CET) Subject: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD Message-ID: <22124.213.225.75.97.1327935713.squirrel@www.nixtra.com> Hi, I'm doing a pre-implementation project for a customer having RHEL 5.7 workstations with KDE as their windows manager. When using KDE at a RHEL 5.7 (or 5.8 BETA) workstation connected to a IPA 2.1.3 running at RHEL 6.2 server, sssd will crash every time I attempt to unlock the screen. To work around the issue I switch to tty1, log in as root, and restart sssd. After attempting this several times (2-5 times), I can finally unlock the screen. I have attempted to update one workstation to 5.8 beta to see if the issue was resolved there. No such luck. Is this a known issue? The log displays the following: Jan 30 15:49:16 svg118 kdesktop_lock: on 0 Jan 30 15:49:21 svg118 kernel: sssd_be[9873] general protection rip:41dc3d rsp:7fffc57c9f10 error:0 Jan 30 15:49:22 svg118 sssd[be[no.ep.corp.local]]: Starting up Jan 30 15:49:33 svg118 sssd[be[no.ep.corp.local]]: Shutting down Jan 30 15:49:33 svg118 sssd[pam]: Shutting down Jan 30 15:49:33 svg118 kcheckpass[9896]: Authentication failure for username (invoked by uid 12345) Jan 30 15:49:33 svg118 sssd[nss]: Shutting down Jan 30 15:49:33 svg118 sssd: Starting up Jan 30 15:49:34 svg118 sssd[be[no.ep.corp.local]]: Starting up Jan 30 15:49:34 svg118 sssd[nss]: Starting up Jan 30 15:49:34 svg118 sssd[pam]: Starting up Jan 30 15:49:42 svg118 kernel: sssd_be[9928] general protection rip:41dc3d rsp:7fff70baba70 error:0 Jan 30 15:49:43 svg118 sssd[be[no.ep.corp.local]]: Starting up Jan 30 15:49:52 svg118 sssd[be[no.ep.corp.local]]: Shutting down Jan 30 15:49:52 svg118 sssd[pam]: Shutting down Jan 30 15:49:52 svg118 kcheckpass[9933]: Authentication failure for username (invoked by uid 12345) Jan 30 15:49:52 svg118 sssd[nss]: Shutting down Jan 30 15:49:52 svg118 sssd: Starting up Jan 30 15:49:52 svg118 sssd[be[no.ep.corp.local]]: Starting up Jan 30 15:49:52 svg118 sssd[pam]: Starting up Jan 30 15:49:52 svg118 sssd[nss]: Starting up Jan 30 15:49:59 svg118 kernel: sssd_be[9985] general protection rip:41dc3d rsp:7fff40912260 error:0 Rgds, Siggi From sgallagh at redhat.com Mon Jan 30 15:11:26 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 30 Jan 2012 10:11:26 -0500 Subject: [Freeipa-users] Fedora 16 client not getting group names In-Reply-To: References: <1327679297.2131.49.camel@sgallagh520.sgallagh.bos.redhat.com> <20120127165717.GD12744@hendrix.redhat.com> <1327688271.2131.53.camel@sgallagh520.sgallagh.bos.redhat.com> <1327929583.2240.5.camel@sgallagh520.sgallagh.bos.redhat.com> <1327934761.2240.19.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <1327936286.2240.24.camel@sgallagh520.sgallagh.bos.redhat.com> On Mon, 2012-01-30 at 10:02 -0500, Dan Scott wrote: > On Mon, Jan 30, 2012 at 09:46, Stephen Gallagher wrote: > > On Mon, 2012-01-30 at 09:41 -0500, Dan Scott wrote: > >> Hi, > >> > >> On Mon, Jan 30, 2012 at 08:19, Stephen Gallagher wrote: > >> > On Fri, 2012-01-27 at 15:00 -0500, Dan Scott wrote: > >> >> On Fri, Jan 27, 2012 at 13:17, Stephen Gallagher wrote: > >> >> > On Fri, 2012-01-27 at 17:57 +0100, Jakub Hrozek wrote: > >> >> >> On Fri, Jan 27, 2012 at 11:47:01AM -0500, Dan Scott wrote: > >> >> >> > Hi, > >> >> >> > > >> >> >> > On Fri, Jan 27, 2012 at 10:48, Stephen Gallagher wrote: > >> >> >> > > On Fri, 2012-01-27 at 10:36 -0500, Dan Scott wrote: > >> >> >> > >> Hi, > >> >> >> > >> > >> >> >> > >> I have a Fedora 16 client running sssd-client-1.6.4-1.fc16.x86_64. > >> >> >> > >> > >> >> >> > >> When I run, e.g. id djscott, I do not get the names of the groups: > >> >> >> > >> > >> >> >> > >> -bash-4.2$ id djscott > >> >> >> > >> uid=768(djscott) gid=1002(legacy-group) > >> >> >> > >> groups=1002(legacy-group),1134,1130,1118,1103,1108,1113,789600001(ipausers),1102,1109,1129,1111 > >> >> >> > >> > >> >> >> > >> Is this because they have low GIDs? (These were migrated over from my > >> >> >> > >> old FreeIPA 1 installation and I'd rather not re-number them all). > >> >> >> > >> > >> >> >> > >> Can someone help me to figure out how to retrieve the group names? > >> >> >> > >> This is working fine on the Fedora 15 clients (sssd-1.5.x). > >> >> >> > > > >> >> >> > > > >> >> >> > > This looks to me like you didn't migrate all of the groups. GIF 1002 and > >> >> >> > > 789600001 are both reporting the names correctly, so clearly the client > >> >> >> > > is able to access the FreeIPA server and retrieve groups. > >> >> >> > > >> >> >> > It's working fine with Fedora 15 clients, so I think that the groups > >> >> >> > were migrated OK. > >> >> >> > > >> >> >> > > Please try the following and report the results: > >> >> >> > > > >> >> >> > > getent group 1134 > >> >> >> > > > >> >> >> > > and also > >> >> >> > > getent group > >> >> >> > > > >> >> >> > > where is the name that is SUPPOSED to match GID 1134. > >> >> >> > > >> >> >> > I've just realised that once I've manually looked up the group using > >> >> >> > the name, the id command is 'fixed': > >> >> >> > > >> >> >> > [root at newton ~]# getent group 1134 > >> >> >> > [root at newton ~]# getent group svn-wfdb-swig-matlab > >> >> >> > svn-wfdb-swig-matlab:*:1134:ikaro,djscott > >> >> >> > [root at newton ~]# getent group 1134 > >> >> >> > svn-wfdb-swig-matlab:*:1134:ikaro,djscott > >> >> >> > [root at newton ~]# id djscott > >> >> >> > uid=768(djscott) gid=1002(legacy-group) > >> >> >> > groups=1002(legacy-group),1134(svn-wfdb-swig-matlab),1130,1118,1103,1108,1113,789600001(ipausers),1102,1109,1129,1111 > >> >> >> > > >> >> >> > The initial getent returned no data. But the group info seems OK once > >> >> >> > I've done one lookup. > >> >> >> > > >> >> >> > >> >> >> That's weird, id runs getgrgid() on each of the returned group GIDs > >> >> >> > >> >> > > >> >> > I know what's going on here. It was a stupid glibc screw-up in Fedora > >> >> > 16. Remove the line starting with "initgroups: " from > >> >> > your /etc/nsswitch.conf file. > >> >> > > >> >> > See https://bugzilla.redhat.com/show_bug.cgi?id=751450 for more details. > >> >> > >> >> Thanks for the info, but I don't have that line in my nsswitch.conf > >> >> file. These servers were upgraded from F15, and I can see the line in > >> >> the /etc/nsswitch.conf.rpmnew files. > >> >> > >> >> Clearing the SSSD cache doesn't seem to have helped. I'm still getting > >> >> the same problem. It's even reverted back to the original list of IDs. > >> >> Only my primary group and 'ipausers' (the only one in the high ID > >> >> range) show up properly. > >> >> > >> >> Thanks, > >> >> > >> >> Dan > >> > > >> > Are you running nscd by any chance? That could be interacting poorly. > >> > >> Nope, nscd isn't running. > >> > >> > Other than that, could you please set debug_level = 7 in your > >> > [domain/DOMAINNAME] section of /etc/sssd/sssd.conf and restart SSSD? > >> > Then try the 'id' command again and take a look > >> > at /var/log/sssd/sssd_DOMAINNAME.log > >> > >> Log file is attached (email only to you, not the list). Possibly a > >> problem with the keytab? > >> > >> Thanks, > >> > >> Dan (Mon Jan 30 09:59:46 2012) [sssd[be[DOMAIN]]] [sdap_get_generic_ext_done] (6): Search result: Server is unwilling to perform(53), Simple Paged Results Search already in progress on this connection (Mon Jan 30 09:59:46 2012) [sssd[be[DOMAIN]]] [sdap_get_generic_ext_done] (2): Unexpected result from ldap: Server is unwilling to perform(53), Simple Paged Results Search already in progress on this connection You're hitting a 389 DS bug: https://fedorahosted.org/389/ticket/260 Re-adding the list (not including private data). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sgallagh at redhat.com Mon Jan 30 15:20:47 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 30 Jan 2012 10:20:47 -0500 Subject: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD In-Reply-To: <22124.213.225.75.97.1327935713.squirrel@www.nixtra.com> References: <22124.213.225.75.97.1327935713.squirrel@www.nixtra.com> Message-ID: <1327936847.2240.25.camel@sgallagh520.sgallagh.bos.redhat.com> On Mon, 2012-01-30 at 16:01 +0100, Sigbjorn Lie wrote: > Hi, > > I'm doing a pre-implementation project for a customer having RHEL 5.7 workstations with KDE as > their windows manager. > > When using KDE at a RHEL 5.7 (or 5.8 BETA) workstation connected to a IPA 2.1.3 running at RHEL > 6.2 server, sssd will crash every time I attempt to unlock the screen. > > To work around the issue I switch to tty1, log in as root, and restart sssd. After attempting this > several times (2-5 times), I can finally unlock the screen. I have attempted to update one > workstation to 5.8 beta to see if the issue was resolved there. No such luck. > > Is this a known issue? > > > The log displays the following: > > Jan 30 15:49:16 svg118 kdesktop_lock: on 0 > Jan 30 15:49:21 svg118 kernel: sssd_be[9873] general protection rip:41dc3d rsp:7fffc57c9f10 error:0 > Jan 30 15:49:22 svg118 sssd[be[no.ep.corp.local]]: Starting up > Jan 30 15:49:33 svg118 sssd[be[no.ep.corp.local]]: Shutting down > Jan 30 15:49:33 svg118 sssd[pam]: Shutting down > Jan 30 15:49:33 svg118 kcheckpass[9896]: Authentication failure for username (invoked by uid 12345) > Jan 30 15:49:33 svg118 sssd[nss]: Shutting down > Jan 30 15:49:33 svg118 sssd: Starting up > Jan 30 15:49:34 svg118 sssd[be[no.ep.corp.local]]: Starting up > Jan 30 15:49:34 svg118 sssd[nss]: Starting up > Jan 30 15:49:34 svg118 sssd[pam]: Starting up > Jan 30 15:49:42 svg118 kernel: sssd_be[9928] general protection rip:41dc3d rsp:7fff70baba70 error:0 > Jan 30 15:49:43 svg118 sssd[be[no.ep.corp.local]]: Starting up > Jan 30 15:49:52 svg118 sssd[be[no.ep.corp.local]]: Shutting down > Jan 30 15:49:52 svg118 sssd[pam]: Shutting down > Jan 30 15:49:52 svg118 kcheckpass[9933]: Authentication failure for username (invoked by uid 12345) > Jan 30 15:49:52 svg118 sssd[nss]: Shutting down > Jan 30 15:49:52 svg118 sssd: Starting up > Jan 30 15:49:52 svg118 sssd[be[no.ep.corp.local]]: Starting up > Jan 30 15:49:52 svg118 sssd[pam]: Starting up > Jan 30 15:49:52 svg118 sssd[nss]: Starting up > Jan 30 15:49:59 svg118 kernel: sssd_be[9985] general protection rip:41dc3d rsp:7fff40912260 error:0 > Definitely not a known issue. Do you think you could attach gdb to the sssd_be process and try to get a backtrace for me to look at, please? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From dpal at redhat.com Mon Jan 30 15:53:42 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 30 Jan 2012 10:53:42 -0500 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <1327933382.13963.242.camel@willson.li.ssimo.org> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> <4F22DBBE.10502@nixtra.com> <4F22E29A.9050709@nixtra.com> <4F22F00D.3000006@redhat.com> <4F22F491.3040305@nixtra.com> <4F26A3EA.7080101@redhat.com> <1327933382.13963.242.camel@willson.li.ssimo.org> Message-ID: <4F26BD06.8020303@redhat.com> On 01/30/2012 09:23 AM, Simo Sorce wrote: > On Mon, 2012-01-30 at 09:06 -0500, Rob Crittenden wrote: >> Like I said, this error is triggered before ignore is evaluated so >> if >> an unknown binary attribute is getting decoded it will cause this >> failure. The only solutions we have right now is to either load the >> schema into IPA temporarily for the migration, rremove it on the >> remote >> side or you could modify the query we make to find the remote entries >> to >> pull only certain attributes. This last one would be tricky to get >> right. >> >> The code looks like: >> >> (entries, truncated) = ds_ldap.find_entries( >> search_filter, ['*'], >> search_bases[ldap_obj_name], >> ds_ldap.SCOPE_ONELEVEL, >> time_limit=0, size_limit=-1, >> search_refs=True # migrated DS may contain >> search references >> ) >> >> You'd want to replace ['*'] with ['attr1','attr2','attr3',...]. It >> would >> be a rather long list and would need to cover both users and groups. >> > TBH I think we should turn the code around and do this by default. > We have no idea how to manage extra attributes anyway so we shouldn't > get them all, only get those we understand. And turn the exclusion list > into an inclusion list, so that if someone wants to import more data > because they added additional schema to FreeIPA they are free to do so. > The current way looks brittle. > > Simo. > Agree, we need to open a BZ and ticket on this one. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon Jan 30 15:54:35 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 10:54:35 -0500 Subject: [Freeipa-users] unable to install or uninstall ipa In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CB7A1BF@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CB7A19E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E404CB7A1BF@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F26BD3B.3070504@redhat.com> Steven Jones wrote: > Example of install failure messages, > > ====== > Warning: skipping DNS resolution of host vuwunicoipam001.unix.vuw.ac.nz > The IPA Master Server will be configured with > Hostname: vuwunicoipam001.unix.vuw.ac.nz > IP address: 10.70.3.10 > Domain name: unix.vuw.ac.nz > > > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > Configuring ntpd > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > done configuring ntpd. > Configuring directory server: Estimated time 1 minute > [1/35]: creating directory server user > [2/35]: creating directory server instance > [3/35]: adding default schema > [4/35]: enabling memberof plugin > root : CRITICAL Failed to load memberof-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/memberof-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpkbE724' returned non-zero exit status 255 > [5/35]: enabling referential integrity plugin > root : CRITICAL Failed to load referint-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/referint-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpExKKnk' returned non-zero exit status 255 > [6/35]: enabling winsync plugin > root : CRITICAL Failed to load ipa-winsync-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/ipa-winsync-conf.ldif -x -D cn=Directory Manager -y /tmp/tmppChSx9' returned non-zero exit status 255 > [7/35]: configuring replication version plugin > root : CRITICAL Failed to load version-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/version-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpqy9Fkp' returned non-zero exit status 255 > [8/35]: enabling IPA enrollment plugin > root : CRITICAL Failed to load enrollment-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpoWPpcO -x -D cn=Directory Manager -y /tmp/tmpxbRGyx' returned non-zero exit status 255 > [9/35]: enabling ldapi > root : CRITICAL Failed to load ldapi.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpVSJoE2 -x -D cn=Directory Manager -y /tmp/tmpqsK_aD' returned non-zero exit status 255 > [10/35]: configuring uniqueness plugin > root : CRITICAL Failed to load unique-attributes.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpWJEh76 -x -D cn=Directory Manager -y /tmp/tmpzxvY9u' returned non-zero exit status 255 > [11/35]: configuring uuid plugin > root : CRITICAL Failed to load uuid-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/uuid-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpdYNh2T' returned non-zero exit status 255 > root : CRITICAL Failed to load uuid-ipauniqueid.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpkEOmk2 -x -D cn=Directory Manager -y /tmp/tmp9ZDoXY' returned non-zero exit status 255 > [12/35]: configuring modrdn plugin > root : CRITICAL Failed to load modrdn-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/modrdn-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpofFRs8' returned non-zero exit status 255 > root : CRITICAL Failed to load modrdn-krbprinc.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpDxRP25 -x -D cn=Directory Manager -y /tmp/tmpUexNQN' returned non-zero exit status 255 > [13/35]: enabling entryUSN plugin > root : CRITICAL Failed to load entryusn.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/entryusn.ldif -x -D cn=Directory Manager -y /tmp/tmpgsBw1B' returned non-zero exit status 255 > ========= > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] > Sent: Monday, 30 January 2012 2:03 p.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] unable to install or uninstall ipa > > I have a failed install with lots of critical failures... > > :( > > When I try to re-install it says its installed but when I try to --uninstall it will not..... > > How do I clean it up manually? > > ======== > [root at vuwunicoipam001 ~]# ipa-server-install --uninstall > > This is a NON REVERSIBLE operation and will delete all data and configuration! > > Are you sure you want to continue with the uninstall procedure? [no]: yes > Shutting down all IPA services > Removing IPA client configuration > Unconfiguring directory server > Unexpected error - see ipaserver-uninstall.log for details: > [Errno 2] No such file or directory: '/etc/dirsrv/slapd-UNIX-VUW-AC-NZ' > [root at vuwunicoipam001 ~]# > ======== To clean it up look at the files in /var/lib/ipa/sysrestore. There you'll find files that were backed up, a state file indicating the initial state when the installer started and an index file which accounts for all the backup files. You can remove [dirsrv] from the state file perhaps but be sure the instance really is gone. It is safe to re-run the uninstaller multiple times and sometimes this is required to get everything cleaned up on some kinds of failures. The problem is that the 389-ds isn't starting up for some reason. You may find the reason why in /var/log/ipaserver-install.log or the 389-ds logs. rob From dpal at redhat.com Mon Jan 30 15:55:53 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 30 Jan 2012 10:55:53 -0500 Subject: [Freeipa-users] FreeIPA 2.2 alpha or beta available somewhere? In-Reply-To: References: Message-ID: <4F26BD89.1010401@redhat.com> On 01/30/2012 09:47 AM, Marco Pizzoli wrote: > Hi guys, > Next days I'm going to start a test deployment of FreeIPA 2.1 but the > following days I'm planning to have a look on the new features FreeIPA > 2.2 brings. > > Are you going to release a alpha/beta package anytime in the future? > > Thanks in advance > Marco > > -- > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Yes alpha is planned for next couple weeks. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Jan 30 15:56:15 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 10:56:15 -0500 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <4F26BD06.8020303@redhat.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> <4F22DBBE.10502@nixtra.com> <4F22E29A.9050709@nixtra.com> <4F22F00D.3000006@redhat.com> <4F22F491.3040305@nixtra.com> <4F26A3EA.7080101@redhat.com> <1327933382.13963.242.camel@willson.li.ssimo.org> <4F26BD06.8020303@redhat.com> Message-ID: <4F26BD9F.4030203@redhat.com> Dmitri Pal wrote: > On 01/30/2012 09:23 AM, Simo Sorce wrote: >> On Mon, 2012-01-30 at 09:06 -0500, Rob Crittenden wrote: >>> Like I said, this error is triggered before ignore is evaluated so >>> if >>> an unknown binary attribute is getting decoded it will cause this >>> failure. The only solutions we have right now is to either load the >>> schema into IPA temporarily for the migration, rremove it on the >>> remote >>> side or you could modify the query we make to find the remote entries >>> to >>> pull only certain attributes. This last one would be tricky to get >>> right. >>> >>> The code looks like: >>> >>> (entries, truncated) = ds_ldap.find_entries( >>> search_filter, ['*'], >>> search_bases[ldap_obj_name], >>> ds_ldap.SCOPE_ONELEVEL, >>> time_limit=0, size_limit=-1, >>> search_refs=True # migrated DS may contain >>> search references >>> ) >>> >>> You'd want to replace ['*'] with ['attr1','attr2','attr3',...]. It >>> would >>> be a rather long list and would need to cover both users and groups. >>> >> TBH I think we should turn the code around and do this by default. >> We have no idea how to manage extra attributes anyway so we shouldn't >> get them all, only get those we understand. And turn the exclusion list >> into an inclusion list, so that if someone wants to import more data >> because they added additional schema to FreeIPA they are free to do so. >> The current way looks brittle. >> >> Simo. >> > Agree, we need to open a BZ and ticket on this one. > Oh I don't know. The reason we did it this way was to specifically put into the user's face those attributes that aren't being migrated. This way we don't find out much after the fact that some things weren't migrated properly forcing them to re-migrate. I'd certainly rather have a little pain at the beginning of the process and know I have everything I need rather than days/weeks/months later and realize something important was missed. rob From dpal at redhat.com Mon Jan 30 16:00:14 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 30 Jan 2012 11:00:14 -0500 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <4F26BD9F.4030203@redhat.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> <4F22DBBE.10502@nixtra.com> <4F22E29A.9050709@nixtra.com> <4F22F00D.3000006@redhat.com> <4F22F491.3040305@nixtra.com> <4F26A3EA.7080101@redhat.com> <1327933382.13963.242.camel@willson.li.ssimo.org> <4F26BD06.8020303@redhat.com> <4F26BD9F.4030203@redhat.com> Message-ID: <4F26BE8E.9050906@redhat.com> On 01/30/2012 10:56 AM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 01/30/2012 09:23 AM, Simo Sorce wrote: >>> On Mon, 2012-01-30 at 09:06 -0500, Rob Crittenden wrote: >>>> Like I said, this error is triggered before ignore is evaluated so >>>> if >>>> an unknown binary attribute is getting decoded it will cause this >>>> failure. The only solutions we have right now is to either load the >>>> schema into IPA temporarily for the migration, rremove it on the >>>> remote >>>> side or you could modify the query we make to find the remote entries >>>> to >>>> pull only certain attributes. This last one would be tricky to get >>>> right. >>>> >>>> The code looks like: >>>> >>>> (entries, truncated) = ds_ldap.find_entries( >>>> search_filter, ['*'], >>>> search_bases[ldap_obj_name], >>>> ds_ldap.SCOPE_ONELEVEL, >>>> time_limit=0, size_limit=-1, >>>> search_refs=True # migrated DS may contain >>>> search references >>>> ) >>>> >>>> You'd want to replace ['*'] with ['attr1','attr2','attr3',...]. It >>>> would >>>> be a rather long list and would need to cover both users and groups. >>>> >>> TBH I think we should turn the code around and do this by default. >>> We have no idea how to manage extra attributes anyway so we shouldn't >>> get them all, only get those we understand. And turn the exclusion list >>> into an inclusion list, so that if someone wants to import more data >>> because they added additional schema to FreeIPA they are free to do so. >>> The current way looks brittle. >>> >>> Simo. >>> >> Agree, we need to open a BZ and ticket on this one. >> > > Oh I don't know. The reason we did it this way was to specifically put > into the user's face those attributes that aren't being migrated. This > way we don't find out much after the fact that some things weren't > migrated properly forcing them to re-migrate. I'd certainly rather > have a little pain at the beginning of the process and know I have > everything I need rather than days/weeks/months later and realize > something important was missed. > > rob May be we should have a dry run option then or something like migrate-ds-test that will return two lists: List of all attributes detected and the list of attributes that we actually can migrate. For the ones we can't migrate we should explain why. Then migrate-ds should accept the second list as an input overriding the default "*". How about that? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Mon Jan 30 16:01:46 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 30 Jan 2012 11:01:46 -0500 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <4F26BD9F.4030203@redhat.com> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> <4F22DBBE.10502@nixtra.com> <4F22E29A.9050709@nixtra.com> <4F22F00D.3000006@redhat.com> <4F22F491.3040305@nixtra.com> <4F26A3EA.7080101@redhat.com> <1327933382.13963.242.camel@willson.li.ssimo.org> <4F26BD06.8020303@redhat.com> <4F26BD9F.4030203@redhat.com> Message-ID: <1327939306.13963.246.camel@willson.li.ssimo.org> On Mon, 2012-01-30 at 10:56 -0500, Rob Crittenden wrote: > Dmitri Pal wrote: > > On 01/30/2012 09:23 AM, Simo Sorce wrote: > >> On Mon, 2012-01-30 at 09:06 -0500, Rob Crittenden wrote: > >>> Like I said, this error is triggered before ignore is evaluated so > >>> if > >>> an unknown binary attribute is getting decoded it will cause this > >>> failure. The only solutions we have right now is to either load the > >>> schema into IPA temporarily for the migration, rremove it on the > >>> remote > >>> side or you could modify the query we make to find the remote entries > >>> to > >>> pull only certain attributes. This last one would be tricky to get > >>> right. > >>> > >>> The code looks like: > >>> > >>> (entries, truncated) = ds_ldap.find_entries( > >>> search_filter, ['*'], > >>> search_bases[ldap_obj_name], > >>> ds_ldap.SCOPE_ONELEVEL, > >>> time_limit=0, size_limit=-1, > >>> search_refs=True # migrated DS may contain > >>> search references > >>> ) > >>> > >>> You'd want to replace ['*'] with ['attr1','attr2','attr3',...]. It > >>> would > >>> be a rather long list and would need to cover both users and groups. > >>> > >> TBH I think we should turn the code around and do this by default. > >> We have no idea how to manage extra attributes anyway so we shouldn't > >> get them all, only get those we understand. And turn the exclusion list > >> into an inclusion list, so that if someone wants to import more data > >> because they added additional schema to FreeIPA they are free to do so. > >> The current way looks brittle. > >> > >> Simo. > >> > > Agree, we need to open a BZ and ticket on this one. > > > > Oh I don't know. The reason we did it this way was to specifically put > into the user's face those attributes that aren't being migrated. This > way we don't find out much after the fact that some things weren't > migrated properly forcing them to re-migrate. I'd certainly rather have > a little pain at the beginning of the process and know I have everything > I need rather than days/weeks/months later and realize something > important was missed. I understand the intent, but I think the current method causes more pain then necessary. If admins have important data they want to preserve they better explicitly include it in the import list. And check the data was properly imported. I do not think we need to make life of good admins difficult in order to try to salvage bad admins that do not even check the migration imported all data they needed. Simo. -- Simo Sorce * Red Hat, Inc * New York From dale at themacartneyclan.com Mon Jan 30 16:42:19 2012 From: dale at themacartneyclan.com (Dale Macartney) Date: Mon, 30 Jan 2012 16:42:19 +0000 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F269F43.40607@redhat.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> Message-ID: <4F26C86B.6040700@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Of course Dmitri Here you go. I was actually trying to resolve this for an automated kickstart process anyway. The details specific to dovecot are in the middle. # Connect server to IPA domain (ensure DNS is working correctly otherwise this step will fail) ipa-client-install -U -p admin -w mysecretpassword # install postfix if necessary (installed by default in rhel6) yum -y install postfix # set postfix to start on boot chkconfig postfix on # configure postfix with hostname, domain and origin details sed -i 's/#myhostname = host.domain.tld/myhostname = servername.example.com/g' /etc/postfix/main.cf sed -i 's/#mydomain = domain.tld/mydomain = example.com/g' /etc/postfix/main.cf sed -i 's/#myorigin = $mydomain/myorigin = $mydomain/g' /etc/postfix/main.cf # configure postfix to listen on all interfaces sed -i 's/#inet_interfaces = all/inet_interfaces = all/g' /etc/postfix/main.cf sed -i 's/inet_interfaces = localhost/#inet_interfaces = localhost/g' /etc/postfix/main.cf # apply postfix changes service postfix restart # Install dovecot yum -y install dovecot # set dovecot to start on boot chkconfig dovecot on # set dovecot to listen on imap and imaps only sed -i 's/#protocols = imap pop3 lmtp/protocols = imap imaps/g' /etc/dovecot/dovecot.conf # point dovecot to required mailbox directory (This is the section that was previously failing) echo "mail_location = mbox:~/mail:INBOX=/var/mail/%u" >> /etc/dovecot/dovecot.conf # reload dovecot to apply changes service dovecot restart # Apply working IPtables cat > /etc/sysconfig/iptables << EOF # Generated by iptables-save v1.4.7 on Tue Jan 10 12:17:41 2012 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [29:4596] - - -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT - - -A INPUT -p tcp -m tcp --dport 143 -j ACCEPT - - -A INPUT -p tcp -m tcp --dport 993 -j ACCEPT - - -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT - - -A INPUT -p icmp -j ACCEPT - - -A INPUT -i lo -j ACCEPT - - -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT - - -A INPUT -j REJECT --reject-with icmp-host-prohibited - - -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT # Completed on Tue Jan 10 12:17:41 2012 EOF With the above details, I am able to replicate a 100% working IPA authenticated mail server, allowing IPA users to retrieve mail via imap/imaps. I hope this helps. Dale On 01/30/2012 01:46 PM, Dmitri Pal wrote: - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPJshWAAoJEAJsWS61tB+qN48P/RR7qGHnLAmfRT4dWm8b/fHp C4oC/PtYmlw4CXxUh2ILfnnMTuGAD9sJMWHC0NGqdvKF9j/+ahcdaDg1KJmZ2JxH C4OQKsBj5sBPcicJQIBVUzU77VbZR5ZVXidc1ixLaLETXnz48OhQy9SYu8IbuxIE V1LJKRltJQ54CthD7xExkofiuxDQr++4IMF8WSMtApDexemrGiQtP/bfmVn2oszN xypkaFyNk8n4oUznd8QncSo2PukxVL1Is3q+hnWwyMsQrIP0xlhVbF3YfeLmTMNv yHh41ehS2GwmXJguYAe/dnpxHkxqXzmGBjN3lYxekfFfeUlfrxPZCVC/S9J9lrwX rgqZFiqKdrBFINmwfqeN2MAzLggcc7sxK5cwBv9dw1wUeJxhm0junFEymrYXER3s +Ps4UlJmH4Hts0bDomQDZ3d7Cxf2V8JtXm1ux4HkEkiVA1cUkuvvqkmcEie1XhAH nNC7tVnJg3xYm5lTvC6WV9R9lxOWq+w4O1saJfjkqpNaqB/shoZCMv+JOQGPcaKm SCsbOrMtUITq4jjDo84I/LLaZg3LF91aPZSfs9lJIECh3GV1+rG70X3DtjWQ9ucq vlKG4GHRvdcTzCsb9/HOCM3aFsLOt5eb3/WQBvSWZ860xNDS6Gcd92OLkW8zainu idEItJm/ii0j+wwW6aiT =NvTn - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPJshlAAoJEAJsWS61tB+qcQ4P/0E6l25FfCuMk1RQdbqTf0Ys MYjhkNGPl8hJrO+wAFE4+Lp1OIMVeH/r489EMVBvnbzsaT1tPPsVsLzsNC8Nt+am uVsgdc1icYmy1NG0Sj9U70whSLksAKL9zT0ijufgDFT0J59qLCgTmc+uW2cI23Z3 6tqx5NiJ3zYlc1Ckm7biu4wwAk/jaPFBPuONEDAuxgBgsaDCNg9xacqauFbEe4Nb YqTA9UnayeJ6Elrdea3ouKCqjztyFPkcaMxj+JTdBrLbSjXdzkF08KtuZETaEZ6g Gq2QhNC3REkY1xfo5MMCKbhRym/uFW8txmh8saTABRIWcPoqndKOtpe+LB04Ui4A qG9KdfCwAbJHIYYe/OpOVM01weMvwz92U7oZlfxDXPl3rq0Mr0uaijtZRMZjCCdI QPyB+DZV76J2o9+YGWH5B+pZWE99BJPg25B9dv9uu92Kp6TTi8B2v2vetMytgeoQ lzocLTfWF1E3oK95SmuvErvfOYwwDLeHN9qwiLBusbT5v5xpWijbvwBCoHDo+LqZ lEQl2QreP97tsV58JHqbt6EyzdYRWQKeQcJhDo7W5TSAejs+dKdeo9i+8Ud6c8HD DtzQ4iIQ6vferd856WLheLe0Sv+GE2+IQ1YG5avelxmx+KaRkf+WdYWbslNxnoIr CkN/3WFB2nxPogrSYGGN =GcOl -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 5790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From dale at themacartneyclan.com Mon Jan 30 16:42:07 2012 From: dale at themacartneyclan.com (Dale Macartney) Date: Mon, 30 Jan 2012 16:42:07 +0000 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F269F43.40607@redhat.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> Message-ID: <4F26C85F.1020502@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Of course Dmitri Here you go. I was actually trying to resolve this for an automated kickstart process anyway. The details specific to dovecot are in the middle. # Connect server to IPA domain (ensure DNS is working correctly otherwise this step will fail) ipa-client-install -U -p admin -w mysecretpassword # install postfix if necessary (installed by default in rhel6) yum -y install postfix # set postfix to start on boot chkconfig postfix on # configure postfix with hostname, domain and origin details sed -i 's/#myhostname = host.domain.tld/myhostname = servername.example.com/g' /etc/postfix/main.cf sed -i 's/#mydomain = domain.tld/mydomain = example.com/g' /etc/postfix/main.cf sed -i 's/#myorigin = $mydomain/myorigin = $mydomain/g' /etc/postfix/main.cf # configure postfix to listen on all interfaces sed -i 's/#inet_interfaces = all/inet_interfaces = all/g' /etc/postfix/main.cf sed -i 's/inet_interfaces = localhost/#inet_interfaces = localhost/g' /etc/postfix/main.cf # apply postfix changes service postfix restart # Install dovecot yum -y install dovecot # set dovecot to start on boot chkconfig dovecot on # set dovecot to listen on imap and imaps only sed -i 's/#protocols = imap pop3 lmtp/protocols = imap imaps/g' /etc/dovecot/dovecot.conf # point dovecot to required mailbox directory (This is the section that was previously failing) echo "mail_location = mbox:~/mail:INBOX=/var/mail/%u" >> /etc/dovecot/dovecot.conf # reload dovecot to apply changes service dovecot restart # Apply working IPtables cat > /etc/sysconfig/iptables << EOF # Generated by iptables-save v1.4.7 on Tue Jan 10 12:17:41 2012 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [29:4596] - -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT - -A INPUT -p tcp -m tcp --dport 143 -j ACCEPT - -A INPUT -p tcp -m tcp --dport 993 -j ACCEPT - -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT - -A INPUT -p icmp -j ACCEPT - -A INPUT -i lo -j ACCEPT - -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT - -A INPUT -j REJECT --reject-with icmp-host-prohibited - -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT # Completed on Tue Jan 10 12:17:41 2012 EOF With the above details, I am able to replicate a 100% working IPA authenticated mail server, allowing IPA users to retrieve mail via imap/imaps. I hope this helps. Dale On 01/30/2012 01:46 PM, Dmitri Pal wrote: > On 01/30/2012 07:16 AM, Dale Macartney wrote: > > >> Hi all >> >> I'm working on a test lab setup at the moment with RHEL 6.2 running IPA >> 2.1 and experimenting with simple mail server setups. . >> >> I have mail being received base on pam lookups from IPA. The mail server >> is tapped into IPA via the ipa-client-install. >> >> I am using a default install of the dovecot rpm from RHN, and dovecot is >> listening via imap/imaps, however all authentication requests fail when >> attempting to login via imap.. >> >> I added the necessary keytabs for imap/mail.example.com and >> imaps/mail.example.com to /etc/krb5.keytab but this hasn't allowed >> authentication. >> >> has anyone set up dovecot through IPA before? Any recommendations? >> >> > Hi Dale, > > Will you be so kind to share with the list a little bit more details about how to setup Dovecot with IPA? If you can provide step by step instructions we would publish them on the FreeIPA wiki. > > Thank you > Dmitri > > >> thanks all >> >> Dale >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPJshWAAoJEAJsWS61tB+qN48P/RR7qGHnLAmfRT4dWm8b/fHp C4oC/PtYmlw4CXxUh2ILfnnMTuGAD9sJMWHC0NGqdvKF9j/+ahcdaDg1KJmZ2JxH C4OQKsBj5sBPcicJQIBVUzU77VbZR5ZVXidc1ixLaLETXnz48OhQy9SYu8IbuxIE V1LJKRltJQ54CthD7xExkofiuxDQr++4IMF8WSMtApDexemrGiQtP/bfmVn2oszN xypkaFyNk8n4oUznd8QncSo2PukxVL1Is3q+hnWwyMsQrIP0xlhVbF3YfeLmTMNv yHh41ehS2GwmXJguYAe/dnpxHkxqXzmGBjN3lYxekfFfeUlfrxPZCVC/S9J9lrwX rgqZFiqKdrBFINmwfqeN2MAzLggcc7sxK5cwBv9dw1wUeJxhm0junFEymrYXER3s +Ps4UlJmH4Hts0bDomQDZ3d7Cxf2V8JtXm1ux4HkEkiVA1cUkuvvqkmcEie1XhAH nNC7tVnJg3xYm5lTvC6WV9R9lxOWq+w4O1saJfjkqpNaqB/shoZCMv+JOQGPcaKm SCsbOrMtUITq4jjDo84I/LLaZg3LF91aPZSfs9lJIECh3GV1+rG70X3DtjWQ9ucq vlKG4GHRvdcTzCsb9/HOCM3aFsLOt5eb3/WQBvSWZ860xNDS6Gcd92OLkW8zainu idEItJm/ii0j+wwW6aiT =NvTn -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 5790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From sigbjorn at nixtra.com Mon Jan 30 17:00:23 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 30 Jan 2012 18:00:23 +0100 Subject: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD In-Reply-To: <1327936847.2240.25.camel@sgallagh520.sgallagh.bos.redhat.com> References: <22124.213.225.75.97.1327935713.squirrel@www.nixtra.com> <1327936847.2240.25.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: Sure. Ive left the office for today, will do so tomorrow. Im not very familiar with gdb. Any particular syntax / switches to add? Rgds, Siggi. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Stephen Gallagher wrote: On Mon, 2012-01-30 at 16:01 +0100, Sigbjorn Lie wrote: > Hi, > > I'm doing a pre-implementation project for a customer having RHEL 5.7 workstations with KDE as > their windows manager. > > When using KDE at a RHEL 5.7 (or 5.8 BETA) workstation connected to a IPA 2.1.3 running at RHEL > 6.2 server, sssd will crash every time I attempt to unlock the screen. > > To work around the issue I switch to tty1, log in as root, and restart sssd. After attempting this > several times (2-5 times), I can finally unlock the screen. I have attempted to update one > workstation to 5.8 beta to see if the issue was resolved there. No such luck. > > Is this a known issue? > > > The log displays the following: > > Jan 30 15:49:16 svg118 kdesktop_lock: on 0 > Jan 30 15:49:21 svg118 kernel: sssd_be[9873] general protection rip:41dc3d rsp:7fffc57c9f10 error:0 > Jan 30 15:49:22 svg118 sssd[be[no.ep.corp.local]]: Starting up > Jan 30 15:49:33 svg118 sssd[be[no.ep.corp.local]]: Shutting down > Jan 30 15:49:33 svg118 sssd[pam]: Shutting down > Jan 30 15:49:33 svg118 kcheckpass[9896]: Authentication failure for username (invoked by uid 12345) > Jan 30 15:49:33 svg118 sssd[nss]: Shutting down > Jan 30 15:49:33 svg118 sssd: Starting up > Jan 30 15:49:34 svg118 sssd[be[no.ep.corp.local]]: Starting up > Jan 30 15:49:34 svg118 sssd[nss]: Starting up > Jan 30 15:49:34 svg118 sssd[pam]: Starting up > Jan 30 15:49:42 svg118 kernel: sssd_be[9928] general protection rip:41dc3d rsp:7fff70baba70 error:0 > Jan 30 15:49:43 svg118 sssd[be[no.ep.corp.local]]: Starting up > Jan 30 15:49:52 svg118 sssd[be[no.ep.corp.local]]: Shutting down > Jan 30 15:49:52 svg118 sssd[pam]: Shutting down > Jan 30 15:49:52 svg118 kcheckpass[9933]: Authentication failure for username (invoked by uid 12345) > Jan 30 15:49:52 svg118 sssd[nss]: Shutting down > Jan 30 15:49:52 svg118 sssd: Starting up > Jan 30 15:49:52 svg118 sssd[be[no.ep.corp.local]]: Starting up > Jan 30 15:49:52 svg118 sssd[pam]: Starting up > Jan 30 15:49:52 svg118 sssd[nss]: Starting up > Jan 30 15:49:59 svg118 kernel: sssd_be[9985] general protection rip:41dc3d rsp:7fff40912260 error:0 > Definitely not a known issue. Do you think you could attach gdb to the sssd_be process and try to get a backtrace for me to look at, please? _____________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Jan 30 17:02:17 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 30 Jan 2012 12:02:17 -0500 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F26C86B.6040700@themacartneyclan.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C86B.6040700@themacartneyclan.com> Message-ID: <4F26CD19.4010700@redhat.com> On 01/30/2012 11:42 AM, Dale Macartney wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Of course Dmitri > > Here you go. I was actually trying to resolve this for an automated > kickstart process anyway. The details specific to dovecot are in the > middle. > > # Connect server to IPA domain (ensure DNS is working correctly > otherwise this step will fail) > ipa-client-install -U -p admin -w mysecretpassword > > # install postfix if necessary (installed by default in rhel6) > yum -y install postfix > > # set postfix to start on boot > chkconfig postfix on > > # configure postfix with hostname, domain and origin details > sed -i 's/#myhostname = host.domain.tld/myhostname = > servername.example.com/g' /etc/postfix/main.cf > sed -i 's/#mydomain = domain.tld/mydomain = example.com/g' > /etc/postfix/main.cf > sed -i 's/#myorigin = $mydomain/myorigin = $mydomain/g' > /etc/postfix/main.cf > > # configure postfix to listen on all interfaces > sed -i 's/#inet_interfaces = all/inet_interfaces = all/g' > /etc/postfix/main.cf > sed -i 's/inet_interfaces = localhost/#inet_interfaces = localhost/g' > /etc/postfix/main.cf > > # apply postfix changes > service postfix restart > > # Install dovecot > yum -y install dovecot > > # set dovecot to start on boot > chkconfig dovecot on > > # set dovecot to listen on imap and imaps only > sed -i 's/#protocols = imap pop3 lmtp/protocols = imap imaps/g' > /etc/dovecot/dovecot.conf > > # point dovecot to required mailbox directory (This is the section > that was previously failing) > echo "mail_location = mbox:~/mail:INBOX=/var/mail/%u" >> > /etc/dovecot/dovecot.conf > > # reload dovecot to apply changes > service dovecot restart > > # Apply working IPtables > cat > /etc/sysconfig/iptables << EOF > # Generated by iptables-save v1.4.7 on Tue Jan 10 12:17:41 2012 > *filter > :INPUT ACCEPT [0:0] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [29:4596] > - -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT > - -A INPUT -p tcp -m tcp --dport 143 -j ACCEPT > - -A INPUT -p tcp -m tcp --dport 993 -j ACCEPT > - -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT > - -A INPUT -p icmp -j ACCEPT > - -A INPUT -i lo -j ACCEPT > - -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT > - -A INPUT -j REJECT --reject-with icmp-host-prohibited > - -A FORWARD -j REJECT --reject-with icmp-host-prohibited > COMMIT > # Completed on Tue Jan 10 12:17:41 2012 > EOF > > With the above details, I am able to replicate a 100% working IPA > authenticated mail server, allowing IPA users to retrieve mail via > imap/imaps. > > I hope this helps. > A lot! Thanks! http://freeipa.org/page/Dovecot_Integration > > Dale > > > > On 01/30/2012 01:46 PM, Dmitri Pal wrote: > > - _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Mon Jan 30 17:05:26 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 30 Jan 2012 18:05:26 +0100 Subject: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available In-Reply-To: <1327939306.13963.246.camel@willson.li.ssimo.org> References: <59461.81.166.38.135.1327673483.squirrel@www.nixtra.com> <1327673832.2131.47.camel@sgallagh520.sgallagh.bos.redhat.com> <4F22B6B4.5040502@redhat.com> <36455.81.166.38.135.1327675824.squirrel@www.nixtra.com> <4F22BAFF.5000100@redhat.com> <4F22DBBE.10502@nixtra.com> <4F22E29A.9050709@nixtra.com> <4F22F00D.3000006@redhat.com> <4F22F491.3040305@nixtra.com> <4F26A3EA.7080101@redhat.com> <1327933382.13963.242.camel@willson.li.ssimo.org> <4F26BD06.8020303@redhat.com> <4F26BD9F.4030203@redhat.com> <1327939306.13963.246.camel@willson.li.ssimo.org> Message-ID: <3851fbd0-73d5-4281-9c8a-a2c8856d34c2@email.android.com> I agree with Simo. As far as I understand I dont have a way around this but to change the source. Ok for me but perhaps a bit much for others... Btw, I haven't had time to test the proposed source changes. Rgds, Siggi -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Simo Sorce wrote: On Mon, 2012-01-30 at 10:56 -0500, Rob Crittenden wrote: > Dmitri Pal wrote: > > On 01/30/2012 09:23 AM, Simo Sorce wrote: > >> On Mon, 2012-01-30 at 09:06 -0500, Rob Crittenden wrote: > >>> Like I said, this error is triggered before ignore is evaluated so > >>> if > >>> an unknown binary attribute is getting decoded it will cause this > >>> failure. The only solutions we have right now is to either load the > >>> schema into IPA temporarily for the migration, rremove it on the > >>> remote > >>> side or you could modify the query we make to find the remote entries > >>> to > >>> pull only certain attributes. This last one would be tricky to get > >>> right. > >>> > >>> The code looks like: > >>> > >>> (entries, truncated) = ds_ldap.find_entries( > >>> search_filter, ['*'], > >>> search_bases[ldap_obj_name], > >>> ds_ldap.SCOPE_ONELEVEL, > >>> time_limit=0, size_limit=-1, > >>> search_refs=True # migrated DS may contain > >>> search references > >>> ) > >>> > >>> You'd want to replace ['*'] with ['attr1','attr2','attr3',...]. It > >>> would > >>> be a rather long list and would need to cover both users and groups. > >>> > >> TBH I think we should turn the code around and do this by default. > >> We have no idea how to manage extra attributes anyway so we shouldn't > >> get them all, only get those we understand. And turn the exclusion list > >> into an inclusion list, so that if someone wants to import more data > >> because they added additional schema to FreeIPA they are free to do so. > >> The current way looks brittle. > >> > >> Simo. > >> > > Agree, we need to open a BZ and ticket on this one. > > > > Oh I don't know. The reason we did it this way was to specifically put > into the user's face those attributes that aren't being migrated. This > way we don't find out much after the fact that some things weren't > migrated properly forcing them to re-migrate. I'd certainly rather have > a little pain at the beginning of the process and know I have everything > I need rather than days/weeks/months later and realize something > important was missed. I understand the intent, but I think the current method causes more pain then necessary. If admins have important data they want to preserve they better explicitly include it in the import list. And check the data was properly imported. I do not think we need to make life of good admins difficult in order to try to salvage bad admins that do not even check the migration imported all data they needed. Simo. -- Simo Sorce * Red Hat, Inc * New York _____________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Mon Jan 30 17:06:14 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 30 Jan 2012 12:06:14 -0500 Subject: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD In-Reply-To: References: <22124.213.225.75.97.1327935713.squirrel@www.nixtra.com> <1327936847.2240.25.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <1327943174.2240.38.camel@sgallagh520.sgallagh.bos.redhat.com> On Mon, 2012-01-30 at 18:00 +0100, Sigbjorn Lie wrote: > Sure. Ive left the office for today, will do so tomorrow. > > Im not very familiar with gdb. Any particular syntax / switches to > add? > > Rgds, > Siggi. You'll want to do this in a non-graphical terminal, so you can switch to it if KDE gets into trouble. First, install the sssd-debuginfo packages (debuginfo-install sssd) and install gdb (yum install gdb) Then run: gdb -p ($pidof sssd_be) Then in the gdb prompt, type 'cont' (this will resume execution of sssd_be). Now, switch back to KDE and unlock the screen. Then switch back to this virtual terminal. You should be back at the prompt, with GDB telling you that you received a SIGSEGV or SIGABRT. Type "bt full" and reply with all pages of output from that (there may be multiple, requiring you to hit enter to see them). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sigbjorn at nixtra.com Mon Jan 30 17:14:32 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 30 Jan 2012 18:14:32 +0100 Subject: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD In-Reply-To: <1327943174.2240.38.camel@sgallagh520.sgallagh.bos.redhat.com> References: <22124.213.225.75.97.1327935713.squirrel@www.nixtra.com> <1327936847.2240.25.camel@sgallagh520.sgallagh.bos.redhat.com> <1327943174.2240.38.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <06f17295-6937-4ebf-a41f-f9148e642f24@email.android.com> Excellent, thank you. I will get this done tomorrow. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Stephen Gallagher wrote: On Mon, 2012-01-30 at 18:00 +0100, Sigbjorn Lie wrote: > Sure. Ive left the office for today, will do so tomorrow. > > Im not very familiar with gdb. Any particular syntax / switches to > add? > > Rgds, > Siggi. You'll want to do this in a non-graphical terminal, so you can switch to it if KDE gets into trouble. First, install the sssd-debuginfo packages (debuginfo-install sssd) and install gdb (yum install gdb) Then run: gdb -p ($pidof sssd_be) Then in the gdb prompt, type 'cont' (this will resume execution of sssd_be). Now, switch back to KDE and unlock the screen. Then switch back to this virtual terminal. You should be back at the prompt, with GDB telling you that you received a SIGSEGV or SIGABRT. Type "bt full" and reply with all pages of output from that (there may be multiple, requiring you to hit enter to see them). -------------- next part -------------- An HTML attachment was scrubbed... URL: From erinn.looneytriggs at gmail.com Mon Jan 30 19:11:07 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 30 Jan 2012 10:11:07 -0900 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F26C85F.1020502@themacartneyclan.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> Message-ID: <4F26EB4B.80209@gmail.com> On 01/30/2012 07:42 AM, Dale Macartney wrote: > > Of course Dmitri > > Here you go. I was actually trying to resolve this for an automated > kickstart process anyway. The details specific to dovecot are in the middle. > > # Connect server to IPA domain (ensure DNS is working correctly > otherwise this step will fail) > ipa-client-install -U -p admin -w mysecretpassword > > # install postfix if necessary (installed by default in rhel6) > yum -y install postfix > > # set postfix to start on boot > chkconfig postfix on > > # configure postfix with hostname, domain and origin details > sed -i 's/#myhostname = host.domain.tld/myhostname = > servername.example.com/g' /etc/postfix/main.cf > sed -i 's/#mydomain = domain.tld/mydomain = example.com/g' > /etc/postfix/main.cf > sed -i 's/#myorigin = $mydomain/myorigin = $mydomain/g' /etc/postfix/main.cf > > # configure postfix to listen on all interfaces > sed -i 's/#inet_interfaces = all/inet_interfaces = all/g' > /etc/postfix/main.cf > sed -i 's/inet_interfaces = localhost/#inet_interfaces = localhost/g' > /etc/postfix/main.cf > > # apply postfix changes > service postfix restart > > # Install dovecot > yum -y install dovecot > > # set dovecot to start on boot > chkconfig dovecot on > > # set dovecot to listen on imap and imaps only > sed -i 's/#protocols = imap pop3 lmtp/protocols = imap imaps/g' > /etc/dovecot/dovecot.conf > > # point dovecot to required mailbox directory (This is the section that > was previously failing) > echo "mail_location = mbox:~/mail:INBOX=/var/mail/%u" >> > /etc/dovecot/dovecot.conf > > # reload dovecot to apply changes > service dovecot restart > > # Apply working IPtables > cat > /etc/sysconfig/iptables << EOF > # Generated by iptables-save v1.4.7 on Tue Jan 10 12:17:41 2012 > *filter > :INPUT ACCEPT [0:0] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [29:4596] > -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT > -A INPUT -p tcp -m tcp --dport 143 -j ACCEPT > -A INPUT -p tcp -m tcp --dport 993 -j ACCEPT > -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT > -A INPUT -p icmp -j ACCEPT > -A INPUT -i lo -j ACCEPT > -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT > -A INPUT -j REJECT --reject-with icmp-host-prohibited > -A FORWARD -j REJECT --reject-with icmp-host-prohibited > COMMIT > # Completed on Tue Jan 10 12:17:41 2012 > EOF > > With the above details, I am able to replicate a 100% working IPA > authenticated mail server, allowing IPA users to retrieve mail via > imap/imaps. > > I hope this helps. > > > Dale > > > > On 01/30/2012 01:46 PM, Dmitri Pal wrote: >> On 01/30/2012 07:16 AM, Dale Macartney wrote: >> > >>> Hi all >>> >>> I'm working on a test lab setup at the moment with RHEL 6.2 running IPA >>> 2.1 and experimenting with simple mail server setups. . >>> >>> I have mail being received base on pam lookups from IPA. The mail server >>> is tapped into IPA via the ipa-client-install. >>> >>> I am using a default install of the dovecot rpm from RHN, and dovecot is >>> listening via imap/imaps, however all authentication requests fail when >>> attempting to login via imap.. >>> >>> I added the necessary keytabs for imap/mail.example.com and >>> imaps/mail.example.com to /etc/krb5.keytab but this hasn't allowed >>> authentication. >>> >>> has anyone set up dovecot through IPA before? Any recommendations? >>> >>> >> Hi Dale, > >> Will you be so kind to share with the list a little bit more details > about how to setup Dovecot with IPA? If you can provide step by step > instructions we would publish them on the FreeIPA wiki. > >> Thank you >> Dmitri > > >>> thanks all >>> >>> Dale >>> >>> > >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > >> -- >> Thank you, >> Dmitri Pal > >> Sr. Engineering Manager IPA project, >> Red Hat Inc. > > >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ > > > > > >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users So I am a bit confused here, is this working for you or not? It looked like you were asking a question to begin with, but then at then end you are saying it is 100% working? Just trying to figure out whether you need help, -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From dale at themacartneyclan.com Mon Jan 30 19:20:36 2012 From: dale at themacartneyclan.com (Dale Macartney) Date: Mon, 30 Jan 2012 19:20:36 +0000 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F26EB4B.80209@gmail.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> Message-ID: <4F26ED84.60205@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Erinn I originally asked the question as I was thinking my auth attempts were failing when using ipa, however this was not the case. On closer inspection, i found that the authentication was successful yet dovecot was failing to read a "missing" mailbox. I found that dovecot was simply missing the mailbox_location directive, detailed below. mail_location = mbox:~/mail:INBOX=/var/mail/%u Once I restarted dovecot with this extra line, the authentication was again validated. I was then prompted to accept the self-signed certificate from dovecot and I was able to retrieve the mail as intended. Does this help clear things up? Dale On 01/30/2012 07:11 PM, Erinn Looney-Triggs wrote: > On 01/30/2012 07:42 AM, Dale Macartney wrote: >> >> Of course Dmitri >> >> Here you go. I was actually trying to resolve this for an automated >> kickstart process anyway. The details specific to dovecot are in the middle. >> >> # Connect server to IPA domain (ensure DNS is working correctly >> otherwise this step will fail) >> ipa-client-install -U -p admin -w mysecretpassword >> >> # install postfix if necessary (installed by default in rhel6) >> yum -y install postfix >> >> # set postfix to start on boot >> chkconfig postfix on >> >> # configure postfix with hostname, domain and origin details >> sed -i 's/#myhostname = host.domain.tld/myhostname = >> servername.example.com/g' /etc/postfix/main.cf >> sed -i 's/#mydomain = domain.tld/mydomain = example.com/g' >> /etc/postfix/main.cf >> sed -i 's/#myorigin = $mydomain/myorigin = $mydomain/g' /etc/postfix/main.cf >> >> # configure postfix to listen on all interfaces >> sed -i 's/#inet_interfaces = all/inet_interfaces = all/g' >> /etc/postfix/main.cf >> sed -i 's/inet_interfaces = localhost/#inet_interfaces = localhost/g' >> /etc/postfix/main.cf >> >> # apply postfix changes >> service postfix restart >> >> # Install dovecot >> yum -y install dovecot >> >> # set dovecot to start on boot >> chkconfig dovecot on >> >> # set dovecot to listen on imap and imaps only >> sed -i 's/#protocols = imap pop3 lmtp/protocols = imap imaps/g' >> /etc/dovecot/dovecot.conf >> >> # point dovecot to required mailbox directory (This is the section that >> was previously failing) >> echo "mail_location = mbox:~/mail:INBOX=/var/mail/%u" >> >> /etc/dovecot/dovecot.conf >> >> # reload dovecot to apply changes >> service dovecot restart >> >> # Apply working IPtables >> cat > /etc/sysconfig/iptables << EOF >> # Generated by iptables-save v1.4.7 on Tue Jan 10 12:17:41 2012 >> *filter >> :INPUT ACCEPT [0:0] >> :FORWARD ACCEPT [0:0] >> :OUTPUT ACCEPT [29:4596] >> -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT >> -A INPUT -p tcp -m tcp --dport 143 -j ACCEPT >> -A INPUT -p tcp -m tcp --dport 993 -j ACCEPT >> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT >> -A INPUT -p icmp -j ACCEPT >> -A INPUT -i lo -j ACCEPT >> -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT >> -A INPUT -j REJECT --reject-with icmp-host-prohibited >> -A FORWARD -j REJECT --reject-with icmp-host-prohibited >> COMMIT >> # Completed on Tue Jan 10 12:17:41 2012 >> EOF >> >> With the above details, I am able to replicate a 100% working IPA >> authenticated mail server, allowing IPA users to retrieve mail via >> imap/imaps. >> >> I hope this helps. >> >> >> Dale >> >> >> >> On 01/30/2012 01:46 PM, Dmitri Pal wrote: >>> On 01/30/2012 07:16 AM, Dale Macartney wrote: >>>> >>>> Hi all >>>> >>>> I'm working on a test lab setup at the moment with RHEL 6.2 running IPA >>>> 2.1 and experimenting with simple mail server setups. . >>>> >>>> I have mail being received base on pam lookups from IPA. The mail server >>>> is tapped into IPA via the ipa-client-install. >>>> >>>> I am using a default install of the dovecot rpm from RHN, and dovecot is >>>> listening via imap/imaps, however all authentication requests fail when >>>> attempting to login via imap.. >>>> >>>> I added the necessary keytabs for imap/mail.example.com and >>>> imaps/mail.example.com to /etc/krb5.keytab but this hasn't allowed >>>> authentication. >>>> >>>> has anyone set up dovecot through IPA before? Any recommendations? >>>> >>>> >>> Hi Dale, >> >>> Will you be so kind to share with the list a little bit more details >> about how to setup Dovecot with IPA? If you can provide step by step >> instructions we would publish them on the FreeIPA wiki. >> >>> Thank you >>> Dmitri >> >> >>>> thanks all >>>> >>>> Dale >>>> >>>> >> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >>> -- >>> Thank you, >>> Dmitri Pal >> >>> Sr. Engineering Manager IPA project, >>> Red Hat Inc. >> >> >>> ------------------------------- >>> Looking to carve out IT costs? >>> www.redhat.com/carveoutcosts/ >> >> >> >> >> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > So I am a bit confused here, is this working for you or not? It looked > like you were asking a question to begin with, but then at then end you > are saying it is 100% working? > > Just trying to figure out whether you need help, > -Erinn > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPJu1iAAoJEAJsWS61tB+qpT8P/Rwwf4tiKaJycKs93RoogUDh xxCOwA5nScV0aTBqDWqQweWR78DPeUXDAP1CtscmeCeyZnVyyh65ZfJHea9YcL0i o6BedZiZ1nBk3iESZSYnvIZ9Woz4GZwH6S7ZlJgoP8c74+9WwnT6VT6DfwP/8+c4 VYNLJyUNNJHffnCQu24toq4cm4wckKYTrErY6IAVQHgo+lBZMdstnUhWa2q6hRao kXchqFnj+NXNI5mOoEuG8ROqTVimX+PTLaBlkM1d3bErCweprJrybohVscK4WmDy wFELxHsO21YsClMI2BEJcjm0t+8U+EnLNGMTAYKTy3jqvdSOdNBCtz+95MoICdFD 7JcJcrGyyp4Njke0dg8Pe3zVwCFYyPEdccT+CLyVGlUcbByOz+JwFfCaAXLaggYa oQ1Z7Y7LNXEdWl2K9vC3h3kYH7gTItWUYOGUn6MrU6Kzidi2tqZJB8DNqwoH57jc VMNGyaNA3vH806RwbQKmWd5sUl/pWb2GF/5cMm/u+4CP8mdB6lb7D1m2CyNwSdKv 7YnxOPG0+YfhwbbNOyDfNOr0Ov0ldc5P2JzYzEbzH68UAhvnF1WED135oVP+t6q/ 180FDHbml2mlL5iOjJu86pYhBR0OWqOpTaINMsYWOWupMWwpkfoXD275o7rkFv+B VS0bfEtLNBXsRLMXqeIJ =d/X7 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 5790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From erinn.looneytriggs at gmail.com Mon Jan 30 19:41:47 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 30 Jan 2012 10:41:47 -0900 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F26ED84.60205@themacartneyclan.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> Message-ID: <4F26F27B.1060209@gmail.com> On 01/30/2012 10:20 AM, Dale Macartney wrote: > > Hi Erinn > > I originally asked the question as I was thinking my auth attempts were > failing when using ipa, however this was not the case. > > On closer inspection, i found that the authentication was successful yet > dovecot was failing to read a "missing" mailbox. > > I found that dovecot was simply missing the mailbox_location directive, > detailed below. > > mail_location = mbox:~/mail:INBOX=/var/mail/%u > > Once I restarted dovecot with this extra line, the authentication was > again validated. I was then prompted to accept the self-signed > certificate from dovecot and I was able to retrieve the mail as intended. > > Does this help clear things up? > > > Dale >> So I am a bit confused here, is this working for you or not? It looked >> like you were asking a question to begin with, but then at then end you >> are saying it is 100% working? > >> Just trying to figure out whether you need help, >> -Erinn > Hey sounds good to me, just glad it is working for you :). The only other question/suggestion I have is that it looks like you aren't leveraging kerberos in your configuration for SSO, You might want to think about doing this as it can be a pretty nice configuration. Essentially you would just need to add service principles for the host in the form of imap and or pop, and change the auth line in your dovecot config to allow for gssapi auth, like so: sed -i -r "s&(\smechanisms =).*&\1 gssapi plain&" Then assuming your user has a ticket, and their client is properly configured, they no longer need to do anything upon logging into their system, kerb will auth the rest. If you are on a multihomed system, you will need two additional changes, service principles for the other host name, and the following modification: sed -i -r 's&#auth_gssapi_hostname.*&auth_gssapi_hostname = $ALL&' I got a little caught up when you referenced the /etc/krb5.keytab file as possibly part of the problem so I thought this was more a kerb issue. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From dale at themacartneyclan.com Mon Jan 30 19:50:48 2012 From: dale at themacartneyclan.com (Dale Macartney) Date: Mon, 30 Jan 2012 19:50:48 +0000 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F26F27B.1060209@gmail.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> Message-ID: <4F26F498.8020407@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Erinn, funny you mention that actually, I was adding service principles when i was first troubleshooting that. SSO is definitely on the planned cards for me to be honest. I'll send through the details to the list one I have a reproducible configuration :-) thanks for the positive feedback. Dale On 01/30/2012 07:41 PM, Erinn Looney-Triggs wrote: > On 01/30/2012 10:20 AM, Dale Macartney wrote: >> >> Hi Erinn >> >> I originally asked the question as I was thinking my auth attempts were >> failing when using ipa, however this was not the case. >> >> On closer inspection, i found that the authentication was successful yet >> dovecot was failing to read a "missing" mailbox. >> >> I found that dovecot was simply missing the mailbox_location directive, >> detailed below. >> >> mail_location = mbox:~/mail:INBOX=/var/mail/%u >> >> Once I restarted dovecot with this extra line, the authentication was >> again validated. I was then prompted to accept the self-signed >> certificate from dovecot and I was able to retrieve the mail as intended. >> >> Does this help clear things up? >> >> >> Dale > >>> So I am a bit confused here, is this working for you or not? It looked >>> like you were asking a question to begin with, but then at then end you >>> are saying it is 100% working? >> >>> Just trying to figure out whether you need help, >>> -Erinn >> > > Hey sounds good to me, just glad it is working for you :). The only > other question/suggestion I have is that it looks like you aren't > leveraging kerberos in your configuration for SSO, You might want to > think about doing this as it can be a pretty nice configuration. > > Essentially you would just need to add service principles for the host > in the form of imap and or pop, and change the auth line in your dovecot > config to allow for gssapi auth, like so: > > sed -i -r "s&(\smechanisms =).*&\1 gssapi plain&" > > Then assuming your user has a ticket, and their client is properly > configured, they no longer need to do anything upon logging into their > system, kerb will auth the rest. > > If you are on a multihomed system, you will need two additional changes, > service principles for the other host name, and the following modification: > sed -i -r 's&#auth_gssapi_hostname.*&auth_gssapi_hostname = $ALL&' > > I got a little caught up when you referenced the /etc/krb5.keytab file > as possibly part of the problem so I thought this was more a kerb issue. > > -Erinn > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPJvSFAAoJEAJsWS61tB+qG9oP/0pDktSo4y5iRKEvMVOplSEx NFIl2cRm3OsjcOJuCMoFotMTFon90H6KxYQz0sYvtERZZWrB7nkpKneRGHZ/ri9R e4eEV/Edp/3yck8INAZ2COMGTKGCm8SFdN1ihnAU7QQ1EDC+kKq/pKUfxyq4LKH2 2KDkCnR02zRfjr+bzaL5tWZkNIAxifsFr6ycuT0GrX03y1KErjPAbre4BPjTq3lG b5xHkZBGVCfFp6bxdfQSs2d4BLcNOwCA1vW0KXAUy4ps1dS220ceeutO+9WbM6Y/ f0g1Iupsa/mIHIIAr6SBi0RGqSEUVkYaRzSxqRSEckfYAK+hPlnl5r46O1UxOFaw jaiizMTgkK3Q2skEtsaVSmPGleNoK0sefvf+Tkuea+1qdSdPUQaqiLwteLGo/QxR KsNPcO8+SN/YtXMynSw2bCY/uejn+NWNJVAW39vWsTlUV4+dtm0SIIcp8s57CLb0 3fZ2XLsfAajF83EucYv0BJE/flnZBQkLFEK6WdM0d/6jcEwn3RE17gOm/ufzvyVQ c3fpRinNSoO+nxwg/wzyljSkd2vsZFIB0oPSeapg+OTccQooXg/QKxGD2ViDIJeq y0pqV6wl3YreKTrdNFG4Eurz99EBG3vZcXFDq7JNd3NMo5nxrrExHDYU9brrTsyN E8BCvhI6AIwHW/5rwOlN =QFxQ -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 5790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From Steven.Jones at vuw.ac.nz Mon Jan 30 19:55:49 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 30 Jan 2012 19:55:49 +0000 Subject: [Freeipa-users] unable to install or uninstall ipa In-Reply-To: <4F26BD3B.3070504@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CB7A19E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E404CB7A1BF@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F26BD3B.3070504@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CB7C8B6@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Yes it appears to be a ldap / dirsrv not starting issue.....Cant see anything in the install log, I have raised a case with RH anyway. I ran the un-install 3 or 4 times and it finally cleaned up..... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Tuesday, 31 January 2012 4:54 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] unable to install or uninstall ipa Steven Jones wrote: > Example of install failure messages, > > ====== > Warning: skipping DNS resolution of host vuwunicoipam001.unix.vuw.ac.nz > The IPA Master Server will be configured with > Hostname: vuwunicoipam001.unix.vuw.ac.nz > IP address: 10.70.3.10 > Domain name: unix.vuw.ac.nz > > > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > Configuring ntpd > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > done configuring ntpd. > Configuring directory server: Estimated time 1 minute > [1/35]: creating directory server user > [2/35]: creating directory server instance > [3/35]: adding default schema > [4/35]: enabling memberof plugin > root : CRITICAL Failed to load memberof-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/memberof-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpkbE724' returned non-zero exit status 255 > [5/35]: enabling referential integrity plugin > root : CRITICAL Failed to load referint-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/referint-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpExKKnk' returned non-zero exit status 255 > [6/35]: enabling winsync plugin > root : CRITICAL Failed to load ipa-winsync-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/ipa-winsync-conf.ldif -x -D cn=Directory Manager -y /tmp/tmppChSx9' returned non-zero exit status 255 > [7/35]: configuring replication version plugin > root : CRITICAL Failed to load version-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/version-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpqy9Fkp' returned non-zero exit status 255 > [8/35]: enabling IPA enrollment plugin > root : CRITICAL Failed to load enrollment-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpoWPpcO -x -D cn=Directory Manager -y /tmp/tmpxbRGyx' returned non-zero exit status 255 > [9/35]: enabling ldapi > root : CRITICAL Failed to load ldapi.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpVSJoE2 -x -D cn=Directory Manager -y /tmp/tmpqsK_aD' returned non-zero exit status 255 > [10/35]: configuring uniqueness plugin > root : CRITICAL Failed to load unique-attributes.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpWJEh76 -x -D cn=Directory Manager -y /tmp/tmpzxvY9u' returned non-zero exit status 255 > [11/35]: configuring uuid plugin > root : CRITICAL Failed to load uuid-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/uuid-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpdYNh2T' returned non-zero exit status 255 > root : CRITICAL Failed to load uuid-ipauniqueid.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpkEOmk2 -x -D cn=Directory Manager -y /tmp/tmp9ZDoXY' returned non-zero exit status 255 > [12/35]: configuring modrdn plugin > root : CRITICAL Failed to load modrdn-conf.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/modrdn-conf.ldif -x -D cn=Directory Manager -y /tmp/tmpofFRs8' returned non-zero exit status 255 > root : CRITICAL Failed to load modrdn-krbprinc.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /tmp/tmpDxRP25 -x -D cn=Directory Manager -y /tmp/tmpUexNQN' returned non-zero exit status 255 > [13/35]: enabling entryUSN plugin > root : CRITICAL Failed to load entryusn.ldif: Command '/usr/bin/ldapmodify -h vuwunicoipam001.unix.vuw.ac.nz -v -f /usr/share/ipa/entryusn.ldif -x -D cn=Directory Manager -y /tmp/tmpgsBw1B' returned non-zero exit status 255 > ========= > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] > Sent: Monday, 30 January 2012 2:03 p.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] unable to install or uninstall ipa > > I have a failed install with lots of critical failures... > > :( > > When I try to re-install it says its installed but when I try to --uninstall it will not..... > > How do I clean it up manually? > > ======== > [root at vuwunicoipam001 ~]# ipa-server-install --uninstall > > This is a NON REVERSIBLE operation and will delete all data and configuration! > > Are you sure you want to continue with the uninstall procedure? [no]: yes > Shutting down all IPA services > Removing IPA client configuration > Unconfiguring directory server > Unexpected error - see ipaserver-uninstall.log for details: > [Errno 2] No such file or directory: '/etc/dirsrv/slapd-UNIX-VUW-AC-NZ' > [root at vuwunicoipam001 ~]# > ======== To clean it up look at the files in /var/lib/ipa/sysrestore. There you'll find files that were backed up, a state file indicating the initial state when the installer started and an index file which accounts for all the backup files. You can remove [dirsrv] from the state file perhaps but be sure the instance really is gone. It is safe to re-run the uninstaller multiple times and sometimes this is required to get everything cleaned up on some kinds of failures. The problem is that the 389-ds isn't starting up for some reason. You may find the reason why in /var/log/ipaserver-install.log or the 389-ds logs. rob From dpal at redhat.com Mon Jan 30 20:02:53 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 30 Jan 2012 15:02:53 -0500 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F26F498.8020407@themacartneyclan.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> Message-ID: <4F26F76D.1010503@redhat.com> On 01/30/2012 02:50 PM, Dale Macartney wrote: > > Hey Erinn, funny you mention that actually, I was adding service > principles when i was first troubleshooting that. > > SSO is definitely on the planned cards for me to be honest. I'll send > through the details to the list one I have a reproducible > configuration :-) And to the page, please > > thanks for the positive feedback. > > Dale > > > > On 01/30/2012 07:41 PM, Erinn Looney-Triggs wrote: > > On 01/30/2012 10:20 AM, Dale Macartney wrote: > >> > >> Hi Erinn > >> > >> I originally asked the question as I was thinking my auth attempts were > >> failing when using ipa, however this was not the case. > >> > >> On closer inspection, i found that the authentication was > successful yet > >> dovecot was failing to read a "missing" mailbox. > >> > >> I found that dovecot was simply missing the mailbox_location directive, > >> detailed below. > >> > >> mail_location = mbox:~/mail:INBOX=/var/mail/%u > >> > >> Once I restarted dovecot with this extra line, the authentication was > >> again validated. I was then prompted to accept the self-signed > >> certificate from dovecot and I was able to retrieve the mail as > intended. > >> > >> Does this help clear things up? > >> > >> > >> Dale > > >>> So I am a bit confused here, is this working for you or not? It looked > >>> like you were asking a question to begin with, but then at then > end you > >>> are saying it is 100% working? > >> > >>> Just trying to figure out whether you need help, > >>> -Erinn > >> > > > Hey sounds good to me, just glad it is working for you :). The only > > other question/suggestion I have is that it looks like you aren't > > leveraging kerberos in your configuration for SSO, You might want to > > think about doing this as it can be a pretty nice configuration. > > > Essentially you would just need to add service principles for the host > > in the form of imap and or pop, and change the auth line in your dovecot > > config to allow for gssapi auth, like so: > > > sed -i -r "s&(\smechanisms =).*&\1 gssapi plain&" > > > Then assuming your user has a ticket, and their client is properly > > configured, they no longer need to do anything upon logging into their > > system, kerb will auth the rest. > > > If you are on a multihomed system, you will need two additional changes, > > service principles for the other host name, and the following > modification: > > sed -i -r 's&#auth_gssapi_hostname.*&auth_gssapi_hostname = $ALL&' > > > I got a little caught up when you referenced the /etc/krb5.keytab file > > as possibly part of the problem so I thought this was more a kerb issue. > > > -Erinn > > > > _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Mon Jan 30 20:13:31 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 30 Jan 2012 20:13:31 +0000 Subject: [Freeipa-users] unable to install or uninstall ipa In-Reply-To: <4F26BD3B.3070504@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CB7A19E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E404CB7A1BF@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F26BD3B.3070504@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CB7CAF9@STAWINCOX10MBX1.staff.vuw.ac.nz> Looks like the dirsrv is running......... ============= [root at vuwunicoipam001 slapd-UNIX-VUW-AC-NZ]# tail -f errors [31/Jan/2012:09:07:10 +1300] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [31/Jan/2012:09:07:10 +1300] - check_and_set_import_cache: pagesize: 4096, pages: 513748, procpages: 50259 [31/Jan/2012:09:07:10 +1300] - Import allocates 821996KB import cache. [31/Jan/2012:09:07:10 +1300] - import userRoot: Beginning import job... [31/Jan/2012:09:07:10 +1300] - import userRoot: Index buffering enabled with bucket size 100 [31/Jan/2012:09:07:11 +1300] - import userRoot: Processing file "/var/lib/dirsrv/boot.ldif" [31/Jan/2012:09:07:11 +1300] - import userRoot: Finished scanning file "/var/lib/dirsrv/boot.ldif" (1 entries) [31/Jan/2012:09:07:11 +1300] - import userRoot: Workers finished; cleaning up... [31/Jan/2012:09:07:11 +1300] - import userRoot: Workers cleaned up. [31/Jan/2012:09:07:11 +1300] - import userRoot: Cleaning up producer thread... [31/Jan/2012:09:07:11 +1300] - import userRoot: Indexing complete. Post-processing... [31/Jan/2012:09:07:11 +1300] - Nothing to do to build ancestorid index [31/Jan/2012:09:07:11 +1300] - import userRoot: Flushing caches... [31/Jan/2012:09:07:11 +1300] - import userRoot: Closing files... [31/Jan/2012:09:07:11 +1300] - All database threads now stopped [31/Jan/2012:09:07:11 +1300] - import userRoot: Import complete. Processed 1 entries in 1 seconds. (1.00 entries/sec) [31/Jan/2012:09:07:16 +1300] - 389-Directory/1.2.9.14 B2011.312.195 starting up [31/Jan/2012:09:07:16 +1300] - I'm resizing my cache now...cache was 841723904 and is now 8000000 [31/Jan/2012:09:07:16 +1300] - slapd started. Listening on All Interfaces port 389 for LDAP requests [31/Jan/2012:09:07:17 +1300] - slapd shutting down - signaling operation threads [31/Jan/2012:09:07:17 +1300] - slapd shutting down - closing down internal subsystems and plugins [31/Jan/2012:09:07:17 +1300] - Waiting for 4 database threads to stop [31/Jan/2012:09:07:17 +1300] - All database threads now stopped [31/Jan/2012:09:07:17 +1300] - slapd stopped. [31/Jan/2012:09:07:19 +1300] - 389-Directory/1.2.9.14 B2011.312.195 starting up [31/Jan/2012:09:07:19 +1300] - slapd started. Listening on All Interfaces port 389 for LDAP requests ============= 8><--- The problem is that the 389-ds isn't starting up for some reason. You may find the reason why in /var/log/ipaserver-install.log or the 389-ds logs. rob From dale at themacartneyclan.com Mon Jan 30 20:16:52 2012 From: dale at themacartneyclan.com (Dale Macartney) Date: Mon, 30 Jan 2012 20:16:52 +0000 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F26F76D.1010503@redhat.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F26F76D.1010503@redhat.com> Message-ID: <4F26FAB4.2020602@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ;-) will do mate. I'm writing a list of items to cover at the moment actually. On 01/30/2012 08:02 PM, Dmitri Pal wrote: > On 01/30/2012 02:50 PM, Dale Macartney wrote: > > >> Hey Erinn, funny you mention that actually, I was adding service >> principles when i was first troubleshooting that. >> >> SSO is definitely on the planned cards for me to be honest. I'll send >> through the details to the list one I have a reproducible configuration :-) > And to the page, please > >> >> thanks for the positive feedback. >> >> Dale >> >> >> >> On 01/30/2012 07:41 PM, Erinn Looney-Triggs wrote: >> > On 01/30/2012 10:20 AM, Dale Macartney wrote: >> >> >> >> Hi Erinn >> >> >> >> I originally asked the question as I was thinking my auth attempts were >> >> failing when using ipa, however this was not the case. >> >> >> >> On closer inspection, i found that the authentication was successful yet >> >> dovecot was failing to read a "missing" mailbox. >> >> >> >> I found that dovecot was simply missing the mailbox_location directive, >> >> detailed below. >> >> >> >> mail_location = mbox:~/mail:INBOX=/var/mail/%u >> >> >> >> Once I restarted dovecot with this extra line, the authentication was >> >> again validated. I was then prompted to accept the self-signed >> >> certificate from dovecot and I was able to retrieve the mail as intended. >> >> >> >> Does this help clear things up? >> >> >> >> >> >> Dale >> >> >>> So I am a bit confused here, is this working for you or not? It looked >> >>> like you were asking a question to begin with, but then at then end you >> >>> are saying it is 100% working? >> >> >> >>> Just trying to figure out whether you need help, >> >>> -Erinn >> >> >> >> > Hey sounds good to me, just glad it is working for you :). The only >> > other question/suggestion I have is that it looks like you aren't >> > leveraging kerberos in your configuration for SSO, You might want to >> > think about doing this as it can be a pretty nice configuration. >> >> > Essentially you would just need to add service principles for the host >> > in the form of imap and or pop, and change the auth line in your dovecot >> > config to allow for gssapi auth, like so: >> >> > sed -i -r "s&(\smechanisms =).*&\1 gssapi plain&" >> >> > Then assuming your user has a ticket, and their client is properly >> > configured, they no longer need to do anything upon logging into their >> > system, kerb will auth the rest. >> >> > If you are on a multihomed system, you will need two additional changes, >> > service principles for the other host name, and the following modification: >> > sed -i -r 's&#auth_gssapi_hostname.*&auth_gssapi_hostname = $ALL&' >> >> > I got a little caught up when you referenced the /etc/krb5.keytab file >> > as possibly part of the problem so I thought this was more a kerb issue. >> >> > -Erinn >> >> >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPJvqrAAoJEAJsWS61tB+qnecP/3JhcdNm/OQU+meGtP2TxjG2 Zjbhy12WF+Yxo1fW74W2cp21GdHbpvmCfQCCDRMtlCQso3kxpoEyPsU0Y+7+3kQ+ cL34l2f8jATvY6EqljxsGaeqstvfVSMtAUbWHbCJ3YOO4s2pYI3sfvENPL+bjOFV LzzgQ8CKnpspzyMoDapPnLFkfwNzGIjvnX7BMgy3pdJRk9oAHP8IRaa6U7H15Plu 7joC1ElbH09VyOhrjPwf7Jy9+3ayHeB/WLPJ4U0DR0rYsDjErFkDXA7R95Kw6MYQ N3DPsFELgIvxGxt5h8sXcbg9/MBpuPLtcpLaANoscNO76OLhy9qLSZjDgykbq6Kp zXOxNLWLwTHBWq8cv2Ul3H+WzM8mjYaE46VE9pksDAz0H+PljY5f0cHjUx/1sqqR cD/txgR32xZxGYJjfnODGwVrysNVpvqjsBysV7exdk4byldTXB4CbfhznyII+Ewk fIWh7h0gjx8U3uRAUcXZXNIcmmcyc9Z232J6hmlKN4Tc71GX/MLp7YfvGtVSbhzu rrlH16u7CAsi3DqMcwsb5zUW03CcJAp6qjmBoTHbSbhE4XmO6Gs+thlAkTKo1tzo ixdvApq3k8HcAlCvR9Uzwg90huWBmn9BcWAJY/DL5Sb6U5YbUwDzFX/gh9jgY1cr 8zYKbYb9LR9W8UqfwwpP =PkH/ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 5790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From ayoung at redhat.com Tue Jan 31 02:12:04 2012 From: ayoung at redhat.com (Adam Young) Date: Mon, 30 Jan 2012 21:12:04 -0500 Subject: [Freeipa-users] WebUI With Windows, Firefox, and MIT Kerberos In-Reply-To: <4F24441F.2080902@gmail.com> References: <4A3F2452-B056-45A8-A3C5-BBA4D02BD391@citrixonline.com> <4F24441F.2080902@gmail.com> Message-ID: <4F274DF4.5070802@redhat.com> On 01/28/2012 01:53 PM, Erinn Looney-Triggs wrote: > On 1/27/2012 4:53 PM, JR Aquino wrote: >> On Jan 27, 2012, at 5:31 PM, Jr Aquino wrote: >> >> Has anyone successfully gotten firefox in windows with firefox and mit kerberos? >> >> I've followed several how to's, but i cant get firefox to take/pass my tgt. >> >> >> The Key to success: >> >> network.negotiate-auth.gsslib: C:\Program Files\MIT\Kerberos\bin\gssapi32.dll >> >> I had been previously using lib\i386/gssapi32.lib and thats what was breaking it. >> >> The rest of the documentation on the FreeIPA site is sound. >> >> We could probably stand to add that 1 line to the doc at http://freeipa.com/page/ClientConfigurationGuide >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > The only other thing I would add here, at least for me, was on an x86_64 > install of windows I needed to use: C:\Program Files > (x86)\MIT\Kerberos\bin\gssapi32.dll > > -Erinn > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Done. Thanks to both of you for contributing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From JR.Aquino at citrix.com Tue Jan 31 06:48:56 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Tue, 31 Jan 2012 06:48:56 +0000 Subject: [Freeipa-users] WebUI With Windows, Firefox, and MIT Kerberos In-Reply-To: <4F274DF4.5070802@redhat.com> References: <4A3F2452-B056-45A8-A3C5-BBA4D02BD391@citrixonline.com> <4F24441F.2080902@gmail.com> <4F274DF4.5070802@redhat.com> Message-ID: <2F0E9427-BC30-438F-B242-CAFD9F5879C4@citrixonline.com> On Jan 30, 2012, at 6:12 PM, Adam Young wrote: On 01/28/2012 01:53 PM, Erinn Looney-Triggs wrote: On 1/27/2012 4:53 PM, JR Aquino wrote: On Jan 27, 2012, at 5:31 PM, Jr Aquino wrote: Has anyone successfully gotten firefox in windows with firefox and mit kerberos? I've followed several how to's, but i cant get firefox to take/pass my tgt. The Key to success: network.negotiate-auth.gsslib: C:\Program Files\MIT\Kerberos\bin\gssapi32.dll I had been previously using lib\i386/gssapi32.lib and thats what was breaking it. The rest of the documentation on the FreeIPA site is sound. We could probably stand to add that 1 line to the doc at http://freeipa.com/page/ClientConfigurationGuide _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users The only other thing I would add here, at least for me, was on an x86_64 install of windows I needed to use: C:\Program Files (x86)\MIT\Kerberos\bin\gssapi32.dll -Erinn OPPS! One other line I needed to change for firefox to work in windows: network.auth.use-sspi: false ^ This tells firefox to use the built-in AD based Kerberos/SSO. I didn't realize I had missed this until I went back through from scratch to retest. From ondrejv at s3group.cz Tue Jan 31 09:22:50 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 31 Jan 2012 10:22:50 +0100 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F26F498.8020407@themacartneyclan.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> Message-ID: <4F27B2EA.1090305@s3group.cz> >> Hey sounds good to me, just glad it is working for you :). The only >> other question/suggestion I have is that it looks like you aren't >> leveraging kerberos in your configuration for SSO, You might want to >> think about doing this as it can be a pretty nice configuration. >> >> Essentially you would just need to add service principles for the host >> in the form of imap and or pop, and change the auth line in your dovecot >> config to allow for gssapi auth, like so: >> >> sed -i -r "s&(\smechanisms =).*&\1 gssapi plain&" >> >> Then assuming your user has a ticket, and their client is properly >> configured, they no longer need to do anything upon logging into their >> system, kerb will auth the rest. >> >> If you are on a multihomed system, you will need two additional changes, >> service principles for the other host name, and the following modification: >> sed -i -r 's&#auth_gssapi_hostname.*&auth_gssapi_hostname = $ALL&' >> >> I got a little caught up when you referenced the /etc/krb5.keytab file >> as possibly part of the problem so I thought this was more a kerb issue. >> Exactly, I was confused by this as well - I would like to see this working, too. But I would say we would need to do something with the permissions on /etc/krb5.keytab which is now (by default) only readable by root. We need to address this problem more in general as when inegrating Bind DNS server, you hit the same thing. I would say something like ACL entry would help. Ondrej Proud winners of the prestigious Irish Software Exporter Award 2011 from Irish Exporters Association (IEA). Please, refer to our web site for more details regarding the award. -------- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Tue Jan 31 12:32:36 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 31 Jan 2012 07:32:36 -0500 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F27B2EA.1090305@s3group.cz> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F27B2EA.1090305@s3group.cz> Message-ID: <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> On Tue, 2012-01-31 at 10:22 +0100, Ondrej Valousek wrote: > > > > Hey sounds good to me, just glad it is working for you :). The only > > > other question/suggestion I have is that it looks like you aren't > > > leveraging kerberos in your configuration for SSO, You might want to > > > think about doing this as it can be a pretty nice configuration. > > > > > > Essentially you would just need to add service principles for the host > > > in the form of imap and or pop, and change the auth line in your dovecot > > > config to allow for gssapi auth, like so: > > > > > > sed -i -r "s&(\smechanisms =).*&\1 gssapi plain&" > > > > > > Then assuming your user has a ticket, and their client is properly > > > configured, they no longer need to do anything upon logging into their > > > system, kerb will auth the rest. > > > > > > If you are on a multihomed system, you will need two additional changes, > > > service principles for the other host name, and the following modification: > > > sed -i -r 's&#auth_gssapi_hostname.*&auth_gssapi_hostname = $ALL&' > > > > > > I got a little caught up when you referenced the /etc/krb5.keytab file > > > as possibly part of the problem so I thought this was more a kerb issue. > > > > Exactly, I was confused by this as well - I would like to see this > working, too. But I would say we would need to do something with the > permissions on /etc/krb5.keytab which is now (by default) only > readable by root. We need to address this problem more in general as > when inegrating Bind DNS server, you hit the same thing. > I would say something like ACL entry would help. I fail to see why non-root processes should be trying to read /etc/krb5.keytab at all. You should be generating a per-service keytab with only the keys necessary for that service to authenticate itself to the KDC. So you might have /etc/dovecot/dovecot.keytab which is readable only by the dovecot user. The problem with allowing access to /etc/krb5.keytab is that it means that an exploit in another process (especially a mail server!) could gain access to the keys necessary to impersonate your host in kerberized applications on the network. That's really dangerous. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sigbjorn at nixtra.com Tue Jan 31 12:35:43 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 31 Jan 2012 13:35:43 +0100 (CET) Subject: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD In-Reply-To: <1327943174.2240.38.camel@sgallagh520.sgallagh.bos.redhat.com> References: <22124.213.225.75.97.1327935713.squirrel@www.nixtra.com> <1327936847.2240.25.camel@sgallagh520.sgallagh.bos.redhat.com> <1327943174.2240.38.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <33082.213.225.75.97.1328013343.squirrel@www.nixtra.com> On Mon, January 30, 2012 18:06, Stephen Gallagher wrote: > On Mon, 2012-01-30 at 18:00 +0100, Sigbjorn Lie wrote: > >> Sure. Ive left the office for today, will do so tomorrow. >> >> >> Im not very familiar with gdb. Any particular syntax / switches to >> add? >> >> Rgds, >> Siggi. >> > > You'll want to do this in a non-graphical terminal, so you can switch to > it if KDE gets into trouble. > > First, install the sssd-debuginfo packages (debuginfo-install sssd) > and install gdb (yum install gdb) > > Then run: > gdb -p ($pidof sssd_be) > > Then in the gdb prompt, type 'cont' (this will resume execution of > sssd_be). > > Now, switch back to KDE and unlock the screen. Then switch back to this > virtual terminal. > > You should be back at the prompt, with GDB telling you that you received > a SIGSEGV or SIGABRT. > > Type "bt full" and reply with all pages of output from that (there may > be multiple, requiring you to hit enter to see them). > Ok, please see below for the output from gdb. I notice that it's not happening every time. All this morning I could unlock without any issues. Around lunchtime the issue started occouring again, but it's different each time how many times I have to restart sssd before I can successfully unlock my desktop. warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff3fbfd000 0x00002b104670cce3 in __epoll_wait_nocancel () from /lib64/libc.so.6 (gdb) cont Continuing. Detaching after fork from child process 22008. Detaching after fork from child process 23608. Detaching after fork from child process 28122. Detaching after fork from child process 32315. Program received signal SIGSEGV, Segmentation fault. sysdb_attrs_get_el_int (attrs=0x6c616d726f6e2d72, name=0x43c75d "name", alloc=true, el=0x7fff3fafbb18) at src/db/sysdb.c:254 254 for (i = 0; i < attrs->num; i++) { (gdb) Continuing. Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) bt full No stack. (gdb) Regards, Siggi From sgallagh at redhat.com Tue Jan 31 12:40:46 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 31 Jan 2012 07:40:46 -0500 Subject: [Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD In-Reply-To: <33082.213.225.75.97.1328013343.squirrel@www.nixtra.com> References: <22124.213.225.75.97.1327935713.squirrel@www.nixtra.com> <1327936847.2240.25.camel@sgallagh520.sgallagh.bos.redhat.com> <1327943174.2240.38.camel@sgallagh520.sgallagh.bos.redhat.com> <33082.213.225.75.97.1328013343.squirrel@www.nixtra.com> Message-ID: <1328013646.2240.98.camel@sgallagh520.sgallagh.bos.redhat.com> On Tue, 2012-01-31 at 13:35 +0100, Sigbjorn Lie wrote: > > > Ok, please see below for the output from gdb. > > I notice that it's not happening every time. All this morning I could unlock without any issues. > Around lunchtime the issue started occouring again, but it's different each time how many times I > have to restart sssd before I can successfully unlock my desktop. > > > > warning: no loadable sections found in added symbol-file system-supplied DSO at > 0x7fff3fbfd000 > 0x00002b104670cce3 in __epoll_wait_nocancel () from /lib64/libc.so.6 > (gdb) cont > Continuing. > > Detaching after fork from child process 22008. > Detaching after fork from child process 23608. > Detaching after fork from child process 28122. > Detaching after fork from child process 32315. > > Program received signal SIGSEGV, Segmentation fault. > sysdb_attrs_get_el_int (attrs=0x6c616d726f6e2d72, name=0x43c75d "name", > alloc=true, el=0x7fff3fafbb18) at src/db/sysdb.c:254 > 254 for (i = 0; i < attrs->num; i++) { > (gdb) > Continuing. Don't do "continue" here. This is where we needed the 'bt full'. Once you continue from here, it just exits and we lose the state. Please rerun this test. > > Program terminated with signal SIGSEGV, Segmentation fault. > The program no longer exists. > (gdb) bt full > No stack. > (gdb) > > > Regards, > Siggi > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ondrejv at s3group.cz Tue Jan 31 12:58:31 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 31 Jan 2012 13:58:31 +0100 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F27B2EA.1090305@s3group.cz> <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4F27E577.70203@s3group.cz> > I fail to see why non-root processes should be trying to > read /etc/krb5.keytab at all. You should be generating a per-service > keytab with only the keys necessary for that service to authenticate > itself to the KDC. So you might have /etc/dovecot/dovecot.keytab which > is readable only by the dovecot user. > > The problem with allowing access to /etc/krb5.keytab is that it means > that an exploit in another process (especially a mail server!) could > gain access to the keys necessary to impersonate your host in kerberized > applications on the network. That's really dangerous. Right, but that's exactly what is happening with kerberized BIND, right? As far as I understand, you need to chown /etc/krb5.keytab to 'named' first. In general, you are probably right, the only problem is that most of the Linux kerberized services expect krb5.keytab in /etc. Moreover, in situation where winbind (or later maybe even sssd, for example) maintains the system Kerberos database, we would need some means to tell him to maintain more database files on multiple locations - and that is too messy. Maybe a time to introduce some simple database layer on the top of the /etc/krb5.keytab which would handle the permissions correctly? Applications/services would need to talk to this layer and not krb5.keytab directly. Ondrej > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Proud winners of the prestigious Irish Software Exporter Award 2011 from Irish Exporters Association (IEA). Please, refer to our web site for more details regarding the award. -------- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Jan 31 14:22:00 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 31 Jan 2012 09:22:00 -0500 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F27E577.70203@s3group.cz> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F27B2EA.1090305@s3group.cz> <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> <4F27E577.70203@s3group.cz> Message-ID: <1328019720.13963.252.camel@willson.li.ssimo.org> On Tue, 2012-01-31 at 13:58 +0100, Ondrej Valousek wrote: > > > > I fail to see why non-root processes should be trying to > > read /etc/krb5.keytab at all. You should be generating a per-service > > keytab with only the keys necessary for that service to authenticate > > itself to the KDC. So you might have /etc/dovecot/dovecot.keytab which > > is readable only by the dovecot user. > > > > The problem with allowing access to /etc/krb5.keytab is that it means > > that an exploit in another process (especially a mail server!) could > > gain access to the keys necessary to impersonate your host in kerberized > > applications on the network. That's really dangerous. > Right, but that's exactly what is happening with kerberized BIND, > right? As far as I understand, you need to chown /etc/krb5.keytab to > 'named' first. Not at all, in freeipa we create a /etc/named/dns.keytab (or similar) and we put there the keys for the DNS/fqdn at REALM principal. > In general, you are probably right, the only problem is that most of > the Linux kerberized services expect krb5.keytab in /etc. /etc/krb5.keytab is simply the default keytab location, you just need to set the KRB5_KTNAME env variable right before services startup (init scripts or systemd unit files) to make them user a different default. Some let you explicitly define the keytab location in their config to avoid having to mess with environment variables. > Moreover, in situation where winbind (or later maybe even sssd, for > example) maintains the system Kerberos database, we would need some > means to tell him to maintain more database files on multiple > locations - and that is too messy. These tools maintain only the host/ or at most the cifs/ keytab normally. The other keytabs are not, although with AD that's messy as AD aliases all keys to the host/ one. That is a bad issue with AD that I plan to fix in the spring via the gss-proxy project I am working on. > Maybe a time to introduce some simple database layer on the top of > the /etc/krb5.keytab which would handle the permissions correctly? See https://fedorahosted.org/gss-proxy/ I know there isn't much info yet. Some info is here, but also needs a bit of updating: http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI > Applications/services would need to talk to this layer and not > krb5.keytab directly. That's completely right, working on that :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Jan 31 14:23:47 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 31 Jan 2012 09:23:47 -0500 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F27B2EA.1090305@s3group.cz> <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <1328019828.13963.254.camel@willson.li.ssimo.org> On Tue, 2012-01-31 at 07:32 -0500, Stephen Gallagher wrote: > On Tue, 2012-01-31 at 10:22 +0100, Ondrej Valousek wrote: > > > > > > Hey sounds good to me, just glad it is working for you :). The only > > > > other question/suggestion I have is that it looks like you aren't > > > > leveraging kerberos in your configuration for SSO, You might want to > > > > think about doing this as it can be a pretty nice configuration. > > > > > > > > Essentially you would just need to add service principles for the host > > > > in the form of imap and or pop, and change the auth line in your dovecot > > > > config to allow for gssapi auth, like so: > > > > > > > > sed -i -r "s&(\smechanisms =).*&\1 gssapi plain&" > > > > > > > > Then assuming your user has a ticket, and their client is properly > > > > configured, they no longer need to do anything upon logging into their > > > > system, kerb will auth the rest. > > > > > > > > If you are on a multihomed system, you will need two additional changes, > > > > service principles for the other host name, and the following modification: > > > > sed -i -r 's&#auth_gssapi_hostname.*&auth_gssapi_hostname = $ALL&' > > > > > > > > I got a little caught up when you referenced the /etc/krb5.keytab file > > > > as possibly part of the problem so I thought this was more a kerb issue. > > > > > > Exactly, I was confused by this as well - I would like to see this > > working, too. But I would say we would need to do something with the > > permissions on /etc/krb5.keytab which is now (by default) only > > readable by root. We need to address this problem more in general as > > when inegrating Bind DNS server, you hit the same thing. > > I would say something like ACL entry would help. > > > I fail to see why non-root processes should be trying to > read /etc/krb5.keytab at all. You should be generating a per-service > keytab with only the keys necessary for that service to authenticate > itself to the KDC. So you might have /etc/dovecot/dovecot.keytab which > is readable only by the dovecot user. > > The problem with allowing access to /etc/krb5.keytab is that it means > that an exploit in another process (especially a mail server!) could > gain access to the keys necessary to impersonate your host in kerberized > applications on the network. That's really dangerous. Just to make it clear how bad it is. The host/ key is used to validate logins, if an attacker gets it it can successfuly MITM a login attempt by hijacking KDC replies to AS-REQ and TGS-REQ by forging a TGT and then forging a ticket for the host using the host key. It is *very* bad, so try to reduce the number of applications that can access the host/ keys. Simo. -- Simo Sorce * Red Hat, Inc * New York From dale at themacartneyclan.com Tue Jan 31 16:07:26 2012 From: dale at themacartneyclan.com (Dale Macartney) Date: Tue, 31 Jan 2012 16:07:26 +0000 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <1328019828.13963.254.camel@willson.li.ssimo.org> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F27B2EA.1090305@s3group.cz> <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> <1328019828.13963.254.camel@willson.li.ssimo.org> Message-ID: <4F2811BE.8010305@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 howdy all just another update from me. I have a workable gssapi setup working with dovecot for imap... (i didn't test pop.... yet). the below setup was tested against rhel6.2 # enable dovecot on startup chkconfig dovecot on # set dovecot to listen on imap sed -i 's/#protocols = imap pop3 lmtp/protocols = imap/g' /etc/dovecot/dovecot.conf # set mailbost location echo "mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u" >> /etc/dovecot/dovecot.conf # enable user/mailbox lookups echo "userdb {" >> /etc/dovecot/conf.d/10-auth.conf echo " driver = static" >> /etc/dovecot/conf.d/10-auth.conf echo " args = uid=dovecot gid=dovecot home=/var/spool/mail/%u" >> /etc/dovecot/conf.d/10-auth.conf echo "}" >> /etc/dovecot/conf.d/10-auth.conf # set all gssapi goodies for SSO against IPA sed -i 's/auth_mechanisms = plain/auth_mechanisms = gssapi/g' /etc/dovecot/conf.d/10-auth.conf sed -i "s/#auth_gssapi_hostname =/auth_gssapi_hostname = $(hostname)/g" /etc/dovecot/conf.d/10-auth.conf sed -i "s-#auth_krb5_keytab =-auth_krb5_keytab = /etc/krb5.keytab-g" /etc/dovecot/conf.d/10-auth.conf sed -i "s/#auth_realms =/auth_realms = $(hostname --domain)/g" /etc/dovecot/conf.d/10-auth.conf sed -i "s/#auth_default_realm =/auth_default_realm = $(hostname --domain)/g" /etc/dovecot/conf.d/10-auth.conf # create keytab for service principles. kinit admin ipa service-add imap/mail02.example.com ipa service-add imaps/mail02.example.com ipa-getkeytab -s ds01.example.com -p imap/mail02.example.com -k /etc/krb5.keytab ipa-getkeytab -s ds01.example.com -p imaps/mail02.example.com -k /etc/krb5.keytab setfacl -m u:dovecot:r /etc/krb5.keytab service dovecot restart there 2 things I want to get resolved before i put the details on the wiki and thats around selinux and automated deployments (kickstart).. when selinux is enforcing, i receive these messages in /var/log/maillog. The second line shows the error. Jan 31 15:54:28 mail02 dovecot: imap-login: Login: user=, method=GSSAPI, rip=192.168.122.61, lip=192.168.122.32, mpid=20737, TLS Jan 31 15:54:28 mail02 dovecot: imap(user1): Error: open(/home/user1/mail/.imap/INBOX/dovecot.index.log) failed: Permission denied (euid=1201600003(user1) egid=1201600003(user1) missing +r perm: /home/user1/mail/.imap/INBOX/dovecot.index.log, euid is not dir owner) the first line shows the successful gssapi authentication. (gotta love not entering passwords). I am no guru on dovecot, but does anyone have any recommendations for the second line? I presume it has to do with the format that I am setting the mail_location variable. I reproduced this twice to verify the settings. The only part that I can't automate via kickstart, is the kinit admin section, of course because we have to enter a password here.. any thoughts? Dale On 01/31/2012 02:23 PM, Simo Sorce wrote: > On Tue, 2012-01-31 at 07:32 -0500, Stephen Gallagher wrote: >> On Tue, 2012-01-31 at 10:22 +0100, Ondrej Valousek wrote: >>> >>>>> Hey sounds good to me, just glad it is working for you :). The only >>>>> other question/suggestion I have is that it looks like you aren't >>>>> leveraging kerberos in your configuration for SSO, You might want to >>>>> think about doing this as it can be a pretty nice configuration. >>>>> >>>>> Essentially you would just need to add service principles for the host >>>>> in the form of imap and or pop, and change the auth line in your dovecot >>>>> config to allow for gssapi auth, like so: >>>>> >>>>> sed -i -r "s&(\smechanisms =).*&\1 gssapi plain&" >>>>> >>>>> Then assuming your user has a ticket, and their client is properly >>>>> configured, they no longer need to do anything upon logging into their >>>>> system, kerb will auth the rest. >>>>> >>>>> If you are on a multihomed system, you will need two additional changes, >>>>> service principles for the other host name, and the following modification: >>>>> sed -i -r 's&#auth_gssapi_hostname.*&auth_gssapi_hostname = $ALL&' >>>>> >>>>> I got a little caught up when you referenced the /etc/krb5.keytab file >>>>> as possibly part of the problem so I thought this was more a kerb issue. >>>>> >>> Exactly, I was confused by this as well - I would like to see this >>> working, too. But I would say we would need to do something with the >>> permissions on /etc/krb5.keytab which is now (by default) only >>> readable by root. We need to address this problem more in general as >>> when inegrating Bind DNS server, you hit the same thing. >>> I would say something like ACL entry would help. >> >> >> I fail to see why non-root processes should be trying to >> read /etc/krb5.keytab at all. You should be generating a per-service >> keytab with only the keys necessary for that service to authenticate >> itself to the KDC. So you might have /etc/dovecot/dovecot.keytab which >> is readable only by the dovecot user. >> >> The problem with allowing access to /etc/krb5.keytab is that it means >> that an exploit in another process (especially a mail server!) could >> gain access to the keys necessary to impersonate your host in kerberized >> applications on the network. That's really dangerous. > > Just to make it clear how bad it is. > The host/ key is used to validate logins, if an attacker gets it it can > successfuly MITM a login attempt by hijacking KDC replies to AS-REQ and > TGS-REQ by forging a TGT and then forging a ticket for the host using > the host key. > > It is *very* bad, so try to reduce the number of applications that can > access the host/ keys. > > Simo. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPKBGvAAoJEAJsWS61tB+qERMQAIyz/8ZTJYOJv0c1O6QtFMUY kznbbGwT3ydjCNWCIWiuZs+sg9rOKWueGsM1wUA0OPZKHon261E6X8DMdXpvOfRr /Y7Suub4XJxIlLDEvjSwbUIkniTlM6mbnHrxuEvGw+51fBjXZCXR1LPsFtcz8qAh HXYnpEyFgsBTapQ0foO5anM2CtM1g+qrqkIeSkWV9aHk4UYBG5tR+OWJeUVBeQUV 9Ch/9xcBGOJcaCeKDxgWfvOfgJFP5YX4tuEYNGJNYpJP3fosMP1+Uf0Hsnn+b2sV DuOlZIsMT45GsswsNIATbxfnmCn76jT2PTrFGFGFFjt47Mw7vPt5Ago6SxpmVlWN cMRNuC1Z3bjp7jIIBJvOV6cQDVpaEhss0wuq/TWMfD9NadYCruPoil48UX+focLd TlfOrK4iZ9qeSwlh0nnn9eSqCMJQjizPo1EqNrMm+vImccR9eSM8GSRvaO/3vHtJ 0pEVcUEQvJydOiUV9lNH5Z0goujWQveRirYImuiyEA3aK/P1pP49agVkNvD4e9Mf UWyrWstuYXTAjS8QRTGMXmzQz41u7KnBwjMSKQq7qcMFIOcP3IoZWXvc+OdlfgnZ YeVEHTL83Zs5ZyzeS71TJE9l3R7jp4ztEdtjJuwPkMXSZTqWT26/9WD75vIQLVON i7Z+nM1U0MvqViwuzGBW =wwcq -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 5790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From sigbjorn at nixtra.com Tue Jan 31 16:37:35 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 31 Jan 2012 17:37:35 +0100 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F2811BE.8010305@themacartneyclan.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F27B2EA.1090305@s3group.cz> <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> <1328019828.13963.254.camel@willson.li.ssimo.org> <4F2811BE.8010305@themacartneyclan.com> Message-ID: <4F2818CF.1020707@nixtra.com> On 01/31/2012 05:07 PM, Dale Macartney wrote: > > sed -i "s-#auth_krb5_keytab =-auth_krb5_keytab = /etc/krb5.keytab-g" > /etc/dovecot/conf.d/10-auth.conf > Perhaps I could recommend to retreive the imap/imaps keytabs into a seperate keytab file, and configure the auth_krb5_keytab config file option in dovecot.conf to point to this file. This increases the security by a tenfold as pointed out earlier in this thread. Regards, Siggi From dale at themacartneyclan.com Tue Jan 31 16:40:38 2012 From: dale at themacartneyclan.com (Dale Macartney) Date: Tue, 31 Jan 2012 16:40:38 +0000 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F2818CF.1020707@nixtra.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F27B2EA.1090305@s3group.cz> <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> <1328019828.13963.254.camel@willson.li.ssimo.org> <4F2811BE.8010305@themacartneyclan.com> <4F2818CF.1020707@nixtra.com> Message-ID: <4F281986.7030907@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 thanks Siggi, I was just browsing past those mails from earlier today as well... I'll make those changes before it goes on the wiki. On 01/31/2012 04:37 PM, Sigbjorn Lie wrote: > On 01/31/2012 05:07 PM, Dale Macartney wrote: >> >> sed -i "s-#auth_krb5_keytab =-auth_krb5_keytab = /etc/krb5.keytab-g" >> /etc/dovecot/conf.d/10-auth.conf >> > > Perhaps I could recommend to retreive the imap/imaps keytabs into a seperate keytab file, and configure the auth_krb5_keytab config file option in dovecot.conf to point to this file. This increases the security by a tenfold as pointed out earlier in this thread. > > > > Regards, > Siggi > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPKBl+AAoJEAJsWS61tB+qIaEQAKvmMIbXaf8xoExx4I2zNSf6 Vz0cmCH5DLzOLnIJR13qqsSCOcYiYRow6o/F5hlsoN1sbdvPDKXpg2xDviWqUI4V wNyC7/HLCjNyufqj+El/V9hQfGbu6CggIei5cPB716R9Lq+5Wwi6Wbv0l/4KB3aV K6c0iow93cVA7Z9F1LfYynxKpsYAMX+0jnc+hybnVqlQHk1F24LIkfCKO5vQLz/N qw0h+PddqD57sfJNxUxjQ9OpPeWDZYuCtIeFnCsbG8LnfLhkU6oHoxJYFCySpynN tTkBLDLG94CAsav5rWmttzuxLvVQR7dFpemOvgaAXMOHrOGl75+XTH1b4AyEU9XP BuX87CrzhuNWNCDV5lI82DGgjeOH2O5UN16vpE8KTT94fstH3OvOjpwBIQoMq+1A /3Rj3hL+Q5UYkPm30+0eCPTlFwnlwUQpeNI27DuzV/SnjCvqtNeqTBxP6o3CdGHL 0/vNWVOVgbhCYkPp5c+mceLrJVihtVNFhhVv1v7KNmITbu2PVklkDhwLgDY3T3Cw YuYqSkO7AgQSb7eirw4t/KRhEvvwOTmrAB61l4WFtgonrr3pH6+zwYoyZvBTDwd8 UN2VfyjjGc6Sdc7NYKfOi7EgNaGJlxL/z0yJN6gz8LU1sWfv6Ol4vPoyE7obc68z wQLL9IVwG/7btEoWdFA3 =Dpue -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 5790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From dale at themacartneyclan.com Tue Jan 31 18:22:36 2012 From: dale at themacartneyclan.com (Dale Macartney) Date: Tue, 31 Jan 2012 18:22:36 +0000 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F281986.7030907@themacartneyclan.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F27B2EA.1090305@s3group.cz> <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> <1328019828.13963.254.camel@willson.li.ssimo.org> <4F2811BE.8010305@themacartneyclan.com> <4F2818CF.1020707@nixtra.com> <4F281986.7030907@themacartneyclan.com> Message-ID: <4F28316C.5070507@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All I just found the culprit for the selinux error I have the user's home dir automatically created when I was testing the account was working. ssh user2 at mail02.example.com... etc for some reason, the selinux context of the users homedir is set to home_root_t instead of user_home_dir_t. once a restorecon was run on /home (restorecon -R /home) the selinux errors disappeared when accessing mail via imap. I'll do a write up of the details for the wiki so it is documented. Dale On 01/31/2012 04:40 PM, Dale Macartney wrote: > > thanks Siggi, > > I was just browsing past those mails from earlier today as well... I'll > make those changes before it goes on the wiki. > > > > On 01/31/2012 04:37 PM, Sigbjorn Lie wrote: > > On 01/31/2012 05:07 PM, Dale Macartney wrote: > >> > >> sed -i "s-#auth_krb5_keytab =-auth_krb5_keytab = /etc/krb5.keytab-g" > >> /etc/dovecot/conf.d/10-auth.conf > >> > > > Perhaps I could recommend to retreive the imap/imaps keytabs into a > seperate keytab file, and configure the auth_krb5_keytab config file > option in dovecot.conf to point to this file. This increases the > security by a tenfold as pointed out earlier in this thread. > > > > > Regards, > > Siggi > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPKDFpAAoJEAJsWS61tB+qmn4P/32sD+bJJWd2J8XjqFti6lC2 BZhahWgYiEpfwgGX5B3YSwx7v6URq+dYdp0ZIYJFTAMitq6qDD8Y0wJ7bpd1zxb1 GyVLDDBxkpzLOSFe21CqQVsWvOLU9AHlOWcT4AaKYU8M2s4XqyIqiY8WduAzJcen l1Q2yryZ6uAYdpLsG4WHxu9WvfSE+85K0cvFlc302tVa/JyML40gsRueRN7gRAHa zhPOu605ZgEP890CvP1jHN77hH7WU52MZqBJrscnFIbxEhuJtjMzXIPcGeJev+TR aHiBzdGVsQUssFAL6B589l+Q3NxRSlU/zxCk9pERF3Ql8m/YPnlBiTdqa0Am3y6+ PJF5ggmkDIeWCWuJwT9f1Rpm2zF/ooytnPlcIfm3hbETHFdzPjNBH52M/whXrCx6 XdUw5Bk3sYkSdmrbgjqVY/gz+We3JzkWBPbiKf1I8DD7EOTT4lb5BNxsSKAslwZn apbnIcTkMn9du22zIn5/o1iYbnUi52BEJkTj0ZNrmNDeVNMYA/A/ssUcC4ecEiql aIDftfH+2sFvzDBIyB1eygibpcI2ILTy4J8gwLSAZyZ3oF65icnfTUldkqB/JBC8 6yVJKXMNIojTQo7NKaBJ3pDF1mALLzfXldGOqxudF7U7TlhGyvqA+SpTPxA9IM77 qKHqWoOCfTci/4C+ncLn =0kQn -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 5790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From simo at redhat.com Tue Jan 31 18:48:17 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 31 Jan 2012 13:48:17 -0500 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F28316C.5070507@themacartneyclan.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F27B2EA.1090305@s3group.cz> <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> <1328019828.13963.254.camel@willson.li.ssimo.org> <4F2811BE.8010305@themacartneyclan.com> <4F2818CF.1020707@nixtra.com> <4F281986.7030907@themacartneyclan.com> <4F28316C.5070507@themacartneyclan.com> Message-ID: <1328035697.21059.4.camel@willson.li.ssimo.org> On Tue, 2012-01-31 at 18:22 +0000, Dale Macartney wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All > > I just found the culprit for the selinux error > > I have the user's home dir automatically created when I was testing > the account was working. > > ssh user2 at mail02.example.com... etc > > for some reason, the selinux context of the users homedir is set to > home_root_t instead of user_home_dir_t. If you use pam_mkhomedir I suggest changing to use pam_oddjob_mkhomedir The seocnd one can properly deal with SELinux labeling on creation. > once a restorecon was run on /home (restorecon -R /home) the selinux > errors disappeared when accessing mail via imap. > > I'll do a write up of the details for the wiki so it is documented. > > > Dale > > > > On 01/31/2012 04:40 PM, Dale Macartney wrote: > > > > thanks Siggi, > > > > I was just browsing past those mails from earlier today as well... > I'll > > make those changes before it goes on the wiki. > > > > > > > > On 01/31/2012 04:37 PM, Sigbjorn Lie wrote: > > > On 01/31/2012 05:07 PM, Dale Macartney wrote: > > >> > > >> sed -i "s-#auth_krb5_keytab =-auth_krb5_keytab > = /etc/krb5.keytab-g" > > >> /etc/dovecot/conf.d/10-auth.conf > > >> > > > > > Perhaps I could recommend to retreive the imap/imaps keytabs into > a > > seperate keytab file, and configure the auth_krb5_keytab config file > > option in dovecot.conf to point to this file. This increases the > > security by a tenfold as pointed out earlier in this thread. > > > > > > > > > Regards, > > > Siggi > > > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPKDFpAAoJEAJsWS61tB+qmn4P/32sD+bJJWd2J8XjqFti6lC2 > BZhahWgYiEpfwgGX5B3YSwx7v6URq+dYdp0ZIYJFTAMitq6qDD8Y0wJ7bpd1zxb1 > GyVLDDBxkpzLOSFe21CqQVsWvOLU9AHlOWcT4AaKYU8M2s4XqyIqiY8WduAzJcen > l1Q2yryZ6uAYdpLsG4WHxu9WvfSE+85K0cvFlc302tVa/JyML40gsRueRN7gRAHa > zhPOu605ZgEP890CvP1jHN77hH7WU52MZqBJrscnFIbxEhuJtjMzXIPcGeJev+TR > aHiBzdGVsQUssFAL6B589l+Q3NxRSlU/zxCk9pERF3Ql8m/YPnlBiTdqa0Am3y6+ > PJF5ggmkDIeWCWuJwT9f1Rpm2zF/ooytnPlcIfm3hbETHFdzPjNBH52M/whXrCx6 > XdUw5Bk3sYkSdmrbgjqVY/gz+We3JzkWBPbiKf1I8DD7EOTT4lb5BNxsSKAslwZn > apbnIcTkMn9du22zIn5/o1iYbnUi52BEJkTj0ZNrmNDeVNMYA/A/ssUcC4ecEiql > aIDftfH+2sFvzDBIyB1eygibpcI2ILTy4J8gwLSAZyZ3oF65icnfTUldkqB/JBC8 > 6yVJKXMNIojTQo7NKaBJ3pDF1mALLzfXldGOqxudF7U7TlhGyvqA+SpTPxA9IM77 > qKHqWoOCfTci/4C+ncLn > =0kQn > -----END PGP SIGNATURE----- > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From dale at themacartneyclan.com Tue Jan 31 21:03:33 2012 From: dale at themacartneyclan.com (Dale Macartney) Date: Tue, 31 Jan 2012 21:03:33 +0000 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <1328035697.21059.4.camel@willson.li.ssimo.org> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F27B2EA.1090305@s3group.cz> <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> <1328019828.13963.254.camel@willson.li.ssimo.org> <4F2811BE.8010305@themacartneyclan.com> <4F2818CF.1020707@nixtra.com> <4F281986.7030907@themacartneyclan.com> <4F28316C.5070507@themacartneyclan.com> <1328035697.21059.4.camel@willson.li.ssimo.org> Message-ID: <4F285725.8050007@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Simo I have used oddjob in the past and it works a treat, however this was with ipa-client-install.. I was just dappling around with the script over diner and saw you were an author... whenever I use the flag --mkhomedir with ipa-client-install, i get the wrong contexts on the home dirs... I raised a bugzilla ticket just before I left the office. Bug *786223* . I'll keep playing with it an see what I come across. I'll feed back if anything useful comes up. Dale On 01/31/2012 06:48 PM, Simo Sorce wrote: > On Tue, 2012-01-31 at 18:22 +0000, Dale Macartney wrote: >> > All > > I just found the culprit for the selinux error > > I have the user's home dir automatically created when I was testing > the account was working. > > ssh user2 at mail02.example.com... etc > > for some reason, the selinux context of the users homedir is set to > home_root_t instead of user_home_dir_t. > > > If you use pam_mkhomedir I suggest changing to use pam_oddjob_mkhomedir > > The seocnd one can properly deal with SELinux labeling on creation. > > once a restorecon was run on /home (restorecon -R /home) the selinux > errors disappeared when accessing mail via imap. > > I'll do a write up of the details for the wiki so it is documented. > > > Dale > > > > On 01/31/2012 04:40 PM, Dale Macartney wrote: > >>> > >>> thanks Siggi, > >>> > >>> I was just browsing past those mails from earlier today as well... > I'll > >>> make those changes before it goes on the wiki. > >>> > >>> > >>> > >>> On 01/31/2012 04:37 PM, Sigbjorn Lie wrote: > >>>> On 01/31/2012 05:07 PM, Dale Macartney wrote: > >>>>> > >>>>> sed -i "s-#auth_krb5_keytab =-auth_krb5_keytab > = /etc/krb5.keytab-g" > >>>>> /etc/dovecot/conf.d/10-auth.conf > >>>>> > >>> > >>>> Perhaps I could recommend to retreive the imap/imaps keytabs into > a > >>> seperate keytab file, and configure the auth_krb5_keytab config file > >>> option in dovecot.conf to point to this file. This increases the > >>> security by a tenfold as pointed out earlier in this thread. > >>> > >>> > >>> > >>>> Regards, > >>>> Siggi > >>> > >>>> _______________________________________________ > >>>> Freeipa-users mailing list > >>>> Freeipa-users at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPKFcYAAoJEAJsWS61tB+qA6IP/0ciTfwfa/Tz4GAYu8HdMHBL NQvfPyZaVhDjpBrhxTv01/E8P71uDqOYcTjfeOGPiykthrmNJKeDBhi09vs5fL9K NNUO1TovyACtuF9Z/Hrzm5ziZQ6wDQdXq+Hmh3lncMThLxzLpq+31/3NFKoNkID/ T88zodOp9j0QZT7fIzoLbnJteiQy0APZD2L4Y7p5hGKBrXrRK81UxjrRW1B6HF5C WhRYGngXRT3sEFMvL95ReckHMsJFLbBDbAPSfNZt6fsMrQ2ZS7lGl0U8jq8EoAkT kJ/FDUcwSup0PUy+W55zrTuc6pIK8rJ/bRjtzGuAnBDONy52uazU7fiTsljtupnG AvZFbPDJOmhQx1ea/K/uRjFkn02eng7wIhWaLzCEKqAR/yfdR+lsT6SN8LvzIz62 WcwCLaur6909OEQP7nJrsHVbCOqmThwOUKiowUWV60rA69neeOZ/OLptkXxY3+3m UAitAd4mESuB8vWKBpZU51pgq0SKGexbSnLK3T8ch1eNM+1hQyYZBbRO5O2DWoRW xgu7SM0W/qXvlqfnStQj1KVnnKGiLwGIVeKkxaYZTAaFdLQULASqO86b2UN3+kxj QHSY4lciyu2J8nds1fWQ0H94VXBebEwQ+XbfldkaQ71rwgUfToOJTEiS51kDQ318 YXgRmVB+fAFxegdQiF5t =b8Gw -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 5790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From simo at redhat.com Tue Jan 31 21:28:43 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 31 Jan 2012 16:28:43 -0500 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F285725.8050007@themacartneyclan.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F27B2EA.1090305@s3group.cz> <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> <1328019828.13963.254.camel@willson.li.ssimo.org> <4F2811BE.8010305@themacartneyclan.com> <4F2818CF.1020707@nixtra.com> <4F281986.7030907@themacartneyclan.com> <4F28316C.5070507@themacartneyclan.com> <1328035697.21059.4.camel@willson.li.ssimo.org> <4F285725.8050007@themacartneyclan.com> Message-ID: <1328045323.21059.10.camel@willson.li.ssimo.org> On Tue, 2012-01-31 at 21:03 +0000, Dale Macartney wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Simo > > I have used oddjob in the past and it works a treat, however this was > with ipa-client-install.. > > I was just dappling around with the script over diner and saw you were > an author... > > whenever I use the flag --mkhomedir with ipa-client-install, i get the > wrong contexts on the home dirs... > > I raised a bugzilla ticket just before I left the office. Bug *786223* > . > > I'll keep playing with it an see what I come across. I'll feed back if > anything useful comes up. I am going to mark it as duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=647589 as that is an authconfig bug. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Tue Jan 31 21:28:47 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 31 Jan 2012 16:28:47 -0500 Subject: [Freeipa-users] Dovecot imap authentication with IPA/Kerberos In-Reply-To: <4F285725.8050007@themacartneyclan.com> References: <4F268A2F.5050408@themacartneyclan.com> <4F269F43.40607@redhat.com> <4F26C85F.1020502@themacartneyclan.com> <4F26EB4B.80209@gmail.com> <4F26ED84.60205@themacartneyclan.com> <4F26F27B.1060209@gmail.com> <4F26F498.8020407@themacartneyclan.com> <4F27B2EA.1090305@s3group.cz> <1328013156.2240.95.camel@sgallagh520.sgallagh.bos.redhat.com> <1328019828.13963.254.camel@willson.li.ssimo.org> <4F2811BE.8010305@themacartneyclan.com> <4F2818CF.1020707@nixtra.com> <4F281986.7030907@themacartneyclan.com> <4F28316C.5070507@themacartneyclan.com> <1328035697.21059.4.camel@willson.li.ssimo.org> <4F285725.8050007@themacartneyclan.com> Message-ID: <1328045327.2240.133.camel@sgallagh520.sgallagh.bos.redhat.com> On Tue, 2012-01-31 at 21:03 +0000, Dale Macartney wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Simo > > I have used oddjob in the past and it works a treat, however this was > with ipa-client-install.. > > I was just dappling around with the script over diner and saw you were > an author... > > whenever I use the flag --mkhomedir with ipa-client-install, i get the > wrong contexts on the home dirs... > > I raised a bugzilla ticket just before I left the office. Bug *786223* > . > > I'll keep playing with it an see what I come across. I'll feed back if > anything useful comes up. Yeah, ipa-client-install just invokes 'authconfig --update --enablemkhomedir' Authconfig's GUI version will auto-detect the presence of pam_oddjob_mkhomedir and prefer that over pam_mkhomedir, but it appears the command-line version always configures pam_mkhomedir. We need to get that fixed in authconfig. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: