From freeipa at voidembraced.net Thu Mar 4 02:17:46 2010 From: freeipa at voidembraced.net (root) Date: Wed, 03 Mar 2010 18:17:46 -0800 Subject: [Freeipa-users] Unable to connect to IPA server: File Not Found In-Reply-To: <4B87D151.9040404@redhat.com> References: <1CD40A4DEEA320479C98D8A93A5C6906EF11C1@waterloo.t24uk.tipp24.net> <4B699217.8020508@redhat.com> <1CD40A4DEEA320479C98D8A93A5C6906026B0F38@waterloo.t24uk.tipp24.net> <4B69A57A.8080908@redhat.com> <1CD40A4DEEA320479C98D8A93A5C6906026B1103@waterloo.t24uk.tipp24.net> <4B6C4E06.6080703@redhat.com> <1CD40A4DEEA320479C98D8A93A5C6906028BFA25@waterloo.t24uk.tipp24.net> <4B853BCB.9030408@redhat.com> <1CD40A4DEEA320479C98D8A93A5C6906028BFA8E@waterloo.t24uk.tipp24.net> <4B87D151.9040404@redhat.com> Message-ID: <20100304021746.5156162D5C@IronClad.SEA.voidembraced.net> Greetings all: I'm thinking I just have to bounce something (or maybe it's been long enough that I'm running the command wrong, but I don't think so). Note that I show the error when not authenticated, and that I can authenticate without error: [root at sandbox1 ~]# ipa-finduser admin Could not initialize GSSAPI: Unspecified GSS failure. Minor code may provide more information/Ticket expired [root at sandbox1 ~]# kinit admin -k -t krb5.keytab [root at sandbox1 ~]# ipa-finduser admin Unable to connect to IPA server: File Not Found I assume that the "File Not Found" is simply a poor error message. Any insight into what I need to do to fix this? I tried bouncing [ns-]ldap/dirsrv just in case that was the source of our problem. NOTE: We also use coda, and it has no difficulty authenticating to [IPA] kerberos (though we are having an odd UID issue with non-admin users which prompted the attempt to run some ipa-finduser queries). Your assistance in this matter is greatly appreciated. Regards, -Don {void} From rcritten at redhat.com Thu Mar 4 16:44:54 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Mar 2010 11:44:54 -0500 Subject: [Freeipa-users] Unable to connect to IPA server: File Not Found In-Reply-To: <20100304021746.5156162D5C@IronClad.SEA.voidembraced.net> References: <1CD40A4DEEA320479C98D8A93A5C6906EF11C1@waterloo.t24uk.tipp24.net> <4B699217.8020508@redhat.com> <1CD40A4DEEA320479C98D8A93A5C6906026B0F38@waterloo.t24uk.tipp24.net> <4B69A57A.8080908@redhat.com> <1CD40A4DEEA320479C98D8A93A5C6906026B1103@waterloo.t24uk.tipp24.net> <4B6C4E06.6080703@redhat.com> <1CD40A4DEEA320479C98D8A93A5C6906028BFA25@waterloo.t24uk.tipp24.net> <4B853BCB.9030408@redhat.com> <1CD40A4DEEA320479C98D8A93A5C6906028BFA8E@waterloo.t24uk.tipp24.net> <4B87D151.9040404@redhat.com> <20100304021746.5156162D5C@IronClad.SEA.voidembraced.net> Message-ID: <4B8FE386.3010301@redhat.com> root wrote: > Greetings all: > I'm thinking I just have to bounce something (or maybe it's been long > enough that I'm running the command wrong, but I don't think so). > Note that I show the error when not authenticated, and that I can > authenticate without error: > [root at sandbox1 ~]# ipa-finduser admin > Could not initialize GSSAPI: Unspecified GSS failure. Minor code may > provide more information/Ticket expired > [root at sandbox1 ~]# kinit admin -k -t krb5.keytab > [root at sandbox1 ~]# ipa-finduser admin > Unable to connect to IPA server: File Not Found > > I assume that the "File Not Found" is simply a poor error message. Any > insight into what I need to do to fix this? > I tried bouncing [ns-]ldap/dirsrv just in case that was the source of > our problem. > NOTE: We also use coda, and it has no difficulty authenticating to > [IPA] kerberos (though we are having an odd UID issue with non-admin > users which prompted the attempt to run some ipa-finduser queries). > > Your assistance in this matter is greatly appreciated. > > Regards, > -Don > {void} Well, File Not Found has probably trickled up from somewhere, it isn't something we directly report, so it isn't clear where it originated. Is anything logged in the Apache error log when you do this command? rob From dpal at redhat.com Mon Mar 8 13:36:53 2010 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 08 Mar 2010 08:36:53 -0500 Subject: [Freeipa-users] Unable to connect to IPA server: File Not Found Message-ID: <4B94FD75.9030708@redhat.com> Don, Sorry, I accidentally deleted your post. I am resending it. =============================== Greetings all: Turned out to be webservice getting reconfigured out from under me. We didn't know that the management interface website was necessary for the command-line management tools. This raises a couple more questions: 1) Is the free-ipa website needed only for management (i.e.: changes) to the IPA (e.g.: user additions, password changes, service deletions, etc.), or is it required for the fundamental workings of authentication -- we think this unlikely as this should be handled by kerberos/ldap, etc., and we were able to auth while the website was down. 2) What is the simplest way to configure the free-ipa website for command-line only usage -- is there a stand-alone daemon we can run for the free-ipa command-line utilities to work so we need not worry about free-ipa in our apache configs? 3) It is worthy of mention that we do have redundant configuration between two servers, and will need them to be able to propogate changes across -- is the free-ipa website in any way related to this, or is this entirely handled by internal kerberos/ldap faculties? Regards, -Don {void} > Greetings all: > I'm thinking I just have to bounce something (or maybe it's been long > enough that I'm running the command wrong, but I don't think so). > Note that I show the error when not authenticated, and that I can > authenticate without error: > [root at sandbox1 ~]# ipa-finduser admin > Could not initialize GSSAPI: Unspecified GSS failure. Minor code may > provide more information/Ticket expired > [root at sandbox1 ~]# kinit admin -k -t krb5.keytab > [root at sandbox1 ~]# ipa-finduser admin > Unable to connect to IPA server: File Not Found > > I assume that the "File Not Found" is simply a poor error message. > Any insight into what I need to do to fix this? > I tried bouncing [ns-]ldap/dirsrv just in case that was the source of > our problem. > NOTE: We also use coda, and it has no difficulty authenticating to > [IPA] kerberos (though we are having an odd UID issue with non-admin > users which prompted the attempt to run some ipa-finduser queries). > > Your assistance in this matter is greatly appreciated. > > Regards, > -Don > {void} > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmeggins at redhat.com Mon Mar 8 15:30:59 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 08 Mar 2010 08:30:59 -0700 Subject: [Freeipa-users] AD Sync Error In-Reply-To: <68b7c79a1003070306j205b0c1bt44c4d3c3dac3b963@mail.gmail.com> References: <68b7c79a1002240658w222a5333l12e0c31fe1eaffee@mail.gmail.com> <4B8543D8.3050806@redhat.com> <68b7c79a1003070306j205b0c1bt44c4d3c3dac3b963@mail.gmail.com> Message-ID: <4B951833.5000506@redhat.com> Shan Kumaraswamy wrote: > Hi Rich, > > Sorry for the delay replay, after I executed your command I am getting > the following error from my directory server. Please help me to > resolve this error. > > [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com -p 636 -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > CN=administrator,CN=users,DC=bmitest,DC=com -w "secretpw" -s base -b > "" "objectclass=*" > ldap_simple_bind: Can't contact LDAP server > SSL error -5961 (TCP connection reset by peer.) Is sbtaddc001.bmitest.com the real, registered DNS address for the Active Directory server? On both the linux machine and the windows machine? Does a reverse DNS lookup on the IP address return that hostname? Is Active Directory configured to use/listen to SSL? Does the cert db /etc/dirsrv/slapd-BMITEST-COM/cert8.db contain the CA cert of the windows CA? certutil -L -d /etc/dirsrv/slapd-BMITEST-COM > > > > > > On Wed, Feb 24, 2010 at 6:20 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Dear All, > I am facing the AD Sync issue with FreeIPA to Active > Directory, and as per the redhat-ds doc I have done all the > settings from AD front. please help me to resolve this issue. > And find the below error message: > [root at sbttipa001 ~]# ipa-replica-manage add --winsync > --binddn CN=ipaadmin,CN=users,DC=bmitest,DC=com --bindpw > secretpw --ca cert /etc/dirsrv/slapd-BMITEST-COM/adsync.cer > sbtaddc001.bmitest.com > > -v --passsync bmi.123 > > Directory Manager password: > INFO:root:Shutting down dirsrv: > BMITEST-COM... [ OK ] > INFO:root: > INFO:root: > INFO:root: > INFO:root:Starting dirsrv: > BMITEST-COM... [ OK ] > INFO:root: > INFO:root:Added CA certificate > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer to certificate > database for sbttipa001.bmitest.com > > > > INFO:root:Restarted directory server sbttipa001.bmitest.com > > > > INFO:root:Could not validate connection to remote server > sbtaddc001.bmitest.com:636 > > > - continuing > > INFO:root:The error was: {'info': 'error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed', 'desc ': "Can't contact LDAP server"} > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=bmitest,dc=com > Windows PassSync entry exists, not resetting password > INFO:root:Added new sync agreement, waiting for it to become > ready . . . > INFO:root:Replication Update in progress: FALSE: status: 49 - > LDAP error: Invalid credentials: start: 0: end: 0 > INFO:root:Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > [sbttipa001.bmitest.com > >] reports: Update failed! > Status: [49 - LDAP error: Invalid credentials] > INFO:root:Added agreement for other host > sbtaddc001.bmitest.com > > > > Error 49 usually means the password is not correct. You can use > mozldap ldapsearch to test the connection like this: > > /usr/lib/mozldap/ldapsearch -h dchost -p 636 -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > CN=ipaadmin,CN=users,DC=bmitest,DC=com -w "secretpw" -s base -b "" > "objectclass=*" > > > -- > Thanks & Regards > Shan Kumaraswamy > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rcritten at redhat.com Mon Mar 8 15:46:59 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Mar 2010 10:46:59 -0500 Subject: [Freeipa-users] Unable to connect to IPA server: File Not Found In-Reply-To: <4B94FD75.9030708@redhat.com> References: <4B94FD75.9030708@redhat.com> Message-ID: <4B951BF3.9060004@redhat.com> Dmitri Pal wrote: > Don, > > Sorry, I accidentally deleted your post. > I am resending it. > > =============================== > > > Greetings all: > Turned out to be webservice getting reconfigured out from under me. We > didn't know that the management interface website was necessary for the > command-line management tools. > This raises a couple more questions: > 1) Is the free-ipa website needed only for management (i.e.: changes) to > the IPA (e.g.: user additions, password changes, service deletions, > etc.), or is it required for the fundamental workings of authentication > -- we think this unlikely as this should be handled by kerberos/ldap, > etc., and we were able to auth while the website was down. Apache provides a vehicle for getting to the TurboGears UI (via mod_proxy) and for the XML-RPC API used by the command-line. It isn't used for authentication/authorization. > 2) What is the simplest way to configure the free-ipa website for > command-line only usage -- is there a stand-alone daemon we can run for > the free-ipa command-line utilities to work so we need not worry about > free-ipa in our apache configs? It only runs from within Apache right now and there are no plans to do otherwise. We have all of the IPA configuration centralized in two files: ipa.conf and ipa-rewrite.conf, if that helps. > 3) It is worthy of mention that we do have redundant configuration > between two servers, and will need them to be able to propogate changes > across -- is the free-ipa website in any way related to this, or is this > entirely handled by internal kerberos/ldap faculties? Data (users, groups, etc) replication is handled by 389-ds. Per-service configuration is generally done on a per-box basis. We don't have integration with a configuration management system like puppet to keep configuration files in sync, if that is what you are asking. rob > > Regards, > -Don > {void} > >> Greetings all: >> I'm thinking I just have to bounce something (or maybe it's been long >> enough that I'm running the command wrong, but I don't think so). >> Note that I show the error when not authenticated, and that I can >> authenticate without error: >> [root at sandbox1 ~]# ipa-finduser admin >> Could not initialize GSSAPI: Unspecified GSS failure. Minor code may >> provide more information/Ticket expired >> [root at sandbox1 ~]# kinit admin -k -t krb5.keytab >> [root at sandbox1 ~]# ipa-finduser admin >> Unable to connect to IPA server: File Not Found >> >> I assume that the "File Not Found" is simply a poor error message. >> Any insight into what I need to do to fix this? >> I tried bouncing [ns-]ldap/dirsrv just in case that was the source of >> our problem. >> NOTE: We also use coda, and it has no difficulty authenticating to >> [IPA] kerberos (though we are having an odd UID issue with non-admin >> users which prompted the attempt to run some ipa-finduser queries). >> >> Your assistance in this matter is greatly appreciated. >> >> Regards, >> -Don >> {void} >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > From david at adurotec.com Tue Mar 9 00:15:05 2010 From: david at adurotec.com (David Christensen) Date: Mon, 08 Mar 2010 18:15:05 -0600 Subject: [Freeipa-users] Needed_Preauth Issue Message-ID: <4B959309.4070405@adurotec.com> I have two servers that I have installed the ipa-client on, both of these servers are configured the same way however one is providing single sign on, the other is not and instead prompts for a password when a user logs in I did verify that DNS is configured correctly for both servers. I issue kinit prior to logging into either server and verified that I have a valid ticket for both servers, but the failing server remains unchanged. When I look at the krb5kdc.log I see the following for the server that is prompting for a password: Mar 08 23:25:53 ipa1.example.net krb5kdc[12320](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.200.3.131: NEEDED_PREAUTH: davidc at EXAMPLE.NET for krbtgt/EXAMPLE.NET at EXAMPLE.NET, Additional pre-authentication required Mar 08 23:25:53 ipa1.example.net krb5kdc[12320](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.200.3.131: ISSUE: authtime 1268090753, etypes {rep=18 tkt=18 ses=18}, davidc at EXAMPLE.NET for krbtgt/EXAMPLE.NET at EXAMPLE.NET Where else should I look to find the root cause of this issue? What typically causes this type of symptom? Thanks in advance. -- David Christensen From freeipa at voidembraced.net Mon Mar 8 23:23:39 2010 From: freeipa at voidembraced.net (root) Date: Mon, 08 Mar 2010 15:23:39 -0800 Subject: [Freeipa-users] Unable to connect to IPA server: File Not Found In-Reply-To: <4B951BF3.9060004@redhat.com> References: <4B94FD75.9030708@redhat.com> <4B951BF3.9060004@redhat.com> Message-ID: <20100308232339.3A90B6320A@IronClad.SEA.voidembraced.net> >> Turned out to be webservice getting reconfigured out from under me. We >> didn't know that the management interface website was necessary for the >> command-line management tools. >> This raises a couple more questions: >> 1) Is the free-ipa website needed only for management (i.e.: changes) to >> the IPA (e.g.: user additions, password changes, service deletions, >> etc.), or is it required for the fundamental workings of authentication >> -- we think this unlikely as this should be handled by kerberos/ldap, >> etc., and we were able to auth while the website was down. > > Apache provides a vehicle for getting to the TurboGears UI (via mod_proxy) > and for the XML-RPC API used by the command-line. It isn't used for > authentication/authorization. Understood. This is as expected. >> 2) What is the simplest way to configure the free-ipa website for >> command-line only usage -- is there a stand-alone daemon we can run for >> the free-ipa command-line utilities to work so we need not worry about >> free-ipa in our apache configs? > > It only runs from within Apache right now and there are no plans to do > otherwise. We have all of the IPA configuration centralized in two files: > ipa.conf and ipa-rewrite.conf, if that helps. Unfortunately it's not that simple, as configuration bleeds over, but this is not your problem -- or, at least, you do not intend to provide the means for non-apache/CLI only administration of Free-IPA. I don't necessarily blame you, but it sure would be nice if we could nix apache from the mix. :D >> 3) It is worthy of mention that we do have redundant configuration >> between two servers, and will need them to be able to propogate changes >> across -- is the free-ipa website in any way related to this, or is this >> entirely handled by internal kerberos/ldap faculties? > > Data (users, groups, etc) replication is handled by 389-ds. Understood. This, too, is as expected. > Per-service configuration is generally done on a per-box basis. We don't > have integration with a configuration management system like puppet to > keep configuration files in sync, if that is what you are asking. No, you answered the question above. I only care about the internal configuration/state of free-ipa for the purpose of this inquiry. It appears that free-ipa [correctly] stores all it's data in kerberos/ldap, and that free-ipa itself is used only to maintain that kerberos/ldap stored data. Well, with the possible exception of adding/removing servers to the free-ipa management cluster. Thank you for your prompt attention to this matter. Regards, -Don {void} From rmeggins at redhat.com Tue Mar 9 15:16:44 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 09 Mar 2010 08:16:44 -0700 Subject: [Freeipa-users] AD Sync Error In-Reply-To: <68b7c79a1003090620u2cb45891h64d920248344cdda@mail.gmail.com> References: <68b7c79a1002240658w222a5333l12e0c31fe1eaffee@mail.gmail.com> <4B8543D8.3050806@redhat.com> <68b7c79a1003070306j205b0c1bt44c4d3c3dac3b963@mail.gmail.com> <4B951833.5000506@redhat.com> <68b7c79a1003090620u2cb45891h64d920248344cdda@mail.gmail.com> Message-ID: <4B96665C.4090700@redhat.com> Please keep replies on list Shan Kumaraswamy wrote: > Rich, > > > Does a reverse DNS lookup on the IP address return that hostname? -Yes > > Is Active Directory configured to use/listen to SSL? -Yes, Active > Directory Cert Auth installed and exported the and verifityed. > > > Does the cert db /etc/dirsrv/slapd-BMITEST-COM/cert8.db contain the CA > cert of the windows CA? -yes "Imported CA cert" > > certutil -L -d /etc/dirsrv/slapd-BMITEST-COM- Its listing installed cert > I am trying to creating syn agreement from IPA server using following > syntex: > > ipa-replica-manage add --winsync --binddn > CN=Administrator,CN=Users,CN=Accounts,DC=bmitest,DC=com --bindpw > secretpw --cacert /etc/dirsrv/slapd-BMITEST-COM/dsca.cer > sbtaddc001.bmitest.com -v > > Please corret me where I am doing worng? ldap_simple_bind: Can't contact LDAP server SSL error -5961 (TCP connection reset by peer.) This usually indicates some low level error. Let's try this: /usr/lib64/mozldap/ldapsearch -h sbtaddc001.bmitest.com -D "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s base -b "" "objectclass=*" Does that work? > > > > > > On Mon, Mar 8, 2010 at 6:30 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Hi Rich, > > Sorry for the delay replay, after I executed your command I am > getting the following error from my directory server. Please > help me to resolve this error. > > [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > -p 636 -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > CN=administrator,CN=users,DC=bmitest,DC=com -w "secretpw" -s > base -b "" "objectclass=*" > > ldap_simple_bind: Can't contact LDAP server > SSL error -5961 (TCP connection reset by peer.) > > Is sbtaddc001.bmitest.com > > > the real, registered DNS address for the Active Directory server? > On both the linux machine and the windows machine? > Does a reverse DNS lookup on the IP address return that hostname? > Is Active Directory configured to use/listen to SSL? > Does the cert db /etc/dirsrv/slapd-BMITEST-COM/cert8.db contain > the CA cert of the windows CA? > certutil -L -d /etc/dirsrv/slapd-BMITEST-COM > > > > > On Wed, Feb 24, 2010 at 6:20 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > Dear All, > I am facing the AD Sync issue with FreeIPA to Active > Directory, and as per the redhat-ds doc I have done all the > settings from AD front. please help me to resolve this > issue. > And find the below error message: > [root at sbttipa001 ~]# ipa-replica-manage add --winsync > --binddn CN=ipaadmin,CN=users,DC=bmitest,DC=com --bindpw > secretpw --ca cert /etc/dirsrv/slapd-BMITEST-COM/adsync.cer > sbtaddc001.bmitest.com > > > > > -v --passsync bmi.123 > > Directory Manager password: > INFO:root:Shutting down dirsrv: > BMITEST-COM... > [ OK ] > INFO:root: > INFO:root: > INFO:root: > INFO:root:Starting dirsrv: > BMITEST-COM... > [ OK ] > INFO:root: > INFO:root:Added CA certificate > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer to certificate > database for sbttipa001.bmitest.com > > > > > > > INFO:root:Restarted directory server > sbttipa001.bmitest.com > > > > > > INFO:root:Could not validate connection to remote server > sbtaddc001.bmitest.com:636 > > > > > > - continuing > > INFO:root:The error was: {'info': 'error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed', 'desc ': "Can't contact LDAP server"} > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=bmitest,dc=com > Windows PassSync entry exists, not resetting password > INFO:root:Added new sync agreement, waiting for it to > become > ready . . . > INFO:root:Replication Update in progress: FALSE: > status: 49 - > LDAP error: Invalid credentials: start: 0: end: 0 > INFO:root:Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > [sbttipa001.bmitest.com > > > > >] reports: Update failed! > Status: [49 - LDAP error: Invalid credentials] > INFO:root:Added agreement for other host > sbtaddc001.bmitest.com > > > > > > > Error 49 usually means the password is not correct. You > can use > mozldap ldapsearch to test the connection like this: > > /usr/lib/mozldap/ldapsearch -h dchost -p 636 -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > CN=ipaadmin,CN=users,DC=bmitest,DC=com -w "secretpw" -s > base -b "" > "objectclass=*" > > -- Thanks & Regards > Shan Kumaraswamy > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From shan.sysadm at gmail.com Tue Mar 9 15:26:09 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Tue, 9 Mar 2010 18:26:09 +0300 Subject: [Freeipa-users] AD Sync Error In-Reply-To: <4B96665C.4090700@redhat.com> References: <68b7c79a1002240658w222a5333l12e0c31fe1eaffee@mail.gmail.com> <4B8543D8.3050806@redhat.com> <68b7c79a1003070306j205b0c1bt44c4d3c3dac3b963@mail.gmail.com> <4B951833.5000506@redhat.com> <68b7c79a1003090620u2cb45891h64d920248344cdda@mail.gmail.com> <4B96665C.4090700@redhat.com> Message-ID: <68b7c79a1003090726g235b0783m97c8fcceb71c7316@mail.gmail.com> When I try to run this command I am getting this error: [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h sbtaddc001.bmitest.com-D "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s base -b "" "objectclass=*" ldap_simple_bind: Invalid credentials ldap_simple_bind: additional info: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 52e, v1771 On Tue, Mar 9, 2010 at 6:16 PM, Rich Megginson wrote: > Please keep replies on list > > Shan Kumaraswamy wrote: > >> Rich, >> Does a reverse DNS lookup on the IP address return that hostname? -Yes >> Is Active Directory configured to use/listen to SSL? -Yes, Active >> Directory Cert Auth installed and exported the and verifityed. >> >> Does the cert db /etc/dirsrv/slapd-BMITEST-COM/cert8.db contain the CA >> cert of the windows CA? -yes "Imported CA cert" >> >> certutil -L -d /etc/dirsrv/slapd-BMITEST-COM- Its listing installed cert >> I am trying to creating syn agreement from IPA server using following >> syntex: >> ipa-replica-manage add --winsync --binddn >> CN=Administrator,CN=Users,CN=Accounts,DC=bmitest,DC=com --bindpw secretpw >> --cacert /etc/dirsrv/slapd-BMITEST-COM/dsca.cer sbtaddc001.bmitest.com < >> http://sbtaddc001.bmitest.com> -v >> >> Please corret me where I am doing worng? >> > ldap_simple_bind: Can't contact LDAP server > SSL error -5961 (TCP connection reset by peer.) > > This usually indicates some low level error. Let's try this: > /usr/lib64/mozldap/ldapsearch -h sbtaddc001.bmitest.com -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s base -b "" > "objectclass=*" > > Does that work? > >> >> >> >> On Mon, Mar 8, 2010 at 6:30 PM, Rich Megginson > rmeggins at redhat.com>> wrote: >> >> Shan Kumaraswamy wrote: >> >> Hi Rich, >> >> Sorry for the delay replay, after I executed your command I am >> getting the following error from my directory server. Please >> help me to resolve this error. >> >> [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h >> sbtaddc001.bmitest.com >> > > -p 636 -Z -P >> >> /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D >> CN=administrator,CN=users,DC=bmitest,DC=com -w "secretpw" -s >> base -b "" "objectclass=*" >> >> ldap_simple_bind: Can't contact LDAP server >> SSL error -5961 (TCP connection reset by peer.) >> >> Is sbtaddc001.bmitest.com >> > >> >> the real, registered DNS address for the Active Directory server? >> On both the linux machine and the windows machine? >> Does a reverse DNS lookup on the IP address return that hostname? >> Is Active Directory configured to use/listen to SSL? >> Does the cert db /etc/dirsrv/slapd-BMITEST-COM/cert8.db contain >> the CA cert of the windows CA? >> certutil -L -d /etc/dirsrv/slapd-BMITEST-COM >> >> >> >> On Wed, Feb 24, 2010 at 6:20 PM, Rich Megginson >> >> >> wrote: >> >> Shan Kumaraswamy wrote: >> >> Dear All, >> I am facing the AD Sync issue with FreeIPA to Active >> Directory, and as per the redhat-ds doc I have done all the >> settings from AD front. please help me to resolve this >> issue. >> And find the below error message: >> [root at sbttipa001 ~]# ipa-replica-manage add --winsync >> --binddn CN=ipaadmin,CN=users,DC=bmitest,DC=com --bindpw >> secretpw --ca cert /etc/dirsrv/slapd-BMITEST-COM/adsync.cer >> sbtaddc001.bmitest.com >> >> > >> >> > -v --passsync bmi.123 >> >> Directory Manager password: >> INFO:root:Shutting down dirsrv: >> BMITEST-COM... >> [ OK ] >> INFO:root: >> INFO:root: >> INFO:root: >> INFO:root:Starting dirsrv: >> BMITEST-COM... >> [ OK ] >> INFO:root: >> INFO:root:Added CA certificate >> /etc/dirsrv/slapd-BMITEST-COM/adsync.cer to certificate >> database for sbttipa001.bmitest.com >> >> >> > >> > >> >> INFO:root:Restarted directory server >> sbttipa001.bmitest.com >> >> > >> > >> >> INFO:root:Could not validate connection to remote server >> sbtaddc001.bmitest.com:636 >> >> >> >> > >> > - continuing >> >> INFO:root:The error was: {'info': 'error:14090086:SSL >> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify >> failed', 'desc ': "Can't contact LDAP server"} >> The user for the Windows PassSync service is >> uid=passsync,cn=sysaccounts,cn=etc,dc=bmitest,dc=com >> Windows PassSync entry exists, not resetting password >> INFO:root:Added new sync agreement, waiting for it to >> become >> ready . . . >> INFO:root:Replication Update in progress: FALSE: >> status: 49 - >> LDAP error: Invalid credentials: start: 0: end: 0 >> INFO:root:Agreement is ready, starting replication . . . >> Starting replication, please wait until this has completed. >> [sbttipa001.bmitest.com >> >> > >> >> >] reports: Update failed! >> Status: [49 - LDAP error: Invalid credentials] >> INFO:root:Added agreement for other host >> sbtaddc001.bmitest.com >> >> > >> > >> >> >> Error 49 usually means the password is not correct. You >> can use >> mozldap ldapsearch to test the connection like this: >> >> /usr/lib/mozldap/ldapsearch -h dchost -p 636 -Z -P >> /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D >> CN=ipaadmin,CN=users,DC=bmitest,DC=com -w "secretpw" -s >> base -b "" >> "objectclass=*" >> >> -- Thanks & Regards >> Shan Kumaraswamy >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> >> > > >> >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> >> >> -- Thanks & Regards >> Shan Kumaraswamy >> >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Mar 9 15:32:04 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 09 Mar 2010 08:32:04 -0700 Subject: [Freeipa-users] AD Sync Error In-Reply-To: <68b7c79a1003090726g235b0783m97c8fcceb71c7316@mail.gmail.com> References: <68b7c79a1002240658w222a5333l12e0c31fe1eaffee@mail.gmail.com> <4B8543D8.3050806@redhat.com> <68b7c79a1003070306j205b0c1bt44c4d3c3dac3b963@mail.gmail.com> <4B951833.5000506@redhat.com> <68b7c79a1003090620u2cb45891h64d920248344cdda@mail.gmail.com> <4B96665C.4090700@redhat.com> <68b7c79a1003090726g235b0783m97c8fcceb71c7316@mail.gmail.com> Message-ID: <4B9669F4.5000004@redhat.com> Shan Kumaraswamy wrote: > When I try to run this command I am getting this error: > > [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s base -b > "" "objectclass=*" > ldap_simple_bind: Invalid credentials > ldap_simple_bind: additional info: 80090308: LdapErr: DSID-0C0903AA, > comment: AcceptSecurityContext error, data 52e, v1771 You are not providing the correct password. > > > > On Tue, Mar 9, 2010 at 6:16 PM, Rich Megginson > wrote: > > Please keep replies on list > > Shan Kumaraswamy wrote: > > Rich, > Does a reverse DNS lookup on the IP address return that > hostname? -Yes > Is Active Directory configured to use/listen to SSL? -Yes, > Active Directory Cert Auth installed and exported the and > verifityed. > > Does the cert db /etc/dirsrv/slapd-BMITEST-COM/cert8.db > contain the CA cert of the windows CA? -yes "Imported CA cert" > > certutil -L -d /etc/dirsrv/slapd-BMITEST-COM- Its listing > installed cert > I am trying to creating syn agreement from IPA server using > following syntex: > ipa-replica-manage add --winsync --binddn > CN=Administrator,CN=Users,CN=Accounts,DC=bmitest,DC=com > --bindpw secretpw --cacert > /etc/dirsrv/slapd-BMITEST-COM/dsca.cer sbtaddc001.bmitest.com > > > -v > > Please corret me where I am doing worng? > > ldap_simple_bind: Can't contact LDAP server > SSL error -5961 (TCP connection reset by peer.) > > This usually indicates some low level error. Let's try this: > /usr/lib64/mozldap/ldapsearch -h sbtaddc001.bmitest.com > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s > base -b "" "objectclass=*" > > Does that work? > > > > > On Mon, Mar 8, 2010 at 6:30 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > Hi Rich, > > Sorry for the delay replay, after I executed your > command I am > getting the following error from my directory server. > Please > help me to resolve this error. > > [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > -p 636 -Z -P > > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > CN=administrator,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" "objectclass=*" > > ldap_simple_bind: Can't contact LDAP server > SSL error -5961 (TCP connection reset by peer.) > > Is sbtaddc001.bmitest.com > > > > > > the real, registered DNS address for the Active Directory > server? > On both the linux machine and the windows machine? > Does a reverse DNS lookup on the IP address return that > hostname? > Is Active Directory configured to use/listen to SSL? > Does the cert db /etc/dirsrv/slapd-BMITEST-COM/cert8.db contain > the CA cert of the windows CA? > certutil -L -d /etc/dirsrv/slapd-BMITEST-COM > > > > On Wed, Feb 24, 2010 at 6:20 PM, Rich Megginson > > > > >>> wrote: > > Shan Kumaraswamy wrote: > > Dear All, > I am facing the AD Sync issue with FreeIPA to Active > Directory, and as per the redhat-ds doc I have > done all the > settings from AD front. please help me to > resolve this > issue. > And find the below error message: > [root at sbttipa001 ~]# ipa-replica-manage add > --winsync > --binddn CN=ipaadmin,CN=users,DC=bmitest,DC=com > --bindpw > secretpw --ca cert > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer > sbtaddc001.bmitest.com > > > > > > > -v --passsync > bmi.123 > > Directory Manager password: > INFO:root:Shutting down dirsrv: > BMITEST-COM... > [ OK ] > INFO:root: > INFO:root: > INFO:root: > INFO:root:Starting dirsrv: > BMITEST-COM... > [ OK ] > INFO:root: > INFO:root:Added CA certificate > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer to > certificate > database for sbttipa001.bmitest.com > > > > > > > > > INFO:root:Restarted directory server > sbttipa001.bmitest.com > > > > > > > > INFO:root:Could not validate connection to > remote server > sbtaddc001.bmitest.com:636 > > > > > > > > - continuing > > INFO:root:The error was: {'info': > 'error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', 'desc ': "Can't contact LDAP server"} > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=bmitest,dc=com > Windows PassSync entry exists, not resetting > password > INFO:root:Added new sync agreement, waiting for > it to > become > ready . . . > INFO:root:Replication Update in progress: FALSE: > status: 49 - > LDAP error: Invalid credentials: start: 0: end: 0 > INFO:root:Agreement is ready, starting > replication . . . > Starting replication, please wait until this has > completed. > [sbttipa001.bmitest.com > > > > > > > >] reports: > Update failed! > Status: [49 - LDAP error: Invalid credentials] > INFO:root:Added agreement for other host > sbtaddc001.bmitest.com > > > > > > > > > Error 49 usually means the password is not correct. You > can use > mozldap ldapsearch to test the connection like this: > > /usr/lib/mozldap/ldapsearch -h dchost -p 636 -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > CN=ipaadmin,CN=users,DC=bmitest,DC=com -w "secretpw" -s > base -b "" > "objectclass=*" > > -- Thanks & Regards > Shan Kumaraswamy > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > > > > > >> > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From shan.sysadm at gmail.com Tue Mar 9 15:36:20 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Tue, 9 Mar 2010 18:36:20 +0300 Subject: [Freeipa-users] AD Sync Error In-Reply-To: <4B9669F4.5000004@redhat.com> References: <68b7c79a1002240658w222a5333l12e0c31fe1eaffee@mail.gmail.com> <4B8543D8.3050806@redhat.com> <68b7c79a1003070306j205b0c1bt44c4d3c3dac3b963@mail.gmail.com> <4B951833.5000506@redhat.com> <68b7c79a1003090620u2cb45891h64d920248344cdda@mail.gmail.com> <4B96665C.4090700@redhat.com> <68b7c79a1003090726g235b0783m97c8fcceb71c7316@mail.gmail.com> <4B9669F4.5000004@redhat.com> Message-ID: <68b7c79a1003090736o1569df48s7643b96d0122d439@mail.gmail.com> Rich, Your mean the AD Administrator password or IPA admin password? On Tue, Mar 9, 2010 at 6:32 PM, Rich Megginson wrote: > Shan Kumaraswamy wrote: > >> When I try to run this command I am getting this error: >> [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h >> sbtaddc001.bmitest.com -D >> "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s base -b "" >> "objectclass=*" >> >> ldap_simple_bind: Invalid credentials >> ldap_simple_bind: additional info: 80090308: LdapErr: DSID-0C0903AA, >> comment: AcceptSecurityContext error, data 52e, v1771 >> > You are not providing the correct password. > >> >> >> On Tue, Mar 9, 2010 at 6:16 PM, Rich Megginson > rmeggins at redhat.com>> wrote: >> >> Please keep replies on list >> >> Shan Kumaraswamy wrote: >> >> Rich, >> Does a reverse DNS lookup on the IP address return that >> hostname? -Yes >> Is Active Directory configured to use/listen to SSL? -Yes, >> Active Directory Cert Auth installed and exported the and >> verifityed. >> >> Does the cert db /etc/dirsrv/slapd-BMITEST-COM/cert8.db >> contain the CA cert of the windows CA? -yes "Imported CA cert" >> >> certutil -L -d /etc/dirsrv/slapd-BMITEST-COM- Its listing >> installed cert >> I am trying to creating syn agreement from IPA server using >> following syntex: >> ipa-replica-manage add --winsync --binddn >> CN=Administrator,CN=Users,CN=Accounts,DC=bmitest,DC=com >> --bindpw secretpw --cacert >> /etc/dirsrv/slapd-BMITEST-COM/dsca.cer sbtaddc001.bmitest.com >> >> >> > > -v >> >> Please corret me where I am doing worng? >> >> ldap_simple_bind: Can't contact LDAP server >> SSL error -5961 (TCP connection reset by peer.) >> >> This usually indicates some low level error. Let's try this: >> /usr/lib64/mozldap/ldapsearch -h sbtaddc001.bmitest.com >> -D >> >> "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s >> base -b "" "objectclass=*" >> >> Does that work? >> >> >> >> On Mon, Mar 8, 2010 at 6:30 PM, Rich Megginson >> >> >> wrote: >> >> Shan Kumaraswamy wrote: >> >> Hi Rich, >> >> Sorry for the delay replay, after I executed your >> command I am >> getting the following error from my directory server. >> Please >> help me to resolve this error. >> >> [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h >> sbtaddc001.bmitest.com >> >> > >> > -p 636 -Z -P >> >> /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D >> CN=administrator,CN=users,DC=bmitest,DC=com -w >> "secretpw" -s >> base -b "" "objectclass=*" >> >> ldap_simple_bind: Can't contact LDAP server >> SSL error -5961 (TCP connection reset by peer.) >> >> Is sbtaddc001.bmitest.com >> >> > >> > >> >> the real, registered DNS address for the Active Directory >> server? >> On both the linux machine and the windows machine? >> Does a reverse DNS lookup on the IP address return that >> hostname? >> Is Active Directory configured to use/listen to SSL? >> Does the cert db /etc/dirsrv/slapd-BMITEST-COM/cert8.db contain >> the CA cert of the windows CA? >> certutil -L -d /etc/dirsrv/slapd-BMITEST-COM >> >> >> On Wed, Feb 24, 2010 at 6:20 PM, Rich Megginson >> >> > >> > > >>> wrote: >> >> Shan Kumaraswamy wrote: >> >> Dear All, >> I am facing the AD Sync issue with FreeIPA to Active >> Directory, and as per the redhat-ds doc I have >> done all the >> settings from AD front. please help me to >> resolve this >> issue. >> And find the below error message: >> [root at sbttipa001 ~]# ipa-replica-manage add >> --winsync >> --binddn CN=ipaadmin,CN=users,DC=bmitest,DC=com >> --bindpw >> secretpw --ca cert >> /etc/dirsrv/slapd-BMITEST-COM/adsync.cer >> sbtaddc001.bmitest.com >> >> >> > >> >> >> > -v --passsync >> bmi.123 >> >> Directory Manager password: >> INFO:root:Shutting down dirsrv: >> BMITEST-COM... >> [ OK ] >> INFO:root: >> INFO:root: >> INFO:root: >> INFO:root:Starting dirsrv: >> BMITEST-COM... >> [ OK ] >> INFO:root: >> INFO:root:Added CA certificate >> /etc/dirsrv/slapd-BMITEST-COM/adsync.cer to >> certificate >> database for sbttipa001.bmitest.com >> >> >> >> > >> >> > >> >> INFO:root:Restarted directory server >> sbttipa001.bmitest.com >> >> >> > >> >> > >> >> INFO:root:Could not validate connection to >> remote server >> sbtaddc001.bmitest.com:636 >> >> >> >> >> > >> >> > - continuing >> >> INFO:root:The error was: {'info': >> 'error:14090086:SSL >> routines:SSL3_GET_SERVER_CERTIFICATE:certificate >> verify >> failed', 'desc ': "Can't contact LDAP server"} >> The user for the Windows PassSync service is >> uid=passsync,cn=sysaccounts,cn=etc,dc=bmitest,dc=com >> Windows PassSync entry exists, not resetting >> password >> INFO:root:Added new sync agreement, waiting for >> it to >> become >> ready . . . >> INFO:root:Replication Update in progress: FALSE: >> status: 49 - >> LDAP error: Invalid credentials: start: 0: end: 0 >> INFO:root:Agreement is ready, starting >> replication . . . >> Starting replication, please wait until this has >> completed. >> [sbttipa001.bmitest.com >> >> >> >> > >> >> >> >] reports: >> Update failed! >> Status: [49 - LDAP error: Invalid credentials] >> INFO:root:Added agreement for other host >> sbtaddc001.bmitest.com >> >> >> > >> >> > >> >> >> Error 49 usually means the password is not correct. You >> can use >> mozldap ldapsearch to test the connection like this: >> >> /usr/lib/mozldap/ldapsearch -h dchost -p 636 -Z -P >> /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D >> CN=ipaadmin,CN=users,DC=bmitest,DC=com -w "secretpw" -s >> base -b "" >> "objectclass=*" >> >> -- Thanks & Regards >> Shan Kumaraswamy >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> >> > > >> > >> > >> >> >> >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> >> >> -- Thanks & Regards >> Shan Kumaraswamy >> >> >> >> >> >> -- Thanks & Regards >> Shan Kumaraswamy >> >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Mar 9 15:38:44 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 09 Mar 2010 08:38:44 -0700 Subject: [Freeipa-users] AD Sync Error In-Reply-To: <68b7c79a1003090736o1569df48s7643b96d0122d439@mail.gmail.com> References: <68b7c79a1002240658w222a5333l12e0c31fe1eaffee@mail.gmail.com> <4B8543D8.3050806@redhat.com> <68b7c79a1003070306j205b0c1bt44c4d3c3dac3b963@mail.gmail.com> <4B951833.5000506@redhat.com> <68b7c79a1003090620u2cb45891h64d920248344cdda@mail.gmail.com> <4B96665C.4090700@redhat.com> <68b7c79a1003090726g235b0783m97c8fcceb71c7316@mail.gmail.com> <4B9669F4.5000004@redhat.com> <68b7c79a1003090736o1569df48s7643b96d0122d439@mail.gmail.com> Message-ID: <4B966B84.9000601@redhat.com> Shan Kumaraswamy wrote: > Rich, > Your mean the AD Administrator password or IPA admin password? AD I'm trying to find out why IPA cannot make a connection to AD. So the hostname should be the AD hostname, and the -D (binddn) should be the DN of the user that IPA uses to bind to AD, and the password should be the password for that user. > > On Tue, Mar 9, 2010 at 6:32 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > When I try to run this command I am getting this error: > [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s > base -b "" "objectclass=*" > > ldap_simple_bind: Invalid credentials > ldap_simple_bind: additional info: 80090308: LdapErr: > DSID-0C0903AA, comment: AcceptSecurityContext error, data 52e, > v1771 > > You are not providing the correct password. > > > > On Tue, Mar 9, 2010 at 6:16 PM, Rich Megginson > > >> wrote: > > Please keep replies on list > > Shan Kumaraswamy wrote: > > Rich, > Does a reverse DNS lookup on the IP address return that > hostname? -Yes > Is Active Directory configured to use/listen to SSL? -Yes, > Active Directory Cert Auth installed and exported the and > verifityed. > > Does the cert db /etc/dirsrv/slapd-BMITEST-COM/cert8.db > contain the CA cert of the windows CA? -yes "Imported > CA cert" > > certutil -L -d /etc/dirsrv/slapd-BMITEST-COM- Its listing > installed cert > I am trying to creating syn agreement from IPA server using > following syntex: > ipa-replica-manage add --winsync --binddn > CN=Administrator,CN=Users,CN=Accounts,DC=bmitest,DC=com > --bindpw secretpw --cacert > /etc/dirsrv/slapd-BMITEST-COM/dsca.cer > sbtaddc001.bmitest.com > > > > > -v > > Please corret me where I am doing worng? > > ldap_simple_bind: Can't contact LDAP server > SSL error -5961 (TCP connection reset by peer.) > > This usually indicates some low level error. Let's try this: > /usr/lib64/mozldap/ldapsearch -h sbtaddc001.bmitest.com > > -D > > "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s > base -b "" "objectclass=*" > > Does that work? > > > > On Mon, Mar 8, 2010 at 6:30 PM, Rich Megginson > > > > >>> wrote: > > Shan Kumaraswamy wrote: > > Hi Rich, > > Sorry for the delay replay, after I executed your > command I am > getting the following error from my directory > server. > Please > help me to resolve this error. > > [root at sbttipa001 ~]# > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > > -p 636 -Z -P > > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > CN=administrator,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" "objectclass=*" > > ldap_simple_bind: Can't contact LDAP server > SSL error -5961 (TCP connection reset by > peer.) > > Is sbtaddc001.bmitest.com > > > > > > > > the real, registered DNS address for the Active > Directory > server? > On both the linux machine and the windows machine? > Does a reverse DNS lookup on the IP address return that > hostname? > Is Active Directory configured to use/listen to SSL? > Does the cert db > /etc/dirsrv/slapd-BMITEST-COM/cert8.db contain > the CA cert of the windows CA? > certutil -L -d /etc/dirsrv/slapd-BMITEST-COM > > > On Wed, Feb 24, 2010 at 6:20 PM, Rich Megginson > > > >> > > > > >>>> wrote: > > Shan Kumaraswamy wrote: > > Dear All, > I am facing the AD Sync issue with > FreeIPA to Active > Directory, and as per the redhat-ds doc I > have > done all the > settings from AD front. please help me to > resolve this > issue. > And find the below error message: > [root at sbttipa001 ~]# ipa-replica-manage add > --winsync > --binddn > CN=ipaadmin,CN=users,DC=bmitest,DC=com > --bindpw > secretpw --ca cert > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer > sbtaddc001.bmitest.com > > > > > > > > > > -v > --passsync > bmi.123 > > Directory Manager password: > INFO:root:Shutting down dirsrv: > BMITEST-COM... > [ OK ] > INFO:root: > INFO:root: > INFO:root: > INFO:root:Starting dirsrv: > BMITEST-COM... > [ OK ] > INFO:root: > INFO:root:Added CA certificate > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer to > certificate > database for sbttipa001.bmitest.com > > > > > > > > > > > INFO:root:Restarted directory server > sbttipa001.bmitest.com > > > > > > > > > > INFO:root:Could not validate connection to > remote server > sbtaddc001.bmitest.com:636 > > > > > > > > > > - > continuing > > INFO:root:The error was: {'info': > 'error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', 'desc ': "Can't contact LDAP > server"} > The user for the Windows PassSync service is > > uid=passsync,cn=sysaccounts,cn=etc,dc=bmitest,dc=com > Windows PassSync entry exists, not resetting > password > INFO:root:Added new sync agreement, > waiting for > it to > become > ready . . . > INFO:root:Replication Update in progress: > FALSE: > status: 49 - > LDAP error: Invalid credentials: start: > 0: end: 0 > INFO:root:Agreement is ready, starting > replication . . . > Starting replication, please wait until > this has > completed. > [sbttipa001.bmitest.com > > > > > > > > > >] reports: > Update failed! > Status: [49 - LDAP error: Invalid > credentials] > INFO:root:Added agreement for other host > sbtaddc001.bmitest.com > > > > > > > > > > > > Error 49 usually means the password is not > correct. You > can use > mozldap ldapsearch to test the connection > like this: > > /usr/lib/mozldap/ldapsearch -h dchost -p 636 > -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > CN=ipaadmin,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" > "objectclass=*" > > -- Thanks & Regards > Shan Kumaraswamy > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > > > > > >> > > > > > >>> > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From shan.sysadm at gmail.com Tue Mar 9 15:42:46 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Tue, 9 Mar 2010 18:42:46 +0300 Subject: [Freeipa-users] AD Sync Error In-Reply-To: <4B966B84.9000601@redhat.com> References: <68b7c79a1002240658w222a5333l12e0c31fe1eaffee@mail.gmail.com> <4B8543D8.3050806@redhat.com> <68b7c79a1003070306j205b0c1bt44c4d3c3dac3b963@mail.gmail.com> <4B951833.5000506@redhat.com> <68b7c79a1003090620u2cb45891h64d920248344cdda@mail.gmail.com> <4B96665C.4090700@redhat.com> <68b7c79a1003090726g235b0783m97c8fcceb71c7316@mail.gmail.com> <4B9669F4.5000004@redhat.com> <68b7c79a1003090736o1569df48s7643b96d0122d439@mail.gmail.com> <4B966B84.9000601@redhat.com> Message-ID: <68b7c79a1003090742x4589d2pfa7566cef76ea56f@mail.gmail.com> Rich again some errors: [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h sbtaddc001.bmitest.com-D "CN=administrator,CN=users,DC=bmitest,DC=com" -w "Str1ve2XL" -s base -b "" "objectclass=*" ldap_simple_bind: Strong authentication required ldap_simple_bind: additional info: 00002028: LdapErr: DSID-0C0901FC, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v1771 On Tue, Mar 9, 2010 at 6:38 PM, Rich Megginson wrote: > Shan Kumaraswamy wrote: > >> Rich, >> Your mean the AD Administrator password or IPA admin password? >> > AD > > I'm trying to find out why IPA cannot make a connection to AD. So the > hostname should be the AD hostname, and the -D (binddn) should be the DN of > the user that IPA uses to bind to AD, and the password should be the > password for that user. > >> >> On Tue, Mar 9, 2010 at 6:32 PM, Rich Megginson > rmeggins at redhat.com>> wrote: >> >> Shan Kumaraswamy wrote: >> >> When I try to run this command I am getting this error: >> [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h >> sbtaddc001.bmitest.com >> > > -D >> >> "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s >> base -b "" "objectclass=*" >> >> ldap_simple_bind: Invalid credentials >> ldap_simple_bind: additional info: 80090308: LdapErr: >> DSID-0C0903AA, comment: AcceptSecurityContext error, data 52e, >> v1771 >> >> You are not providing the correct password. >> >> >> >> On Tue, Mar 9, 2010 at 6:16 PM, Rich Megginson >> >> >> wrote: >> >> Please keep replies on list >> >> Shan Kumaraswamy wrote: >> >> Rich, >> Does a reverse DNS lookup on the IP address return that >> hostname? -Yes >> Is Active Directory configured to use/listen to SSL? -Yes, >> Active Directory Cert Auth installed and exported the and >> verifityed. >> >> Does the cert db /etc/dirsrv/slapd-BMITEST-COM/cert8.db >> contain the CA cert of the windows CA? -yes "Imported >> CA cert" >> >> certutil -L -d /etc/dirsrv/slapd-BMITEST-COM- Its listing >> installed cert >> I am trying to creating syn agreement from IPA server using >> following syntex: >> ipa-replica-manage add --winsync --binddn >> CN=Administrator,CN=Users,CN=Accounts,DC=bmitest,DC=com >> --bindpw secretpw --cacert >> /etc/dirsrv/slapd-BMITEST-COM/dsca.cer >> sbtaddc001.bmitest.com >> >> >> > >> > -v >> >> Please corret me where I am doing worng? >> >> ldap_simple_bind: Can't contact LDAP server >> SSL error -5961 (TCP connection reset by peer.) >> >> This usually indicates some low level error. Let's try this: >> /usr/lib64/mozldap/ldapsearch -h sbtaddc001.bmitest.com >> >> -D >> >> "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s >> base -b "" "objectclass=*" >> >> Does that work? >> >> >> On Mon, Mar 8, 2010 at 6:30 PM, Rich Megginson >> >> > >> > > >>> wrote: >> >> Shan Kumaraswamy wrote: >> >> Hi Rich, >> >> Sorry for the delay replay, after I executed your >> command I am >> getting the following error from my directory >> server. >> Please >> help me to resolve this error. >> >> [root at sbttipa001 ~]# >> /usr/lib64/mozldap/ldapsearch -h >> sbtaddc001.bmitest.com >> >> >> > >> >> > -p 636 -Z -P >> >> /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D >> CN=administrator,CN=users,DC=bmitest,DC=com -w >> "secretpw" -s >> base -b "" "objectclass=*" >> >> ldap_simple_bind: Can't contact LDAP server >> SSL error -5961 (TCP connection reset by >> peer.) >> >> Is sbtaddc001.bmitest.com >> >> >> > >> >> > >> >> the real, registered DNS address for the Active >> Directory >> server? >> On both the linux machine and the windows machine? >> Does a reverse DNS lookup on the IP address return that >> hostname? >> Is Active Directory configured to use/listen to SSL? >> Does the cert db >> /etc/dirsrv/slapd-BMITEST-COM/cert8.db contain >> the CA cert of the windows CA? >> certutil -L -d /etc/dirsrv/slapd-BMITEST-COM >> >> On Wed, Feb 24, 2010 at 6:20 >> PM, Rich Megginson >> > > > >> > > >> >> > >> > > > >> > >>>> wrote: >> >> Shan Kumaraswamy wrote: >> >> Dear All, >> I am facing the AD Sync issue with >> FreeIPA to Active >> Directory, and as per the redhat-ds doc I >> have >> done all the >> settings from AD front. please help me to >> resolve this >> issue. >> And find the below error message: >> [root at sbttipa001 ~]# ipa-replica-manage add >> --winsync >> --binddn >> CN=ipaadmin,CN=users,DC=bmitest,DC=com >> --bindpw >> secretpw --ca cert >> /etc/dirsrv/slapd-BMITEST-COM/adsync.cer >> sbtaddc001.bmitest.com >> >> >> >> >> > >> >> >> >> > -v >> --passsync >> bmi.123 >> >> Directory Manager password: >> INFO:root:Shutting down dirsrv: >> BMITEST-COM... >> [ OK ] >> INFO:root: >> INFO:root: >> INFO:root: >> INFO:root:Starting dirsrv: >> BMITEST-COM... >> [ OK ] >> INFO:root: >> INFO:root:Added CA certificate >> /etc/dirsrv/slapd-BMITEST-COM/adsync.cer to >> certificate >> database for sbttipa001.bmitest.com >> >> >> >> >> > >> >> >> > >> >> INFO:root:Restarted directory server >> sbttipa001.bmitest.com >> >> >> >> > >> >> >> > >> >> INFO:root:Could not validate connection to >> remote server >> sbtaddc001.bmitest.com:636 >> >> >> >> >> >> > >> >> >> > - >> continuing >> >> INFO:root:The error was: {'info': >> 'error:14090086:SSL >> >> routines:SSL3_GET_SERVER_CERTIFICATE:certificate >> verify >> failed', 'desc ': "Can't contact LDAP >> server"} >> The user for the Windows PassSync service is >> >> uid=passsync,cn=sysaccounts,cn=etc,dc=bmitest,dc=com >> Windows PassSync entry exists, not resetting >> password >> INFO:root:Added new sync agreement, >> waiting for >> it to >> become >> ready . . . >> INFO:root:Replication Update in progress: >> FALSE: >> status: 49 - >> LDAP error: Invalid credentials: start: >> 0: end: 0 >> INFO:root:Agreement is ready, starting >> replication . . . >> Starting replication, please wait until >> this has >> completed. >> [sbttipa001.bmitest.com >> >> >> >> >> > >> >> >> >> >] reports: >> Update failed! >> Status: [49 - LDAP error: Invalid >> credentials] >> INFO:root:Added agreement for other host >> sbtaddc001.bmitest.com >> >> >> >> >> > >> >> >> > >> >> >> Error 49 usually means the password is not >> correct. You >> can use >> mozldap ldapsearch to test the connection >> like this: >> >> /usr/lib/mozldap/ldapsearch -h dchost -p 636 >> -Z -P >> /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D >> CN=ipaadmin,CN=users,DC=bmitest,DC=com -w >> "secretpw" -s >> base -b "" >> "objectclass=*" >> >> -- Thanks & Regards >> Shan Kumaraswamy >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> >> > > >> > >> > >> >> > >> > > >> > >> > >>> >> >> >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> >> >> -- Thanks & Regards >> Shan Kumaraswamy >> >> >> >> >> >> -- Thanks & Regards >> Shan Kumaraswamy >> >> >> >> >> >> -- Thanks & Regards >> Shan Kumaraswamy >> >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Tue Mar 9 15:55:51 2010 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 9 Mar 2010 10:55:51 -0500 Subject: [Freeipa-users] Needed_Preauth Issue In-Reply-To: <4B959309.4070405@adurotec.com> References: <4B959309.4070405@adurotec.com> Message-ID: <20100309105551.4cd69942@willson.li.ssimo.org> On Mon, 08 Mar 2010 18:15:05 -0600 David Christensen wrote: > I have two servers that I have installed the ipa-client on, both of > these servers are configured the same way however one is providing > single sign on, the other is not and instead prompts for a password > when a user logs in > > I did verify that DNS is configured correctly for both servers. I > issue kinit prior to logging into either server and verified that I > have a valid ticket for both servers, but the failing server remains > unchanged. When I look at the krb5kdc.log I see the following for the > server that is prompting for a password: > > Mar 08 23:25:53 ipa1.example.net krb5kdc[12320](info): AS_REQ (12 > etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.200.3.131: > NEEDED_PREAUTH: davidc at EXAMPLE.NET for > krbtgt/EXAMPLE.NET at EXAMPLE.NET, Additional pre-authentication required > > Mar 08 23:25:53 ipa1.example.net krb5kdc[12320](info): AS_REQ (12 > etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.200.3.131: ISSUE: > authtime 1268090753, etypes {rep=18 tkt=18 ses=18}, > davidc at EXAMPLE.NET for krbtgt/EXAMPLE.NET at EXAMPLE.NET > > Where else should I look to find the root cause of this issue? What > typically causes this type of symptom? NEEDED_PREAUTH is perfectly natural, you have it for every principal as it is our default. If you don't see your client requesting a ticket for host/@EXAMPLE.NET then that is going to be an issue. If you obtained a ticket for your server and it still falls back to password auth I suggest looking at the server's logs. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Tue Mar 9 16:03:00 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 09 Mar 2010 09:03:00 -0700 Subject: [Freeipa-users] AD Sync Error In-Reply-To: <68b7c79a1003090742x4589d2pfa7566cef76ea56f@mail.gmail.com> References: <68b7c79a1002240658w222a5333l12e0c31fe1eaffee@mail.gmail.com> <4B8543D8.3050806@redhat.com> <68b7c79a1003070306j205b0c1bt44c4d3c3dac3b963@mail.gmail.com> <4B951833.5000506@redhat.com> <68b7c79a1003090620u2cb45891h64d920248344cdda@mail.gmail.com> <4B96665C.4090700@redhat.com> <68b7c79a1003090726g235b0783m97c8fcceb71c7316@mail.gmail.com> <4B9669F4.5000004@redhat.com> <68b7c79a1003090736o1569df48s7643b96d0122d439@mail.gmail.com> <4B966B84.9000601@redhat.com> <68b7c79a1003090742x4589d2pfa7566cef76ea56f@mail.gmail.com> Message-ID: <4B967134.8050308@redhat.com> Shan Kumaraswamy wrote: > Rich again some errors: > > > [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w "Str1ve2XL" -s base > -b "" "objectclass=*" > ldap_simple_bind: Strong authentication required > ldap_simple_bind: additional info: 00002028: LdapErr: DSID-0C0901FC, > comment: The server requires binds to turn on integrity checking if > SSL\TLS are not already active on the connection, data 0, v1771 If this is your real password, as simo said, please change it immediately. So at least you are talking to the AD server now. It is telling you that it will not accept a bind using a clear text password over an insecure connection - that is, try using SSL as we did previously: /usr/lib64/mozldap/ldapsearch -ZZ -P /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h sbtaddc001.bmitest.com -D "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s base -b "" "objectclass=*" > > > > On Tue, Mar 9, 2010 at 6:38 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Rich, > Your mean the AD Administrator password or IPA admin password? > > AD > > I'm trying to find out why IPA cannot make a connection to AD. So > the hostname should be the AD hostname, and the -D (binddn) should > be the DN of the user that IPA uses to bind to AD, and the > password should be the password for that user. > > > On Tue, Mar 9, 2010 at 6:32 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > When I try to run this command I am getting this error: > [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > -D > > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > ldap_simple_bind: Invalid credentials > ldap_simple_bind: additional info: 80090308: LdapErr: > DSID-0C0903AA, comment: AcceptSecurityContext error, > data 52e, > v1771 > > You are not providing the correct password. > > > > On Tue, Mar 9, 2010 at 6:16 PM, Rich Megginson > > > > >>> wrote: > > Please keep replies on list > > Shan Kumaraswamy wrote: > > Rich, > Does a reverse DNS lookup on the IP address > return that > hostname? -Yes > Is Active Directory configured to use/listen to > SSL? -Yes, > Active Directory Cert Auth installed and > exported the and > verifityed. > > Does the cert db > /etc/dirsrv/slapd-BMITEST-COM/cert8.db > contain the CA cert of the windows CA? -yes > "Imported > CA cert" > > certutil -L -d /etc/dirsrv/slapd-BMITEST-COM- > Its listing > installed cert > I am trying to creating syn agreement from IPA > server using > following syntex: > ipa-replica-manage add --winsync --binddn > > CN=Administrator,CN=Users,CN=Accounts,DC=bmitest,DC=com > --bindpw secretpw --cacert > /etc/dirsrv/slapd-BMITEST-COM/dsca.cer > sbtaddc001.bmitest.com > > > > > > > -v > > Please corret me where I am doing worng? > > ldap_simple_bind: Can't contact LDAP server > SSL error -5961 (TCP connection reset by peer.) > > This usually indicates some low level error. Let's > try this: > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > -D > > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > Does that work? > > > On Mon, Mar 8, 2010 at 6:30 PM, Rich Megginson > > > >> > > > > >>>> wrote: > > Shan Kumaraswamy wrote: > > Hi Rich, > > Sorry for the delay replay, after I > executed your > command I am > getting the following error from my directory > server. > Please > help me to resolve this error. > > [root at sbttipa001 ~]# > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > > > > > -p 636 > -Z -P > > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > > CN=administrator,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" "objectclass=*" > > ldap_simple_bind: Can't contact LDAP server > SSL error -5961 (TCP connection > reset by > peer.) > > Is sbtaddc001.bmitest.com > > > > > > > > > > > the real, registered DNS address for the Active > Directory > server? > On both the linux machine and the windows > machine? > Does a reverse DNS lookup on the IP address > return that > hostname? > Is Active Directory configured to use/listen > to SSL? > Does the cert db > /etc/dirsrv/slapd-BMITEST-COM/cert8.db contain > the CA cert of the windows CA? > certutil -L -d /etc/dirsrv/slapd-BMITEST-COM > > On Wed, Feb 24, > 2010 at 6:20 PM, Rich Megginson > > > > >> > > > > >>> > > > > > >> > > > > >>>>> wrote: > > Shan Kumaraswamy wrote: > > Dear All, > I am facing the AD Sync issue with > FreeIPA to Active > Directory, and as per the > redhat-ds doc I > have > done all the > settings from AD front. please > help me to > resolve this > issue. > And find the below error message: > [root at sbttipa001 ~]# > ipa-replica-manage add > --winsync > --binddn > CN=ipaadmin,CN=users,DC=bmitest,DC=com > --bindpw > secretpw --ca cert > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer > sbtaddc001.bmitest.com > > > > > > > > > > > > -v > --passsync > bmi.123 > > Directory Manager password: > INFO:root:Shutting down dirsrv: > BMITEST-COM... > [ OK ] > INFO:root: > INFO:root: > INFO:root: > INFO:root:Starting dirsrv: > BMITEST-COM... > [ OK ] > INFO:root: > INFO:root:Added CA certificate > > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer to > certificate > database for > sbttipa001.bmitest.com > > > > > > > > > > > > INFO:root:Restarted directory server > sbttipa001.bmitest.com > > > > > > > > > > > > > INFO:root:Could not validate > connection to > remote server > sbtaddc001.bmitest.com:636 > > > > > > > > > > > > > - > continuing > > INFO:root:The error was: {'info': > 'error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', 'desc ': "Can't contact LDAP > server"} > The user for the Windows PassSync > service is > > uid=passsync,cn=sysaccounts,cn=etc,dc=bmitest,dc=com > Windows PassSync entry exists, not > resetting > password > INFO:root:Added new sync agreement, > waiting for > it to > become > ready . . . > INFO:root:Replication Update in > progress: > FALSE: > status: 49 - > LDAP error: Invalid credentials: > start: > 0: end: 0 > INFO:root:Agreement is ready, starting > replication . . . > Starting replication, please wait > until > this has > completed. > [sbttipa001.bmitest.com > > > > > > > > > > > >] > reports: > Update failed! > Status: [49 - LDAP error: Invalid > credentials] > INFO:root:Added agreement for > other host > sbtaddc001.bmitest.com > > > > > > > > > > > > > > Error 49 usually means the password is not > correct. You > can use > mozldap ldapsearch to test the connection > like this: > > /usr/lib/mozldap/ldapsearch -h dchost > -p 636 > -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > CN=ipaadmin,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" > "objectclass=*" > > -- Thanks & Regards > Shan Kumaraswamy > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rmeggins at redhat.com Tue Mar 9 16:38:21 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 09 Mar 2010 09:38:21 -0700 Subject: [Freeipa-users] AD Sync Error In-Reply-To: <68b7c79a1003090814y7a306dc6q42afdee61ee38083@mail.gmail.com> References: <68b7c79a1002240658w222a5333l12e0c31fe1eaffee@mail.gmail.com> <4B951833.5000506@redhat.com> <68b7c79a1003090620u2cb45891h64d920248344cdda@mail.gmail.com> <4B96665C.4090700@redhat.com> <68b7c79a1003090726g235b0783m97c8fcceb71c7316@mail.gmail.com> <4B9669F4.5000004@redhat.com> <68b7c79a1003090736o1569df48s7643b96d0122d439@mail.gmail.com> <4B966B84.9000601@redhat.com> <68b7c79a1003090742x4589d2pfa7566cef76ea56f@mail.gmail.com> <4B967134.8050308@redhat.com> <68b7c79a1003090814y7a306dc6q42afdee61ee38083@mail.gmail.com> Message-ID: <4B96797D.40503@redhat.com> Shan Kumaraswamy wrote: > Yes I can get the output when I ran this step: > > Command: > /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h sbtaddc001.bmitest.com > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -s base -b "" > "objectclass=*" > Output: > > version: 1 > dn: > currentTime: 20100309160730.0Z > subschemaSubentry: > CN=Aggregate,CN=Schema,CN=Configuration,DC=BMITEST,DC=COM > dsServiceName: CN=NTDS > Settings,CN=SBTADDC001,CN=Servers,CN=Bahrain-Site,CN=Si > tes,CN=Configuration,DC=BMITEST,DC=COM > namingContexts: DC=BMITEST,DC=COM > namingContexts: CN=Configuration,DC=BMITEST,DC=COM > namingContexts: CN=Schema,CN=Configuration,DC=BMITEST,DC=COM > namingContexts: DC=DomainDnsZones,DC=BMITEST,DC=COM > namingContexts: DC=ForestDnsZones,DC=BMITEST,DC=COM > defaultNamingContext: DC=BMITEST,DC=COM > schemaNamingContext: CN=Schema,CN=Configuration,DC=BMITEST,DC=COM > configurationNamingContext: CN=Configuration,DC=BMITEST,DC=COM > rootDomainNamingContext: DC=BMITEST,DC=COM > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.2.840.113556.1.4.801 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 1.2.840.113556.1.4.528 > supportedControl: 1.2.840.113556.1.4.417 > supportedControl: 1.2.840.113556.1.4.619 > supportedControl: 1.2.840.113556.1.4.841 > supportedControl: 1.2.840.113556.1.4.529 > supportedControl: 1.2.840.113556.1.4.805 > supportedControl: 1.2.840.113556.1.4.521 > supportedControl: 1.2.840.113556.1.4.970 > supportedControl: 1.2.840.113556.1.4.1338 > supportedControl: 1.2.840.113556.1.4.474 > supportedControl: 1.2.840.113556.1.4.1339 > supportedControl: 1.2.840.113556.1.4.1340 > supportedControl: 1.2.840.113556.1.4.1413 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: 2.16.840.1.113730.3.4.10 > supportedControl: 1.2.840.113556.1.4.1504 > supportedControl: 1.2.840.113556.1.4.1852 > supportedControl: 1.2.840.113556.1.4.802 > supportedControl: 1.2.840.113556.1.4.1907 > supportedControl: 1.2.840.113556.1.4.1948 > supportedControl: 1.2.840.113556.1.4.1974 > supportedControl: 1.2.840.113556.1.4.1341 > supportedControl: 1.2.840.113556.1.4.2026 > supportedLDAPVersion: 3 > supportedLDAPVersion: 2 > supportedLDAPPolicies: MaxPoolThreads > supportedLDAPPolicies: MaxDatagramRecv > supportedLDAPPolicies: MaxReceiveBuffer > supportedLDAPPolicies: InitRecvTimeout > supportedLDAPPolicies: MaxConnections > supportedLDAPPolicies: MaxConnIdleTime > supportedLDAPPolicies: MaxPageSize > supportedLDAPPolicies: MaxQueryDuration > supportedLDAPPolicies: MaxTempTableSize > supportedLDAPPolicies: MaxResultSetSize > supportedLDAPPolicies: MaxNotificationPerConn > supportedLDAPPolicies: MaxValRange > highestCommittedUSN: 905371 > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: DIGEST-MD5 > dnsHostName: SBTADDC001.BMITEST.COM > > > > Please let me know the syntex of IPA Ad sync Ok. Now try it with the ldaps port (-p 636) /usr/lib64/mozldap/ldapsearch -Z -P /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h sbtaddc001.bmitest.com -p 636 -D "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s base -b "" "objectclass=*" > > > > > > > On Tue, Mar 9, 2010 at 7:03 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Rich again some errors: > [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w "Str1ve2XL" > -s base -b "" "objectclass=*" > > ldap_simple_bind: Strong authentication required > ldap_simple_bind: additional info: 00002028: LdapErr: > DSID-0C0901FC, comment: The server requires binds to turn on > integrity checking if SSL\TLS are not already active on the > connection, data 0, v1771 > > If this is your real password, as simo said, please change it > immediately. > > So at least you are talking to the AD server now. It is telling > you that it will not accept a bind using a clear text password > over an insecure connection - that is, try using SSL as we did > previously: > > /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h sbtaddc001.bmitest.com > > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s > base -b "" "objectclass=*" > > > On Tue, Mar 9, 2010 at 6:38 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Your mean the AD Administrator password or IPA admin > password? > > AD > > I'm trying to find out why IPA cannot make a connection to > AD. So > the hostname should be the AD hostname, and the -D (binddn) > should > be the DN of the user that IPA uses to bind to AD, and the > password should be the password for that user. > > > On Tue, Mar 9, 2010 at 6:32 PM, Rich Megginson > > > > >>> wrote: > > Shan Kumaraswamy wrote: > > When I try to run this command I am getting this > error: > [root at sbttipa001 ~]# > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > > -D > > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > ldap_simple_bind: Invalid credentials > ldap_simple_bind: additional info: 80090308: > LdapErr: > DSID-0C0903AA, comment: AcceptSecurityContext error, > data 52e, > v1771 > > You are not providing the correct password. > > > > On Tue, Mar 9, 2010 at 6:16 PM, Rich Megginson > > > >> > > > > >>>> wrote: > > Please keep replies on list > > Shan Kumaraswamy wrote: > > Rich, > Does a reverse DNS lookup on the IP address > return that > hostname? -Yes > Is Active Directory configured to > use/listen to > SSL? -Yes, > Active Directory Cert Auth installed and > exported the and > verifityed. > > Does the cert db > /etc/dirsrv/slapd-BMITEST-COM/cert8.db > contain the CA cert of the windows CA? -yes > "Imported > CA cert" > > certutil -L -d /etc/dirsrv/slapd-BMITEST-COM- > Its listing > installed cert > I am trying to creating syn agreement > from IPA > server using > following syntex: > ipa-replica-manage add --winsync --binddn > > CN=Administrator,CN=Users,CN=Accounts,DC=bmitest,DC=com > --bindpw secretpw --cacert > /etc/dirsrv/slapd-BMITEST-COM/dsca.cer > sbtaddc001.bmitest.com > > > > > > > > > -v > > Please corret me where I am doing worng? > > ldap_simple_bind: Can't contact LDAP server > SSL error -5961 (TCP connection reset by > peer.) > > This usually indicates some low level error. > Let's > try this: > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > -D > > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > Does that work? > > On Mon, Mar 8, 2010 > at 6:30 PM, Rich Megginson > > > > >> > > > > >>> > > > > > >> > > > > >>>>> wrote: > > Shan Kumaraswamy wrote: > > Hi Rich, > > Sorry for the delay replay, after I > executed your > command I am > getting the following error from > my directory > server. > Please > help me to resolve this error. > > [root at sbttipa001 ~]# > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > > > > > > > > -p 636 > -Z -P > > > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > > CN=administrator,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" "objectclass=*" > > ldap_simple_bind: Can't contact > LDAP server > SSL error -5961 (TCP connection > reset by > peer.) > > Is sbtaddc001.bmitest.com > > > > > > > > > > > > > the real, registered DNS address for > the Active > Directory > server? > On both the linux machine and the windows > machine? > Does a reverse DNS lookup on the IP > address > return that > hostname? > Is Active Directory configured to > use/listen > to SSL? > Does the cert db > /etc/dirsrv/slapd-BMITEST-COM/cert8.db contain > the CA cert of the windows CA? > certutil -L -d > /etc/dirsrv/slapd-BMITEST-COM > > On Wed, Feb 24, > 2010 at 6:20 PM, Rich Megginson > > > > > >> > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > > >>>>>> wrote: > > Shan Kumaraswamy wrote: > > Dear All, > I am facing the AD Sync > issue with > FreeIPA to Active > Directory, and as per the > redhat-ds doc I > have > done all the > settings from AD front. please > help me to > resolve this > issue. > And find the below error > message: > [root at sbttipa001 ~]# > ipa-replica-manage add > --winsync > --binddn > CN=ipaadmin,CN=users,DC=bmitest,DC=com > --bindpw > secretpw --ca cert > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > -v > --passsync > bmi.123 > > Directory Manager password: > INFO:root:Shutting down dirsrv: > BMITEST-COM... > [ OK ] > INFO:root: > INFO:root: > INFO:root: > INFO:root:Starting dirsrv: > BMITEST-COM... > [ OK ] > INFO:root: > INFO:root:Added CA certificate > > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer to > certificate > database for > sbttipa001.bmitest.com > > > > > > > > > > > > > > > > INFO:root:Restarted > directory server > sbttipa001.bmitest.com > > > > > > > > > > > > > > > > > INFO:root:Could not validate > connection to > remote server > sbtaddc001.bmitest.com:636 > > > > > > > > > > > > > > > > > - > continuing > > INFO:root:The error was: > {'info': > 'error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', 'desc ': "Can't > contact LDAP > server"} > The user for the Windows > PassSync > service is > > uid=passsync,cn=sysaccounts,cn=etc,dc=bmitest,dc=com > Windows PassSync entry > exists, not > resetting > password > INFO:root:Added new sync > agreement, > waiting for > it to > become > ready . . . > INFO:root:Replication Update in > progress: > FALSE: > status: 49 - > LDAP error: Invalid > credentials: > start: > 0: end: 0 > INFO:root:Agreement is > ready, starting > replication . . . > Starting replication, > please wait > until > this has > completed. > [sbttipa001.bmitest.com > > > > > > > > > > > > > > > >] > reports: > Update failed! > Status: [49 - LDAP error: > Invalid > credentials] > INFO:root:Added agreement for > other host > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > Error 49 usually means the > password is not > correct. You > can use > mozldap ldapsearch to test the > connection > like this: > > /usr/lib/mozldap/ldapsearch -h > dchost > -p 636 > -Z -P > > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > > CN=ipaadmin,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" > "objectclass=*" > > -- Thanks > & Regards > Shan Kumaraswamy > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rmeggins at redhat.com Tue Mar 9 16:58:23 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 09 Mar 2010 09:58:23 -0700 Subject: [Freeipa-users] AD Sync Error In-Reply-To: <68b7c79a1003090853ie41dd36vfd8dd3eb4bbdbc62@mail.gmail.com> References: <68b7c79a1002240658w222a5333l12e0c31fe1eaffee@mail.gmail.com> <4B96665C.4090700@redhat.com> <68b7c79a1003090726g235b0783m97c8fcceb71c7316@mail.gmail.com> <4B9669F4.5000004@redhat.com> <68b7c79a1003090736o1569df48s7643b96d0122d439@mail.gmail.com> <4B966B84.9000601@redhat.com> <68b7c79a1003090742x4589d2pfa7566cef76ea56f@mail.gmail.com> <4B967134.8050308@redhat.com> <68b7c79a1003090814y7a306dc6q42afdee61ee38083@mail.gmail.com> <4B96797D.40503@redhat.com> <68b7c79a1003090853ie41dd36vfd8dd3eb4bbdbc62@mail.gmail.com> Message-ID: <4B967E2F.8000609@redhat.com> Shan Kumaraswamy wrote: > Yes I can able to get the output using the port, but without password. > > /usr/lib64/mozldap/ldapsearch -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h sbtaddc001.bmitest.com > -p 636 -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -s base -b "" > "objectclass=*" Ok. Now try doing a search of your user subtree: /usr/lib64/mozldap/ldapsearch -Z -P /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h sbtaddc001.bmitest.com -p 636 -D "CN=administrator,CN=users,DC=bmitest,DC=com" -b "CN=users,DC=bmitest,DC=com" "objectclass=*" dn You will likely have to provide a password for this > > > > > On Tue, Mar 9, 2010 at 7:38 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Yes I can get the output when I ran this step: > Command: /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h > sbtaddc001.bmitest.com > > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -s base -b "" > "objectclass=*" > > Output: > version: 1 > dn: > currentTime: 20100309160730.0Z > subschemaSubentry: > CN=Aggregate,CN=Schema,CN=Configuration,DC=BMITEST,DC=COM > dsServiceName: CN=NTDS > Settings,CN=SBTADDC001,CN=Servers,CN=Bahrain-Site,CN=Si > tes,CN=Configuration,DC=BMITEST,DC=COM > namingContexts: DC=BMITEST,DC=COM > namingContexts: CN=Configuration,DC=BMITEST,DC=COM > namingContexts: CN=Schema,CN=Configuration,DC=BMITEST,DC=COM > namingContexts: DC=DomainDnsZones,DC=BMITEST,DC=COM > namingContexts: DC=ForestDnsZones,DC=BMITEST,DC=COM > defaultNamingContext: DC=BMITEST,DC=COM > schemaNamingContext: CN=Schema,CN=Configuration,DC=BMITEST,DC=COM > configurationNamingContext: CN=Configuration,DC=BMITEST,DC=COM > rootDomainNamingContext: DC=BMITEST,DC=COM > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.2.840.113556.1.4.801 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 1.2.840.113556.1.4.528 > supportedControl: 1.2.840.113556.1.4.417 > supportedControl: 1.2.840.113556.1.4.619 > supportedControl: 1.2.840.113556.1.4.841 > supportedControl: 1.2.840.113556.1.4.529 > supportedControl: 1.2.840.113556.1.4.805 > supportedControl: 1.2.840.113556.1.4.521 > supportedControl: 1.2.840.113556.1.4.970 > supportedControl: 1.2.840.113556.1.4.1338 > supportedControl: 1.2.840.113556.1.4.474 > supportedControl: 1.2.840.113556.1.4.1339 > supportedControl: 1.2.840.113556.1.4.1340 > supportedControl: 1.2.840.113556.1.4.1413 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: 2.16.840.1.113730.3.4.10 > supportedControl: 1.2.840.113556.1.4.1504 > supportedControl: 1.2.840.113556.1.4.1852 > supportedControl: 1.2.840.113556.1.4.802 > supportedControl: 1.2.840.113556.1.4.1907 > supportedControl: 1.2.840.113556.1.4.1948 > supportedControl: 1.2.840.113556.1.4.1974 > supportedControl: 1.2.840.113556.1.4.1341 > supportedControl: 1.2.840.113556.1.4.2026 > supportedLDAPVersion: 3 > supportedLDAPVersion: 2 > supportedLDAPPolicies: MaxPoolThreads > supportedLDAPPolicies: MaxDatagramRecv > supportedLDAPPolicies: MaxReceiveBuffer > supportedLDAPPolicies: InitRecvTimeout > supportedLDAPPolicies: MaxConnections > supportedLDAPPolicies: MaxConnIdleTime > supportedLDAPPolicies: MaxPageSize > supportedLDAPPolicies: MaxQueryDuration > supportedLDAPPolicies: MaxTempTableSize > supportedLDAPPolicies: MaxResultSetSize > supportedLDAPPolicies: MaxNotificationPerConn > supportedLDAPPolicies: MaxValRange > highestCommittedUSN: 905371 > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: DIGEST-MD5 > dnsHostName: SBTADDC001.BMITEST.COM > > > > > Please let me know the syntex of IPA Ad sync > > Ok. Now try it with the ldaps port (-p 636) > /usr/lib64/mozldap/ldapsearch -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h sbtaddc001.bmitest.com > > -p 636 -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s > base -b "" "objectclass=*" > > > > On Tue, Mar 9, 2010 at 7:03 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > Rich again some errors: > [root at sbttipa001 ~]# /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "Str1ve2XL" > -s base -b "" "objectclass=*" > > ldap_simple_bind: Strong authentication required > ldap_simple_bind: additional info: 00002028: LdapErr: > DSID-0C0901FC, comment: The server requires binds to > turn on > integrity checking if SSL\TLS are not already active on the > connection, data 0, v1771 > > If this is your real password, as simo said, please change it > immediately. > > So at least you are talking to the AD server now. It is > telling > you that it will not accept a bind using a clear text password > over an insecure connection - that is, try using SSL as we did > previously: > > /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h > sbtaddc001.bmitest.com > > > > > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s > base -b "" "objectclass=*" > > On Tue, Mar 9, 2010 at 6:38 PM, Rich Megginson > > > > >>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Your mean the AD Administrator password or IPA admin > password? > > AD > > I'm trying to find out why IPA cannot make a > connection to > AD. So > the hostname should be the AD hostname, and the -D > (binddn) > should > be the DN of the user that IPA uses to bind to AD, > and the > password should be the password for that user. > > > On Tue, Mar 9, 2010 at 6:32 PM, Rich Megginson > > > >> > > > > >>>> wrote: > > Shan Kumaraswamy wrote: > > When I try to run this command I am > getting this > error: > [root at sbttipa001 ~]# > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > > > > > -D > > > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > ldap_simple_bind: Invalid credentials > ldap_simple_bind: additional info: 80090308: > LdapErr: > DSID-0C0903AA, comment: > AcceptSecurityContext error, > data 52e, > v1771 > > You are not providing the correct password. > > > > On Tue, Mar 9, 2010 at 6:16 PM, Rich > Megginson > > > > >> > > > > >>> > > > > > >> > > > > >>>>> wrote: > > Please keep replies on list > > Shan Kumaraswamy wrote: > > Rich, > Does a reverse DNS lookup on the > IP address > return that > hostname? -Yes > Is Active Directory configured to > use/listen to > SSL? -Yes, > Active Directory Cert Auth > installed and > exported the and > verifityed. > > Does the cert db > /etc/dirsrv/slapd-BMITEST-COM/cert8.db > contain the CA cert of the windows > CA? -yes > "Imported > CA cert" > > certutil -L -d > /etc/dirsrv/slapd-BMITEST-COM- > Its listing > installed cert > I am trying to creating syn agreement > from IPA > server using > following syntex: > ipa-replica-manage add --winsync > --binddn > > CN=Administrator,CN=Users,CN=Accounts,DC=bmitest,DC=com > --bindpw secretpw --cacert > /etc/dirsrv/slapd-BMITEST-COM/dsca.cer > sbtaddc001.bmitest.com > > > > > > > > > > > > -v > > Please corret me where I am doing > worng? > > ldap_simple_bind: Can't contact LDAP > server > SSL error -5961 (TCP connection > reset by > peer.) > > This usually indicates some low level > error. > Let's > try this: > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > -D > > > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > Does that work? > > On Mon, Mar > 8, 2010 > at 6:30 PM, Rich Megginson > > > > > >> > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > > >>>>>> wrote: > > Shan Kumaraswamy wrote: > > Hi Rich, > > Sorry for the delay replay, > after I > executed your > command I am > getting the following error > from > my directory > server. > Please > help me to resolve this error. > > [root at sbttipa001 ~]# > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > -p 636 > -Z -P > > > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > > CN=administrator,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" "objectclass=*" > > ldap_simple_bind: Can't contact > LDAP server > SSL error -5961 (TCP > connection > reset by > peer.) > > Is sbtaddc001.bmitest.com > > > > > > > > > > > > > > > the real, registered DNS > address for > the Active > Directory > server? > On both the linux machine and > the windows > machine? > Does a reverse DNS lookup on the IP > address > return that > hostname? > Is Active Directory configured to > use/listen > to SSL? > Does the cert db > /etc/dirsrv/slapd-BMITEST-COM/cert8.db > contain > the CA cert of the windows CA? > certutil -L -d > /etc/dirsrv/slapd-BMITEST-COM > > On > Wed, Feb 24, > 2010 at 6:20 PM, Rich Megginson > > > > >> > > > > > >>> > > > >> > > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > >>>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > >> > > > > > >>>>>>> wrote: > > Shan Kumaraswamy wrote: > > Dear All, > I am facing the AD Sync > issue with > FreeIPA to Active > Directory, and as > per the > redhat-ds doc I > have > done all the > settings from AD > front. please > help me to > resolve this > issue. > And find the below error > message: > [root at sbttipa001 ~]# > ipa-replica-manage add > --winsync > --binddn > CN=ipaadmin,CN=users,DC=bmitest,DC=com > --bindpw > secretpw --ca cert > > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer > > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > > -v > --passsync > bmi.123 > > Directory Manager > password: > INFO:root:Shutting > down dirsrv: > BMITEST-COM... > > [ OK ] > INFO:root: > INFO:root: > INFO:root: > INFO:root:Starting > dirsrv: > BMITEST-COM... > > [ OK ] > INFO:root: > INFO:root:Added CA > certificate > > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer to > certificate > database for > sbttipa001.bmitest.com > > > > > > > > > > > > > > > > > > > > INFO:root:Restarted > directory server > sbttipa001.bmitest.com > > > > > > > > > > > > > > > > > > > > INFO:root:Could not > validate > connection to > remote server > > sbtaddc001.bmitest.com:636 > > > > > > > > > > > > > > > > > > > > - > continuing > > INFO:root:The error was: > {'info': > 'error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', 'desc ': "Can't > contact LDAP > server"} > The user for the Windows > PassSync > service is > > uid=passsync,cn=sysaccounts,cn=etc,dc=bmitest,dc=com > Windows PassSync entry > exists, not > resetting > password > INFO:root:Added new sync > agreement, > waiting for > it to > become > ready . . . > > INFO:root:Replication Update in > progress: > FALSE: > status: 49 - > LDAP error: Invalid > credentials: > start: > 0: end: 0 > INFO:root:Agreement is > ready, starting > replication . . . > Starting replication, > please wait > until > this has > completed. > > [sbttipa001.bmitest.com > > > > > > > > > > > > > > > > > >] > reports: > Update failed! > Status: [49 - LDAP > error: > Invalid > credentials] > INFO:root:Added > agreement for > other host > > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > > > > Error 49 usually means the > password is not > correct. You > can use > mozldap ldapsearch to > test the > connection > like this: > > > /usr/lib/mozldap/ldapsearch -h > dchost > -p 636 > -Z -P > > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > > CN=ipaadmin,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" > "objectclass=*" > > -- > Thanks > & Regards > Shan Kumaraswamy > > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Freeipa-users > mailing list > > Freeipa-users at redhat.com > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>> > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rmeggins at redhat.com Tue Mar 9 17:28:37 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 09 Mar 2010 10:28:37 -0700 Subject: [Freeipa-users] AD Sync Error In-Reply-To: <68b7c79a1003090924k6bb66776u5da4432896386f37@mail.gmail.com> References: <68b7c79a1002240658w222a5333l12e0c31fe1eaffee@mail.gmail.com> <4B9669F4.5000004@redhat.com> <68b7c79a1003090736o1569df48s7643b96d0122d439@mail.gmail.com> <4B966B84.9000601@redhat.com> <68b7c79a1003090742x4589d2pfa7566cef76ea56f@mail.gmail.com> <4B967134.8050308@redhat.com> <68b7c79a1003090814y7a306dc6q42afdee61ee38083@mail.gmail.com> <4B96797D.40503@redhat.com> <68b7c79a1003090853ie41dd36vfd8dd3eb4bbdbc62@mail.gmail.com> <4B967E2F.8000609@redhat.com> <68b7c79a1003090924k6bb66776u5da4432896386f37@mail.gmail.com> Message-ID: <4B968545.5070306@redhat.com> Shan Kumaraswamy wrote: > Wheare I can add the password? ldapsearch -h ... -w passwd bind passwd (for simple authentication) -w - prompt for bind passwd (for simple authentication) -j file read bind passwd from 'file' (for simple authentication) Note that if your password contains shell meta characters (e.g. ! $ etc.) you must quote or escape them at the shell command line if using -w. > > On Tue, Mar 9, 2010 at 7:58 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Yes I can able to get the output using the port, but without > password. > /usr/lib64/mozldap/ldapsearch -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h > sbtaddc001.bmitest.com > > -p 636 -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -s base -b "" > "objectclass=*" > > Ok. Now try doing a search of your user subtree: > /usr/lib64/mozldap/ldapsearch -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h sbtaddc001.bmitest.com > -p 636 -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -b > "CN=users,DC=bmitest,DC=com" "objectclass=*" dn > > You will likely have to provide a password for this > > > > On Tue, Mar 9, 2010 at 7:38 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > Yes I can get the output when I ran this step: > Command: /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h > sbtaddc001.bmitest.com > > > > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -s base -b "" > "objectclass=*" > > Output: > version: 1 > dn: > currentTime: 20100309160730.0Z > subschemaSubentry: > CN=Aggregate,CN=Schema,CN=Configuration,DC=BMITEST,DC=COM > dsServiceName: CN=NTDS > Settings,CN=SBTADDC001,CN=Servers,CN=Bahrain-Site,CN=Si > tes,CN=Configuration,DC=BMITEST,DC=COM > namingContexts: DC=BMITEST,DC=COM > namingContexts: CN=Configuration,DC=BMITEST,DC=COM > namingContexts: > CN=Schema,CN=Configuration,DC=BMITEST,DC=COM > namingContexts: DC=DomainDnsZones,DC=BMITEST,DC=COM > namingContexts: DC=ForestDnsZones,DC=BMITEST,DC=COM > defaultNamingContext: DC=BMITEST,DC=COM > schemaNamingContext: > CN=Schema,CN=Configuration,DC=BMITEST,DC=COM > configurationNamingContext: > CN=Configuration,DC=BMITEST,DC=COM > rootDomainNamingContext: DC=BMITEST,DC=COM > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.2.840.113556.1.4.801 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 1.2.840.113556.1.4.528 > supportedControl: 1.2.840.113556.1.4.417 > supportedControl: 1.2.840.113556.1.4.619 > supportedControl: 1.2.840.113556.1.4.841 > supportedControl: 1.2.840.113556.1.4.529 > supportedControl: 1.2.840.113556.1.4.805 > supportedControl: 1.2.840.113556.1.4.521 > supportedControl: 1.2.840.113556.1.4.970 > supportedControl: 1.2.840.113556.1.4.1338 > supportedControl: 1.2.840.113556.1.4.474 > supportedControl: 1.2.840.113556.1.4.1339 > supportedControl: 1.2.840.113556.1.4.1340 > supportedControl: 1.2.840.113556.1.4.1413 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: 2.16.840.1.113730.3.4.10 > supportedControl: 1.2.840.113556.1.4.1504 > supportedControl: 1.2.840.113556.1.4.1852 > supportedControl: 1.2.840.113556.1.4.802 > supportedControl: 1.2.840.113556.1.4.1907 > supportedControl: 1.2.840.113556.1.4.1948 > supportedControl: 1.2.840.113556.1.4.1974 > supportedControl: 1.2.840.113556.1.4.1341 > supportedControl: 1.2.840.113556.1.4.2026 > supportedLDAPVersion: 3 > supportedLDAPVersion: 2 > supportedLDAPPolicies: MaxPoolThreads > supportedLDAPPolicies: MaxDatagramRecv > supportedLDAPPolicies: MaxReceiveBuffer > supportedLDAPPolicies: InitRecvTimeout > supportedLDAPPolicies: MaxConnections > supportedLDAPPolicies: MaxConnIdleTime > supportedLDAPPolicies: MaxPageSize > supportedLDAPPolicies: MaxQueryDuration > supportedLDAPPolicies: MaxTempTableSize > supportedLDAPPolicies: MaxResultSetSize > supportedLDAPPolicies: MaxNotificationPerConn > supportedLDAPPolicies: MaxValRange > highestCommittedUSN: 905371 > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: DIGEST-MD5 > dnsHostName: SBTADDC001.BMITEST.COM > > > > > > Please let me know the syntex of IPA Ad sync > > Ok. Now try it with the ldaps port (-p 636) > /usr/lib64/mozldap/ldapsearch -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h > sbtaddc001.bmitest.com > > > > -p 636 -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w "secretpw" -s > base -b "" "objectclass=*" > > > On Tue, Mar 9, 2010 at 7:03 PM, Rich Megginson > > > > >>> wrote: > > Shan Kumaraswamy wrote: > > Rich again some errors: > [root at sbttipa001 ~]# > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > > > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "Str1ve2XL" > -s base -b "" "objectclass=*" > > ldap_simple_bind: Strong authentication required > ldap_simple_bind: additional info: 00002028: > LdapErr: > DSID-0C0901FC, comment: The server requires binds to > turn on > integrity checking if SSL\TLS are not already > active on the > connection, data 0, v1771 > > If this is your real password, as simo said, please > change it > immediately. > > So at least you are talking to the AD server now. It is > telling > you that it will not accept a bind using a clear > text password > over an insecure connection - that is, try using SSL > as we did > previously: > > /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h > sbtaddc001.bmitest.com > > > > > > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > On Tue, Mar 9, 2010 at 6:38 PM, Rich > Megginson > > > >> > > > > >>>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Your mean the AD Administrator password > or IPA admin > password? > > AD > > I'm trying to find out why IPA cannot make a > connection to > AD. So > the hostname should be the AD hostname, and > the -D > (binddn) > should > be the DN of the user that IPA uses to bind > to AD, > and the > password should be the password for that user. > > > On Tue, Mar 9, 2010 at 6:32 PM, Rich > Megginson > > > > >> > > > > >>> > > > > > >> > > > > >>>>> wrote: > > Shan Kumaraswamy wrote: > > When I try to run this command I am > getting this > error: > [root at sbttipa001 ~]# > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > > > > > > > -D > > > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > ldap_simple_bind: Invalid credentials > ldap_simple_bind: additional info: > 80090308: > LdapErr: > DSID-0C0903AA, comment: > AcceptSecurityContext error, > data 52e, > v1771 > > You are not providing the correct > password. > > > > On Tue, Mar 9, 2010 at 6:16 PM, Rich > Megginson > > > > > >> > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > > >>>>>> wrote: > > Please keep replies on list > > Shan Kumaraswamy wrote: > > Rich, > Does a reverse DNS lookup > on the > IP address > return that > hostname? -Yes > Is Active Directory > configured to > use/listen to > SSL? -Yes, > Active Directory Cert Auth > installed and > exported the and > verifityed. > > Does the cert db > /etc/dirsrv/slapd-BMITEST-COM/cert8.db > contain the CA cert of the > windows > CA? -yes > "Imported > CA cert" > > certutil -L -d > /etc/dirsrv/slapd-BMITEST-COM- > Its listing > installed cert > I am trying to creating syn > agreement > from IPA > server using > following syntex: > ipa-replica-manage add > --winsync > --binddn > > CN=Administrator,CN=Users,CN=Accounts,DC=bmitest,DC=com > --bindpw secretpw --cacert > > /etc/dirsrv/slapd-BMITEST-COM/dsca.cer > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > -v > > Please corret me where I > am doing > worng? > > ldap_simple_bind: Can't contact > LDAP > server > SSL error -5961 (TCP > connection > reset by > peer.) > > This usually indicates some low > level > error. > Let's > try this: > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > > -D > > > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > Does that work? > > On > Mon, Mar > 8, 2010 > at 6:30 PM, Rich Megginson > > > > >> > > > > > >>> > > > >> > > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > >>>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > >> > > > > > >>>>>>> wrote: > > Shan Kumaraswamy wrote: > > Hi Rich, > > Sorry for the delay > replay, > after I > executed your > command I am > getting the > following error > from > my directory > server. > Please > help me to resolve > this error. > > [root at sbttipa001 ~]# > /usr/lib64/mozldap/ldapsearch -h > > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > > -p 636 > -Z -P > > > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > > CN=administrator,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" > "objectclass=*" > > ldap_simple_bind: > Can't contact > LDAP server > SSL error > -5961 (TCP > connection > reset by > peer.) > > Is > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > > > > the real, registered DNS > address for > the Active > Directory > server? > On both the linux > machine and > the windows > machine? > Does a reverse DNS > lookup on the IP > address > return that > hostname? > Is Active Directory > configured to > use/listen > to SSL? > Does the cert db > /etc/dirsrv/slapd-BMITEST-COM/cert8.db > contain > the CA cert of the > windows CA? > certutil -L -d > /etc/dirsrv/slapd-BMITEST-COM > > On > Wed, Feb 24, > 2010 at 6:20 PM, Rich Megginson > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > > >> > > > > >>>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > > >> > > > > >>>>>> > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>>> > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>>>>>> wrote: > > Shan Kumaraswamy > wrote: > > Dear All, > I am facing > the AD Sync > issue with > FreeIPA to Active > Directory, and as > per the > redhat-ds doc I > have > done all the > settings from AD > front. please > help me to > resolve this > issue. > And find the > below error > message: > > [root at sbttipa001 ~]# > ipa-replica-manage add > --winsync > --binddn > CN=ipaadmin,CN=users,DC=bmitest,DC=com > --bindpw > secretpw --ca > cert > > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer > > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > > > > > > > -v > --passsync > bmi.123 > > Directory Manager > password: > > INFO:root:Shutting > down dirsrv: > > BMITEST-COM... > [ OK ] > INFO:root: > INFO:root: > INFO:root: > > INFO:root:Starting > dirsrv: > > BMITEST-COM... > [ OK ] > INFO:root: > > INFO:root:Added CA > certificate > > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer to > certificate > database for > sbttipa001.bmitest.com > > > > > > > > > > > > > > > > > > > > > > > > > > > INFO:root:Restarted > directory server > > sbttipa001.bmitest.com > > > > > > > > > > > > > > > > > > > > > > > > > INFO:root:Could not > validate > connection to > remote server > > sbtaddc001.bmitest.com:636 > > > > > > > > > > > > > > > > > > > > > > > > > - > continuing > > INFO:root:The > error was: > {'info': > 'error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', > 'desc ': "Can't > contact LDAP > server"} > The user for > the Windows > PassSync > service is > > > uid=passsync,cn=sysaccounts,cn=etc,dc=bmitest,dc=com > Windows > PassSync entry > exists, not > resetting > password > > INFO:root:Added new sync > agreement, > waiting for > it to > become > ready . . . > > INFO:root:Replication Update in > progress: > FALSE: > status: 49 - > LDAP error: > Invalid > credentials: > start: > 0: end: 0 > > INFO:root:Agreement is > ready, starting > replication . . . > Starting > replication, > please wait > until > this has > completed. > > [sbttipa001.bmitest.com > > > > > > > > > > > > > > > > > > > > > > > >] > reports: > Update failed! > Status: [49 > - LDAP > error: > Invalid > credentials] > INFO:root:Added > agreement for > other host > > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > > > > > > > > > Error 49 usually > means the > password is not > correct. You > can use > mozldap ldapsearch to > test the > connection > like this: > > > /usr/lib/mozldap/ldapsearch -h > dchost > -p 636 > -Z -P > > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > > CN=ipaadmin,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" > "objectclass=*" > > -- > Thanks > & Regards > Shan Kumaraswamy > > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Freeipa-users > mailing list > > Freeipa-users at redhat.com > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>>> > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- Thanks & > Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rmeggins at redhat.com Wed Mar 10 15:40:27 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 10 Mar 2010 08:40:27 -0700 Subject: [Freeipa-users] AD Sync Error In-Reply-To: <68b7c79a1003092256i506c25a4s724bc993ac17f537@mail.gmail.com> References: <68b7c79a1002240658w222a5333l12e0c31fe1eaffee@mail.gmail.com> <4B966B84.9000601@redhat.com> <68b7c79a1003090742x4589d2pfa7566cef76ea56f@mail.gmail.com> <4B967134.8050308@redhat.com> <68b7c79a1003090814y7a306dc6q42afdee61ee38083@mail.gmail.com> <4B96797D.40503@redhat.com> <68b7c79a1003090853ie41dd36vfd8dd3eb4bbdbc62@mail.gmail.com> <4B967E2F.8000609@redhat.com> <68b7c79a1003090924k6bb66776u5da4432896386f37@mail.gmail.com> <4B968545.5070306@redhat.com> <68b7c79a1003092256i506c25a4s724bc993ac17f537@mail.gmail.com> Message-ID: <4B97BD6B.9060607@redhat.com> Shan Kumaraswamy wrote: > Hi Rich, > Yes I can get the output with the all the user details. Ok. So we have established that you can establish a TLS/SSL connection to AD with your AD admin DN and password. Can you confirm that your AD sync settings correspond to these? Note that there is no way to confirm your setting for the AD admin password in the AD sync agreement because it is encrypted. You can use ldapmodify to set them like this: ldapmodify -x -h dshost -p dsport -D "cn=directory manager" -w "secretpw" dn: dn of your windows sync agreement changetype: modify replace: nsds5replicacredentials nsds5replicacredentials: clear text AD admin password > > > > > On Tue, Mar 9, 2010 at 8:28 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Wheare I can add the password? > > ldapsearch -h > ... > -w passwd bind passwd (for simple authentication) > -w - prompt for bind passwd (for simple authentication) > -j file read bind passwd from 'file' (for simple authentication) > > Note that if your password contains shell meta characters (e.g. ! > $ etc.) you must quote or escape them at the shell command line if > using -w. > > > On Tue, Mar 9, 2010 at 7:58 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > Yes I can able to get the output using the port, but > without > password. > /usr/lib64/mozldap/ldapsearch -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h > sbtaddc001.bmitest.com > > > > -p 636 -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -s base -b "" > "objectclass=*" > > Ok. Now try doing a search of your user subtree: > /usr/lib64/mozldap/ldapsearch -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h > sbtaddc001.bmitest.com > -p 636 -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -b > "CN=users,DC=bmitest,DC=com" "objectclass=*" dn > > You will likely have to provide a password for this > > > On Tue, Mar 9, 2010 at 7:38 PM, Rich Megginson > > > > >>> wrote: > > Shan Kumaraswamy wrote: > > Yes I can get the output when I ran this step: > Command: /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h > sbtaddc001.bmitest.com > > > > > > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -s > base -b "" > "objectclass=*" > > Output: > version: 1 > dn: > currentTime: 20100309160730.0Z > subschemaSubentry: > > CN=Aggregate,CN=Schema,CN=Configuration,DC=BMITEST,DC=COM > dsServiceName: CN=NTDS > > Settings,CN=SBTADDC001,CN=Servers,CN=Bahrain-Site,CN=Si > tes,CN=Configuration,DC=BMITEST,DC=COM > namingContexts: DC=BMITEST,DC=COM > namingContexts: CN=Configuration,DC=BMITEST,DC=COM > namingContexts: > CN=Schema,CN=Configuration,DC=BMITEST,DC=COM > namingContexts: DC=DomainDnsZones,DC=BMITEST,DC=COM > namingContexts: DC=ForestDnsZones,DC=BMITEST,DC=COM > defaultNamingContext: DC=BMITEST,DC=COM > schemaNamingContext: > CN=Schema,CN=Configuration,DC=BMITEST,DC=COM > configurationNamingContext: > CN=Configuration,DC=BMITEST,DC=COM > rootDomainNamingContext: DC=BMITEST,DC=COM > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.2.840.113556.1.4.801 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 1.2.840.113556.1.4.528 > supportedControl: 1.2.840.113556.1.4.417 > supportedControl: 1.2.840.113556.1.4.619 > supportedControl: 1.2.840.113556.1.4.841 > supportedControl: 1.2.840.113556.1.4.529 > supportedControl: 1.2.840.113556.1.4.805 > supportedControl: 1.2.840.113556.1.4.521 > supportedControl: 1.2.840.113556.1.4.970 > supportedControl: 1.2.840.113556.1.4.1338 > supportedControl: 1.2.840.113556.1.4.474 > supportedControl: 1.2.840.113556.1.4.1339 > supportedControl: 1.2.840.113556.1.4.1340 > supportedControl: 1.2.840.113556.1.4.1413 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: 2.16.840.1.113730.3.4.10 > supportedControl: 1.2.840.113556.1.4.1504 > supportedControl: 1.2.840.113556.1.4.1852 > supportedControl: 1.2.840.113556.1.4.802 > supportedControl: 1.2.840.113556.1.4.1907 > supportedControl: 1.2.840.113556.1.4.1948 > supportedControl: 1.2.840.113556.1.4.1974 > supportedControl: 1.2.840.113556.1.4.1341 > supportedControl: 1.2.840.113556.1.4.2026 > supportedLDAPVersion: 3 > supportedLDAPVersion: 2 > supportedLDAPPolicies: MaxPoolThreads > supportedLDAPPolicies: MaxDatagramRecv > supportedLDAPPolicies: MaxReceiveBuffer > supportedLDAPPolicies: InitRecvTimeout > supportedLDAPPolicies: MaxConnections > supportedLDAPPolicies: MaxConnIdleTime > supportedLDAPPolicies: MaxPageSize > supportedLDAPPolicies: MaxQueryDuration > supportedLDAPPolicies: MaxTempTableSize > supportedLDAPPolicies: MaxResultSetSize > supportedLDAPPolicies: MaxNotificationPerConn > supportedLDAPPolicies: MaxValRange > highestCommittedUSN: 905371 > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: DIGEST-MD5 > dnsHostName: SBTADDC001.BMITEST.COM > > > > > > > > > Please let me know the syntex of IPA Ad sync > > Ok. Now try it with the ldaps port (-p 636) > /usr/lib64/mozldap/ldapsearch -Z -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h > sbtaddc001.bmitest.com > > > > > -p 636 -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > On Tue, Mar 9, 2010 at 7:03 PM, > Rich Megginson > > > >> > > > > >>>> wrote: > > Shan Kumaraswamy wrote: > > Rich again some errors: > [root at sbttipa001 ~]# > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > > > > > > -D > > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "Str1ve2XL" > -s base -b "" "objectclass=*" > > ldap_simple_bind: Strong authentication > required > ldap_simple_bind: additional info: 00002028: > LdapErr: > DSID-0C0901FC, comment: The server > requires binds to > turn on > integrity checking if SSL\TLS are not already > active on the > connection, data 0, v1771 > > If this is your real password, as simo said, > please > change it > immediately. > > So at least you are talking to the AD server > now. It is > telling > you that it will not accept a bind using a clear > text password > over an insecure connection - that is, try > using SSL > as we did > previously: > > /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -h > sbtaddc001.bmitest.com > > > > > > > > > -D > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > On Tue, Mar 9, 2010 at 6:38 PM, > Rich > Megginson > > > > >> > > > > >>> > > > > > >> > > > > >>>>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Your mean the AD Administrator > password > or IPA admin > password? > > AD > > I'm trying to find out why IPA cannot > make a > connection to > AD. So > the hostname should be the AD > hostname, and > the -D > (binddn) > should > be the DN of the user that IPA uses to > bind > to AD, > and the > password should be the password for > that user. > > > On Tue, Mar 9, 2010 at 6:32 PM, Rich > Megginson > > > > > >> > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > > >>>>>> wrote: > > Shan Kumaraswamy wrote: > > When I try to run this > command I am > getting this > error: > [root at sbttipa001 ~]# > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > -D > > > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > ldap_simple_bind: Invalid > credentials > ldap_simple_bind: > additional info: > 80090308: > LdapErr: > DSID-0C0903AA, comment: > AcceptSecurityContext error, > data 52e, > v1771 > > You are not providing the correct > password. > > > > On Tue, Mar 9, 2010 at > 6:16 PM, Rich > Megginson > > > > >> > > > > > >>> > > > >> > > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > >>>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > >> > > > > > >>>>>>> wrote: > > Please keep replies on list > > Shan Kumaraswamy wrote: > > Rich, > Does a reverse DNS > lookup > on the > IP address > return that > hostname? -Yes > Is Active Directory > configured to > use/listen to > SSL? -Yes, > Active Directory > Cert Auth > installed and > exported the and > verifityed. > > Does the cert db > /etc/dirsrv/slapd-BMITEST-COM/cert8.db > contain the CA cert > of the > windows > CA? -yes > "Imported > CA cert" > > certutil -L -d > /etc/dirsrv/slapd-BMITEST-COM- > Its listing > installed cert > I am trying to > creating syn > agreement > from IPA > server using > following syntex: > ipa-replica-manage add > --winsync > --binddn > > CN=Administrator,CN=Users,CN=Accounts,DC=bmitest,DC=com > --bindpw secretpw > --cacert > > /etc/dirsrv/slapd-BMITEST-COM/dsca.cer > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > > > -v > > Please corret me > where I > am doing > worng? > > ldap_simple_bind: Can't > contact > LDAP > server > SSL error -5961 (TCP > connection > reset by > peer.) > > This usually indicates > some low > level > error. > Let's > try this: > > /usr/lib64/mozldap/ldapsearch -h > sbtaddc001.bmitest.com > > > > > > > > > -D > > > "CN=administrator,CN=users,DC=bmitest,DC=com" -w > "secretpw" -s > base -b "" "objectclass=*" > > Does that work? > > On > Mon, Mar > 8, 2010 > at 6:30 PM, Rich Megginson > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > > >> > > > > >>>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > > >> > > > > >>>>>> > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>>> > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>>>>>> wrote: > > Shan Kumaraswamy > wrote: > > Hi Rich, > > Sorry for the > delay > replay, > after I > executed your > command I am > getting the > following error > from > my directory > server. > Please > help me to > resolve > this error. > > > [root at sbttipa001 ~]# > > /usr/lib64/mozldap/ldapsearch -h > > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > > > > > > > -p 636 > -Z -P > > > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > > CN=administrator,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" > "objectclass=*" > > ldap_simple_bind: > Can't contact > LDAP server > SSL error > -5961 (TCP > connection > reset by > peer.) > > Is > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > > > > > > > the real, > registered DNS > address for > the Active > Directory > server? > On both the linux > machine and > the windows > machine? > Does a reverse DNS > lookup on the IP > address > return that > hostname? > Is Active Directory > configured to > use/listen > to SSL? > Does the cert db > > /etc/dirsrv/slapd-BMITEST-COM/cert8.db > contain > the CA cert of the > windows CA? > certutil -L -d > /etc/dirsrv/slapd-BMITEST-COM > > > On > Wed, Feb 24, > 2010 at 6:20 PM, Rich Megginson > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>>> > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > > >>>>>> > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>>> > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > > >>>>>>> > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > >>>>> > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>>>> > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > >>>>> > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>>>>>>> wrote: > > Shan > Kumaraswamy > wrote: > > Dear All, > I am > facing > the AD Sync > issue with > FreeIPA to Active > > Directory, and as > per the > redhat-ds doc I > have > done all the > > settings from AD > front. please > help me to > resolve this > issue. > And > find the > below error > message: > > [root at sbttipa001 ~]# > ipa-replica-manage add > --winsync > --binddn > > CN=ipaadmin,CN=users,DC=bmitest,DC=com > --bindpw > > secretpw --ca > cert > > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer > > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > > > > > > > > > > > -v > --passsync > bmi.123 > > > Directory Manager > password: > > INFO:root:Shutting > down dirsrv: > > BMITEST-COM... > [ OK ] > INFO:root: > INFO:root: > INFO:root: > > INFO:root:Starting > dirsrv: > > BMITEST-COM... > [ OK ] > INFO:root: > > INFO:root:Added CA > certificate > > /etc/dirsrv/slapd-BMITEST-COM/adsync.cer to > certificate > > database for > sbttipa001.bmitest.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > INFO:root:Restarted > directory server > > sbttipa001.bmitest.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > INFO:root:Could not > validate > connection to > remote server > > sbtaddc001.bmitest.com:636 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > continuing > > > INFO:root:The > error was: > {'info': > 'error:14090086:SSL > > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', > 'desc ': "Can't > contact LDAP > server"} > The > user for > the Windows > PassSync > service is > > > uid=passsync,cn=sysaccounts,cn=etc,dc=bmitest,dc=com > Windows > PassSync entry > exists, not > resetting > password > > INFO:root:Added new sync > agreement, > waiting for > it to > become > ready > . . . > > INFO:root:Replication Update in > progress: > FALSE: > status: 49 - > LDAP > error: > Invalid > credentials: > start: > 0: end: 0 > > INFO:root:Agreement is > ready, starting > replication . . . > Starting > replication, > please wait > until > this has > completed. > > [sbttipa001.bmitest.com > > > > > > > > > > > > > > > > > > > > > > > > > > >] > reports: > Update failed! > > Status: [49 > - LDAP > error: > Invalid > credentials] > > INFO:root:Added > agreement for > other host > > sbtaddc001.bmitest.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Error 49 > usually > means the > password is not > correct. You > can use > mozldap > ldapsearch to > test the > connection > like this: > > > /usr/lib/mozldap/ldapsearch -h > dchost > -p 636 > -Z -P > > /etc/dirsrv/slapd-BMITEST-COM/cert8.db -D > > CN=ipaadmin,CN=users,DC=bmitest,DC=com -w > "secretpw" -s > base -b "" > > "objectclass=*" > > > -- Thanks > & Regards > Shan > Kumaraswamy > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Freeipa-users > mailing list > > Freeipa-users at redhat.com > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>>>> > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Thanks & > Regards > Shan Kumaraswamy > > > > > > -- Thanks & > Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From chorn at fluxcoil.net Fri Mar 12 15:47:06 2010 From: chorn at fluxcoil.net (Christian Horn) Date: Fri, 12 Mar 2010 16:47:06 +0100 Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA v2 Server Alpha 2 Release In-Reply-To: <4B7D900A.2090605@redhat.com> References: <4B7D900A.2090605@redhat.com> Message-ID: <20100312154706.GA18809@fluxcoil.net> On Thu, Feb 18, 2010 at 02:07:54PM -0500, Rob Crittenden wrote: > > Please take a moment to play with these pages. Please do not pay > attention to style, rather focus attention to the work flow, layout and > data being added, displayed or modified. We need to understand if the > direction that this interface establishes is the right one. Should we > continue with the proposed approach or do something else. What? That webinterface looks usable to me, found what i expected - plus groupings/options in the interface for which i do not intuitively pick up their use. Probably just my missing of the ipa2.0 picture thou. Looks good so far with the fedora-clients i tested. 2 other comments i collected on the install: - When http_proxy/https_proxy are set in environment ipa-server-install is started from then installation doesnt succed, the log mentions '/usr/bin/wget -O /etc/ipa/ca.crt http://host.domain/ipa/config/ca.crt' returned with non-0. unsetting the 2 vars fixes the problem. - the install-script noted too many times: ----- IPA requires ports 389 and 636 for the Directory Server. These are currently in use: 389 ----- This was noted even when nothing was listening on the port but it was in some wait-states. The admin has just to wait for the state to get cleared but the script could ofcourse also wait for itself. Christian From dpal at redhat.com Fri Mar 12 16:37:54 2010 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 12 Mar 2010 11:37:54 -0500 Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA v2 Server Alpha 2 Release In-Reply-To: <20100312154706.GA18809@fluxcoil.net> References: <4B7D900A.2090605@redhat.com> <20100312154706.GA18809@fluxcoil.net> Message-ID: <4B9A6DE2.6020509@redhat.com> Christian Horn wrote: > On Thu, Feb 18, 2010 at 02:07:54PM -0500, Rob Crittenden wrote: > >> Please take a moment to play with these pages. Please do not pay >> attention to style, rather focus attention to the work flow, layout and >> data being added, displayed or modified. We need to understand if the >> direction that this interface establishes is the right one. Should we >> continue with the proposed approach or do something else. What? >> > > That webinterface looks usable to me, found what i expected - > plus groupings/options in the interface for which i do not > intuitively pick up their use. Probably just my missing of > the ipa2.0 picture thou. > Looks good so far with the fedora-clients i tested. > > 2 other comments i collected on the install: > > - When http_proxy/https_proxy are set in environment ipa-server-install > is started from then installation doesnt succed, the log mentions > '/usr/bin/wget -O /etc/ipa/ca.crt http://host.domain/ipa/config/ca.crt' > returned with non-0. > unsetting the 2 vars fixes the problem. > > - the install-script noted too many times: > ----- > IPA requires ports 389 and 636 for the Directory Server. > These are currently in use: > 389 > ----- > This was noted even when nothing was listening on the port but it was > in some wait-states. The admin has just to wait for the state to get > cleared but the script could ofcourse also wait for itself. > > Thank you very much for the feedback! We have recorded issues you have noticed and will look into them. > Christian > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Gerrard.Geldenhuis at betfair.com Wed Mar 17 10:22:58 2010 From: Gerrard.Geldenhuis at betfair.com (Gerrard Geldenhuis) Date: Wed, 17 Mar 2010 10:22:58 +0000 Subject: [Freeipa-users] Installing on Centos Message-ID: <2AA5506325476F4295EDDB5D15B08A560E59B3@HAMMBX01.uk.betfair.local> Hi I was wondering if anyone has had any luck in getting FreeIPA compiled and installed on Centos. I am struggling a bit at the moment. I have downloaded a fedora source package which I have tried to compile but can't even get the package to install at the moment. I get the error: error: unpacking of archive failed on file /usr/src/redhat/SOURCES/Fix-install-with-krb-1.7.patch;4ba0aaed: cpio: MD5 sum mismatch This is the file I downloaded: http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/updates/12/SRPMS/ipa-1.2.2-3.fc12.src.rpm Regards ________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. ________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shan.sysadm at gmail.com Wed Mar 17 12:55:32 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Wed, 17 Mar 2010 15:55:32 +0300 Subject: [Freeipa-users] Installing on Centos In-Reply-To: <2AA5506325476F4295EDDB5D15B08A560E59B3@HAMMBX01.uk.betfair.local> References: <2AA5506325476F4295EDDB5D15B08A560E59B3@HAMMBX01.uk.betfair.local> Message-ID: <68b7c79a1003170555k1171c93bp620fee9f3a659532@mail.gmail.com> Hi, Follow the below steps provided by Mr.Rob from FreeIPA-Redhat, and I have successfully complied and Installed in my test environment. % cd rpmbuild/SOURCES % wget http://kojipkgs.fedoraproject.org/packages/ipa/1.2.2/2.fc11/src/ipa-1.2.2-2.fc11.src.rpm % rpm2cpio ipa-1.2.2-2.fc11.src.rpm |cpio -idv % --- ipa.spec.orig 2010-02-03 10:22:04.000000000 -0500 +++ ipa.spec 2010-02-03 10:25:23.000000000 -0500 @@ -16,7 +16,7 @@ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Patch1: ipa-schema.patch -BuildRequires: fedora-ds-base-devel >= 1.1.3 +BuildRequires: redhat-ds-base-devel >= 8.1 BuildRequires: mozldap-devel BuildRequires: svrcore-devel BuildRequires: nspr-devel @@ -30,7 +30,7 @@ BuildRequires: autoconf BuildRequires: automake BuildRequires: libtool -BuildRequires: popt-devel +BuildRequires: popt BuildRequires: /usr/share/selinux/devel/Makefile BuildRequires: m4 BuildRequires: policycoreutils >= %{POLICYCOREUTILSVER} @@ -49,7 +49,7 @@ Requires: %{name}-client = %{version}-%{release} Requires: %{name}-admintools = %{version}-%{release} Requires(post): %{name}-server-selinux = %{version}-%{release} -Requires: fedora-ds-base >= 1.1.3 +Requires: redhat-ds-base >= 8.1 Requires: openldap-clients Requires: nss Requires: nss-tools % rpmbuild -ba ipa.spec % su # cd ../RPMS/x86_64 # rpm -Uvh ipa-admintools-1.2.2-2.x86_64.rpm ipa-client-1.2.2-2.x86_64.rpm ipa-python-1.2.2-2.x86_64.rpm ipa-server-1.2.2-2.x86_64.rpm ipa-server-selinux-1.2.2-2.x86_64.rpm # /usr/sbin/ipa-server-install # kinit admin # /usr/sbin/ipa-finduser admin Home Directory: /home/admin Login Shell: /bin/bash Last Name: Administrator Login: admin # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.2 (Tikanga) The UI works too: # curl -k --negotiate -u : https://ipa.example.com/ipa/ui 2>&1 | grep Logged On Wed, Mar 17, 2010 at 1:22 PM, Gerrard Geldenhuis < Gerrard.Geldenhuis at betfair.com> wrote: > Hi > > I was wondering if anyone has had any luck in getting FreeIPA compiled and > installed on Centos. I am struggling a bit at the moment. I have downloaded > a fedora source package which I have tried to compile but can?t even get the > package to install at the moment. I get the error: > > error: unpacking of archive failed on file > /usr/src/redhat/SOURCES/Fix-install-with-krb-1.7.patch;4ba0aaed: cpio: MD5 > sum mismatch > > > > This is the file I downloaded: > > > http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/updates/12/SRPMS/ipa-1.2.2-3.fc12.src.rpm > > > > Regards > > ________________________________________________________________________ > In order to protect our email recipients, Betfair Group use SkyScan from > MessageLabs to scan all Incoming and Outgoing mail for viruses. > > ________________________________________________________________________ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Mar 17 12:58:40 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Mar 2010 08:58:40 -0400 Subject: [Freeipa-users] Installing on Centos In-Reply-To: <2AA5506325476F4295EDDB5D15B08A560E59B3@HAMMBX01.uk.betfair.local> References: <2AA5506325476F4295EDDB5D15B08A560E59B3@HAMMBX01.uk.betfair.local> Message-ID: <4BA0D200.5020301@redhat.com> Gerrard Geldenhuis wrote: > Hi > > I was wondering if anyone has had any luck in getting FreeIPA compiled > and installed on Centos. I am struggling a bit at the moment. I have > downloaded a fedora source package which I have tried to compile but > can?t even get the package to install at the moment. I get the error: > > error: unpacking of archive failed on file > /usr/src/redhat/SOURCES/Fix-install-with-krb-1.7.patch;4ba0aaed: cpio: > MD5 sum mismatch > > > > This is the file I downloaded: > > http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/updates/12/SRPMS/ipa-1.2.2-3.fc12.src.rpm > > > > Regards rpm changed around F10 or 11. IIRC it uses SHA256 instead of MD5, that's why you are getting the error unpacking it. Try this instead: % rpm2cpio ipa-1.2.2-3.fc12.src.rpm | cpio -idv You'd need to do this anyway since you need to make some spec file changes. Replace the BuildRequires: popt-devel with popt If you are going to build against the CentOS RHDS then replace occurrences of fedora-ds with redhat-ds. 389-ds has a Provides for fedora-ds so things will just work if you are using 389-ds. Then: rpmbuild -ba ipa.spec I think that should do it assuming all the other build and install time dependencies we have are available in CentOS. rob From jhrozek at redhat.com Wed Mar 17 12:59:20 2010 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 17 Mar 2010 13:59:20 +0100 Subject: [Freeipa-users] Installing on Centos In-Reply-To: <2AA5506325476F4295EDDB5D15B08A560E59B3@HAMMBX01.uk.betfair.local> References: <2AA5506325476F4295EDDB5D15B08A560E59B3@HAMMBX01.uk.betfair.local> Message-ID: <4BA0D228.4050302@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/17/2010 11:22 AM, Gerrard Geldenhuis wrote: > Hi > I was wondering if anyone has had any luck in getting FreeIPA compiled and installed on Centos. I am struggling a bit at the moment. I have downloaded a fedora source package which I have tried to compile but can't even get the package to install at the moment. I get the error: > error: unpacking of archive failed on file /usr/src/redhat/SOURCES/Fix-install-with-krb-1.7.patch;4ba0aaed: cpio: MD5 sum mismatch > > This is the file I downloaded: > http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/updates/12/SRPMS/ipa-1.2.2-3.fc12.src.rpm > > Regards > Yes, newer Fedora (11 and later) releases are using SHA256 instead of MD5. I would suggest either building the source RPM from Fedora sources on the Centos 5 machine (cvs co freeipa, cd freeipa/F12/; make local), or just install the source RPM with --nomd5 and then rpmbuild the binary packages. Of course, the dependencies (both runtime and build) might be different on Centos vs. Fedora, so you might need to do some tweaking.. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkug0igACgkQHsardTLnvCVkQQCgq3rUgPcXPIa6wbSzkNaUBWuR nCMAnRmEn6V9g+CyY2W1qdRRUMKbCi5V =HoDo -----END PGP SIGNATURE----- From Gerrard.Geldenhuis at betfair.com Wed Mar 17 14:28:38 2010 From: Gerrard.Geldenhuis at betfair.com (Gerrard Geldenhuis) Date: Wed, 17 Mar 2010 14:28:38 +0000 Subject: [Freeipa-users] Installing on Centos In-Reply-To: <4BA0D228.4050302@redhat.com> References: <2AA5506325476F4295EDDB5D15B08A560E59B3@HAMMBX01.uk.betfair.local> <4BA0D228.4050302@redhat.com> Message-ID: <2AA5506325476F4295EDDB5D15B08A560E5C2B@HAMMBX01.uk.betfair.local> > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Jakub Hrozek > Sent: 17 March 2010 12:59 > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Installing on Centos > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/17/2010 11:22 AM, Gerrard Geldenhuis wrote: > > Yes, newer Fedora (11 and later) releases are using SHA256 instead of > MD5. > > I would suggest either building the source RPM from Fedora sources on > the Centos 5 machine (cvs co freeipa, cd freeipa/F12/; make local), or > just install the source RPM with --nomd5 and then rpmbuild the binary > packages. > > Of course, the dependencies (both runtime and build) might be different > on Centos vs. Fedora, so you might need to do some tweaking.. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > Thanks for all the feedback I have made some good headway and can at least start running the build, however I currently get this error: make[4]: Entering directory `/usr/src/redhat/BUILD/freeipa-1.2.2/ipa-server/ipa-gui' tg-admin i18n compile Traceback (most recent call last): File "/usr/bin/tg-admin", line 5, in ? from pkg_resources import load_entry_point File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 2479, in ? working_set.require(__requires__) File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 585, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 483, in resolve raise DistributionNotFound(req) # XXX put more info here pkg_resources.DistributionNotFound: Cheetah>=2.0.1 make[4]: *** [locales/ja/LC_MESSAGES/messages.mo] Error 1 make[4]: Leaving directory `/usr/src/redhat/BUILD/freeipa-1.2.2/ipa-server/ipa-gui' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/src/redhat/BUILD/freeipa-1.2.2/ipa-server/ipa-gui' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/freeipa-1.2.2/ipa-server' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/freeipa-1.2.2/ipa-server' make: *** [all] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.70572 (%build) I have the following Cheetah related packages installed: rpm -qa | grep -i cheetah python-cheetah-2.0.1-1.el5.rf python-turbocheetah-1.0-4.el5 I decided to stick with 389-DS, I don't know enough about the differences in the Centos-DS and 389-DS to make an informed decision about either. Defaults is thus good. I installed 389-DS from epel. Regards ________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. ________________________________________________________________________ From james.roman at ssaihq.com Wed Mar 17 15:32:55 2010 From: james.roman at ssaihq.com (James Roman) Date: Wed, 17 Mar 2010 11:32:55 -0400 Subject: [Freeipa-users] MemberOf plugin keeps disabling account Message-ID: <4BA0F627.8030106@ssaihq.com> I have a single account that keeps getting disabled by the memberOf Plugin, even though it is disabled. # MemberOf Plugin, plugins, config dn: cn=MemberOf Plugin,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: MemberOf Plugin nsslapd-pluginPath: libmemberof-plugin nsslapd-pluginInitfunc: memberof_postop_init nsslapd-pluginType: postoperation nsslapd-pluginEnabled: off nsslapd-plugin-depends-on-type: database memberofgroupattr: member memberofattr: memberOf nsslapd-pluginId: memberof nsslapd-pluginVersion: 1.2.5 nsslapd-pluginVendor: 389 Project nsslapd-pluginDescription: memberof plugin The individual account is on both the Active directory and our FreeIPA server. We keep trying to enable the account in Windows and in FreeIPA, but the plugin keeps following up and disabling it. time: 20100317111143 dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com changetype: modify replace: modifiersName modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20100317151114Z - time: 20100317111526 dn: cn=inactivated,cn=account inactivation,cn=accounts,dc=domain,dc=com changetype: modify delete: member member: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com - replace: modifiersname modifiersname: uid=FreeipaAdminUser,cn=users,cn=accounts,dc=domain,dc=com - replace: modifytimestamp modifytimestamp: 20100317151526Z - time: 20100317111526 dn: cn=activated,cn=account inactivation,cn=accounts,dc=domain,dc=com changetype: modify add: member member: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com - replace: modifiersname modifiersname: uid=FreeipaAdminUser,cn=users,cn=accounts,dc=domain,dc=com - replace: modifytimestamp modifytimestamp: 20100317151526Z - time: 20100317111527 dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com changetype: modify replace: modifiersName modifiersName: cn=ipa-memberof,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20100317151502Z - time: 20100317111529 dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com changetype: modify replace: modifiersName modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20100317151502Z - time: 20100317111530 dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com changetype: modify replace: modifiersName modifiersName: cn=ipa-memberof,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20100317151502Z - time: 20100317111530 dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com changetype: modify replace: modifiersName modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20100317151502Z - time: 20100317111640 dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com changetype: modify replace: modifiersName modifiersName: cn=ipa-memberof,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20100317151615Z - time: 20100317111642 dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com changetype: modify replace: modifiersName modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20100317151615Z - time: 20100317111642 dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com changetype: modify replace: modifiersName modifiersName: cn=ipa-memberof,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20100317151615Z - time: 20100317111643 dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com changetype: modify replace: modifiersName modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20100317151615Z Am I missing something? What do I need to do to get the MemeberOf plugin from stepping on our changes? We have FreeIPA 1.2.2 and 389-DS 1.2.5 on FC11. From rcritten at redhat.com Wed Mar 17 15:53:47 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Mar 2010 11:53:47 -0400 Subject: [Freeipa-users] MemberOf plugin keeps disabling account In-Reply-To: <4BA0F627.8030106@ssaihq.com> References: <4BA0F627.8030106@ssaihq.com> Message-ID: <4BA0FB0B.2060006@redhat.com> James Roman wrote: > I have a single account that keeps getting disabled by the memberOf > Plugin, even though it is disabled. [ SNIP ] > Am I missing something? What do I need to do to get the MemeberOf plugin > from stepping on our changes? We have FreeIPA 1.2.2 and 389-DS 1.2.5 on > FC11. I don't think you want to disable memberof, it will probably break other stuff. I'm guessing you did this to see what would happen. Did you restart the DS after disabling it? I believe that is required. How are you unlocking the user, using the ipa-lockuser tool? I should note that a user doesn't need to be in cn=activated to be unlocked, they just need to not be in cn=inactivated. The cn=activated is there so you can disable a group (which will in turn inactivate all members of that group) and then go back and set some group members to be re-activated. rob From james.roman at ssaihq.com Wed Mar 17 17:09:16 2010 From: james.roman at ssaihq.com (James Roman) Date: Wed, 17 Mar 2010 13:09:16 -0400 Subject: [Freeipa-users] MemberOf plugin keeps disabling account In-Reply-To: <4BA0FB0B.2060006@redhat.com> References: <4BA0F627.8030106@ssaihq.com> <4BA0FB0B.2060006@redhat.com> Message-ID: <4BA10CBC.8050001@ssaihq.com> OK. I Think I've got this licked. I had to manually activate the account on both the Active Directory and the FreeIPA server. I think what was happening was this: 1. Admin activates the account on IPA server (moves cn=inactivated to cn-activated) 2. IPA server schedules windows sync 3. IPA server reads windows status disabled 4. IPA disables FreeIPA account 5. IPA server updates AD account to enable 6. IPA server schedules 2nd windows sync 7. IPA server updates AD account to disable I don't know why this account is encountering this issue. It just started flipping disabled at about 2:00 am today. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.roman at ssaihq.com Wed Mar 17 18:01:47 2010 From: james.roman at ssaihq.com (James Roman) Date: Wed, 17 Mar 2010 14:01:47 -0400 Subject: [Freeipa-users] MemberOf plugin keeps disabling account In-Reply-To: <4BA10EB2.6060707@redhat.com> References: <4BA0F627.8030106@ssaihq.com> <4BA0FB0B.2060006@redhat.com> <4BA102CB.4010605@ssaihq.com> <4BA10EB2.6060707@redhat.com> Message-ID: <4BA1190B.7090409@ssaihq.com> > Well, the current 389 memberOf is a bit more advanced than the > ipa-memberOf. We did the initial development of the plugin, then it > got moved into mainline 389-ds. The ipa plugin should work fine > though, I don't know of any reason to switch. > > rob Any idea why both are being executed? Even when the MemberOf Plugin is disabled? # ipa-memberof, plugins, config dn: cn=ipa-memberof,cn=plugins,cn=config ...... nsslapd-pluginEnabled: on # MemberOf Plugin, plugins, config dn: cn=MemberOf Plugin,cn=plugins,cn=config ...... nsslapd-pluginEnabled: off Is it possible that the DS upgrade steps on the ipa-memberof libraries in some way, causing both to be executed? I would imagine that having two plugins making the same update to the directory could be problematic. Maybe its the way the audit logging is occurring. From ssorce at redhat.com Wed Mar 17 19:05:09 2010 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 17 Mar 2010 15:05:09 -0400 Subject: [Freeipa-users] MemberOf plugin keeps disabling account In-Reply-To: <4BA1190B.7090409@ssaihq.com> References: <4BA0F627.8030106@ssaihq.com> <4BA0FB0B.2060006@redhat.com> <4BA102CB.4010605@ssaihq.com> <4BA10EB2.6060707@redhat.com> <4BA1190B.7090409@ssaihq.com> Message-ID: <20100317150509.341181f5@willson.li.ssimo.org> On Wed, 17 Mar 2010 14:01:47 -0400 James Roman wrote: > > > Well, the current 389 memberOf is a bit more advanced than the > > ipa-memberOf. We did the initial development of the plugin, then it > > got moved into mainline 389-ds. The ipa plugin should work fine > > though, I don't know of any reason to switch. > > > > rob > Any idea why both are being executed? Even when the MemberOf Plugin > is disabled? > > # ipa-memberof, plugins, config > dn: cn=ipa-memberof,cn=plugins,cn=config > ...... > nsslapd-pluginEnabled: on > > > # MemberOf Plugin, plugins, config > dn: cn=MemberOf Plugin,cn=plugins,cn=config > ...... > nsslapd-pluginEnabled: off > > Is it possible that the DS upgrade steps on the ipa-memberof > libraries in some way, causing both to be executed? I would imagine > that having two plugins making the same update to the directory could > be problematic. Maybe its the way the audit logging is occurring. To actually disable the plugin you need a restart after you change the config, but please *do not* do that unless you want trouble :) The memberof plugin does not change group memberships it only updates the memberof attribute to keep it in sync with the member ones. Simo. -- Simo Sorce * Red Hat, Inc * New York From james.roman at ssaihq.com Wed Mar 17 19:24:18 2010 From: james.roman at ssaihq.com (James Roman) Date: Wed, 17 Mar 2010 15:24:18 -0400 Subject: [Freeipa-users] MemberOf plugin keeps disabling account In-Reply-To: <20100317150509.341181f5@willson.li.ssimo.org> References: <4BA0F627.8030106@ssaihq.com> <4BA0FB0B.2060006@redhat.com> <4BA102CB.4010605@ssaihq.com> <4BA10EB2.6060707@redhat.com> <4BA1190B.7090409@ssaihq.com> <20100317150509.341181f5@willson.li.ssimo.org> Message-ID: <4BA12C62.40902@ssaihq.com> > To actually disable the plugin you need a restart after you change the > config, but please *do not* do that unless you want trouble :) > > The memberof plugin does not change group memberships it only updates > the memberof attribute to keep it in sync with the member ones. > > Simo. > > Just to clarify, we never disabled the 389 MemberOf plugin. My original ldif dump after the upgrade to 1.2.5 had the 389 DS memberOf plugin disabled. So it never was enabled. This probably meant little to us from a functional standpoint because we already had the FreeIPA ipa_memberof plugin installed and enabled. Do I need both of them enabled? Or will that cause additional misery? Of the two, ipa-memberof and 389's memberOf plugin, which should I enable? From ssorce at redhat.com Wed Mar 17 19:54:20 2010 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 17 Mar 2010 15:54:20 -0400 Subject: [Freeipa-users] MemberOf plugin keeps disabling account In-Reply-To: <4BA12C62.40902@ssaihq.com> References: <4BA0F627.8030106@ssaihq.com> <4BA0FB0B.2060006@redhat.com> <4BA102CB.4010605@ssaihq.com> <4BA10EB2.6060707@redhat.com> <4BA1190B.7090409@ssaihq.com> <20100317150509.341181f5@willson.li.ssimo.org> <4BA12C62.40902@ssaihq.com> Message-ID: <20100317155420.2ea97654@willson.li.ssimo.org> On Wed, 17 Mar 2010 15:24:18 -0400 James Roman wrote: > > > To actually disable the plugin you need a restart after you change > > the config, but please *do not* do that unless you want trouble :) > > > > The memberof plugin does not change group memberships it only > > updates the memberof attribute to keep it in sync with the member > > ones. > > > > Simo. > > > > > Just to clarify, we never disabled the 389 MemberOf plugin. My > original ldif dump after the upgrade to 1.2.5 had the 389 DS memberOf > plugin disabled. So it never was enabled. This probably meant little > to us from a functional standpoint because we already had the FreeIPA > ipa_memberof plugin installed and enabled. > > Do I need both of them enabled? Or will that cause additional misery? > Of the two, ipa-memberof and 389's memberOf plugin, which should I > enable? > Oh sorry, no I misunderstood. You can't have both enabled they would interfere, only one or the other. The 389 memberof plugin is probably better now, as we merge all the code we developed for ipa in there. But unless you have specific problems you can just leave it as it is. Simo. -- Simo Sorce * Red Hat, Inc * New York From james.roman at ssaihq.com Wed Mar 17 20:00:02 2010 From: james.roman at ssaihq.com (James Roman) Date: Wed, 17 Mar 2010 16:00:02 -0400 Subject: [Freeipa-users] MemberOf plugin keeps disabling account In-Reply-To: <20100317150509.341181f5@willson.li.ssimo.org> References: <4BA0F627.8030106@ssaihq.com> <4BA0FB0B.2060006@redhat.com> <4BA102CB.4010605@ssaihq.com> <4BA10EB2.6060707@redhat.com> <4BA1190B.7090409@ssaihq.com> <20100317150509.341181f5@willson.li.ssimo.org> Message-ID: <4BA134C2.4040403@ssaihq.com> > The memberof plugin does not change group memberships it only updates > the memberof attribute to keep it in sync with the member ones. > > Simo. > > I made a mistake interpreting the audit log initially. I realized after I created the subject that the MemberOf changes reflect the changes being made in the background to the individual record to populate the memberOf attributes for the change I initiated. Since the audit records don't actually say what the MemberOf plugins are changing in the record (they only report updating the modifiersname), I thought it was actually what was changing the group membership back. Something else was changing the group membership back (or rolling back the initial change), but it is not being recorded in the audit logs. I still can't get my head around why the audit log reports both plugins making changes to the record, even though the 389 MemberOf plugin is disabled. time: 20100317111527 dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com changetype: modify replace: modifiersName modifiersName: cn=ipa-memberof,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20100317151502Z - time: 20100317111529 dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com changetype: modify replace: modifiersName modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config From james.roman at ssaihq.com Thu Mar 18 16:15:09 2010 From: james.roman at ssaihq.com (James Roman) Date: Thu, 18 Mar 2010 12:15:09 -0400 Subject: [Freeipa-users] MemberOf plugin keeps disabling account In-Reply-To: <4BA134C2.4040403@ssaihq.com> References: <4BA0F627.8030106@ssaihq.com> <4BA0FB0B.2060006@redhat.com> <4BA102CB.4010605@ssaihq.com> <4BA10EB2.6060707@redhat.com> <4BA1190B.7090409@ssaihq.com> <20100317150509.341181f5@willson.li.ssimo.org> <4BA134C2.4040403@ssaihq.com> Message-ID: <4BA2518D.5000404@ssaihq.com> Just for posterity. The issue ended up being that the AD and FreeIPA were out of sync. One of the sub-containers in the Active Directory containing disabled accounts was moved outside of the scope of the sync agreement. We never ran a replica init, so a number of scheduled syncs were pending. On 03/17/2010 04:00 PM, James Roman wrote: > >> The memberof plugin does not change group memberships it only updates >> the memberof attribute to keep it in sync with the member ones. >> >> Simo. >> > I made a mistake interpreting the audit log initially. I realized > after I created the subject that the MemberOf changes reflect the > changes being made in the background to the individual record to > populate the memberOf attributes for the change I initiated. Since the > audit records don't actually say what the MemberOf plugins are > changing in the record (they only report updating the modifiersname), > I thought it was actually what was changing the group membership back. > > Something else was changing the group membership back (or rolling back > the initial change), but it is not being recorded in the audit logs. > > I still can't get my head around why the audit log reports both > plugins making changes to the record, even though the 389 MemberOf > plugin is disabled. > > time: 20100317111527 > dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com > changetype: modify > replace: modifiersName > modifiersName: cn=ipa-memberof,cn=plugins,cn=config > - > replace: modifyTimestamp > modifyTimestamp: 20100317151502Z > - > > time: 20100317111529 > dn: uid=afflicted.user,cn=users,cn=accounts,dc=domain,dc=com > changetype: modify > replace: modifiersName > modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Thu Mar 18 20:44:01 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Mar 2010 16:44:01 -0400 Subject: [Freeipa-users] MemberOf plugin keeps disabling account In-Reply-To: <4BA2518D.5000404@ssaihq.com> References: <4BA0F627.8030106@ssaihq.com> <4BA0FB0B.2060006@redhat.com> <4BA102CB.4010605@ssaihq.com> <4BA10EB2.6060707@redhat.com> <4BA1190B.7090409@ssaihq.com> <20100317150509.341181f5@willson.li.ssimo.org> <4BA134C2.4040403@ssaihq.com> <4BA2518D.5000404@ssaihq.com> Message-ID: <4BA29091.7070406@redhat.com> James Roman wrote: > Just for posterity. The issue ended up being that the AD and FreeIPA > were out of sync. One of the sub-containers in the Active Directory > containing disabled accounts was moved outside of the scope of the sync > agreement. We never ran a replica init, so a number of scheduled syncs > were pending. Glad you figured it out. Thanks for closing the loop :-) cheers rob From wgmeyer at gmail.com Thu Mar 18 21:58:26 2010 From: wgmeyer at gmail.com (Walter Meyer) Date: Thu, 18 Mar 2010 17:58:26 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support Message-ID: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> I am testing out FreeIPA and am wondering if FreeIPA is compatible with the Google Apps password sync utility. Specifically my question in relation to FreeIPA is how the password attribute is stored in the DS? Is it in any of these Google Apps supported formats: MD5, SHA1, or Plain Text? If not can I change it to one of these, or is this a bad idea? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Mar 18 22:10:45 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Mar 2010 18:10:45 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> Message-ID: <4BA2A4E5.9020603@redhat.com> Walter Meyer wrote: > I am testing out FreeIPA and am wondering if FreeIPA is compatible with > the Google Apps password sync utility. Specifically my question in > relation to FreeIPA is how the password attribute is stored in the DS? > Is it in any of these Google Apps supported formats: MD5, SHA1, or Plain > Text? If not can I change it to one of these, or is this a bad idea? > Thanks in advance. > I'm not familiar with the Google Apps password sync utility, do you have any pointers describing how it works? In general though IPA needs to receive password changes in cleartext so it can generate matching kerberos keys. We can currently accept password changes over LDAP and the kerberos password protocol. Setting a password using either of these methods keeps all passwords/keys in sync. This requires an encrypted channel using either SSL or SASL. rob From wgmeyer at gmail.com Thu Mar 18 23:47:35 2010 From: wgmeyer at gmail.com (Walter Meyer) Date: Thu, 18 Mar 2010 19:47:35 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <4BA2A4E5.9020603@redhat.com> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> <4BA2A4E5.9020603@redhat.com> Message-ID: <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> Sorry I should have linked to the manual for it: http://www.postini.com/webdocs/gads/admin The Google Apps utility actually syncs passwords from LDAP to Google Apps, not the other way around. The manual says that the utility supports password attributes in MD5, SHA1, or Clear Text. So I am wondering how they are stored in the IPA DS. On Thu, Mar 18, 2010 at 6:10 PM, Rob Crittenden wrote: > Walter Meyer wrote: > >> I am testing out FreeIPA and am wondering if FreeIPA is compatible with >> the Google Apps password sync utility. Specifically my question in relation >> to FreeIPA is how the password attribute is stored in the DS? Is it in any >> of these Google Apps supported formats: MD5, SHA1, or Plain Text? If not can >> I change it to one of these, or is this a bad idea? Thanks in advance. >> >> > I'm not familiar with the Google Apps password sync utility, do you have > any pointers describing how it works? > > In general though IPA needs to receive password changes in cleartext so it > can generate matching kerberos keys. We can currently accept password > changes over LDAP and the kerberos password protocol. Setting a password > using either of these methods keeps all passwords/keys in sync. This > requires an encrypted channel using either SSL or SASL. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Mar 19 15:25:31 2010 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 19 Mar 2010 11:25:31 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> <4BA2A4E5.9020603@redhat.com> <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> Message-ID: <4BA3976B.4040107@redhat.com> Walter Meyer wrote: > Sorry I should have linked to the manual for it: > http://www.postini.com/webdocs/gads/admin > > The Google Apps utility actually syncs passwords from LDAP to Google > Apps, not the other way around. The manual says that the utility > supports password attributes in MD5, SHA1, or Clear Text. So I am > wondering how they are stored in the IPA DS. > All three of these methods are completely insecure. Rob correct me if I am wrong but if you log as a Directory Manager and do a ldap search you will see all the passwords in a user entry. AFAIR they are prefixed with the {type} something like this. But I do not remember them being MD5, SHA1 or cleartext by default. If you look at the Administration manual for the underlaying directory server http://www.redhat.com/docs/manuals/dir-server/pdf/ds80admin.pdf you will find the section 16.1.x that talks about enabling different plugins. If you really want your IPA server to be insecure you can enable one of those plugins and it will cause the creation of the passwords in a corresponding scheme. But this is all really insecure and should not be considered a viable solution in a production environment. What are the Google Applications that you need the password for? Can you present the original use case and explain your goals? May be there are more secure ways to make Google Apps happy then creating insecure hashes in the IPA. Thanks Dmitri > On Thu, Mar 18, 2010 at 6:10 PM, Rob Crittenden > wrote: > > Walter Meyer wrote: > > I am testing out FreeIPA and am wondering if FreeIPA is > compatible with the Google Apps password sync utility. > Specifically my question in relation to FreeIPA is how the > password attribute is stored in the DS? Is it in any of these > Google Apps supported formats: MD5, SHA1, or Plain Text? If > not can I change it to one of these, or is this a bad idea? > Thanks in advance. > > > I'm not familiar with the Google Apps password sync utility, do > you have any pointers describing how it works? > > In general though IPA needs to receive password changes in > cleartext so it can generate matching kerberos keys. We can > currently accept password changes over LDAP and the kerberos > password protocol. Setting a password using either of these > methods keeps all passwords/keys in sync. This requires an > encrypted channel using either SSL or SASL. > > rob > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From wgmeyer at gmail.com Fri Mar 19 17:44:49 2010 From: wgmeyer at gmail.com (Walter Meyer) Date: Fri, 19 Mar 2010 13:44:49 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <4BA3976B.4040107@redhat.com> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> <4BA2A4E5.9020603@redhat.com> <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> <4BA3976B.4040107@redhat.com> Message-ID: <6ba5d9ef1003191044hf7807dj1c3a1419297c620f@mail.gmail.com> We would be using Google Apps for our email system (and other services included with GA like Google Docs etc.) I'd like to have one password for users when they access their email via Google Apps, ideally the users and passwords would be centralized in IPA. According to the Google documentation they only support updating user passwords with the utility or through the API's that are encoded in MD5, SHA1, or clear text. Another option I have considered is implementing a SSO solution like Shibboleth (integrated with IPA) and having users login to their email and other Google Apps services using that, as Google Apps supports SAML. But the SAML SSO solution wouldn't work with IMAP and users would have to maintain a separate password for this. Yet another option would be to write a web app that would send a password change simultaneously to Google Apps via their API's and to the IPA server, so the passwords would be the same as long as the end-user only used the web app to change their password. http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html So my goal is to have one password for Directory Services (IPA) and Google Apps services if possible. Thanks, Walter On Fri, Mar 19, 2010 at 11:25 AM, Dmitri Pal wrote: > Walter Meyer wrote: > > Sorry I should have linked to the manual for it: > > http://www.postini.com/webdocs/gads/admin > > > > The Google Apps utility actually syncs passwords from LDAP to Google > > Apps, not the other way around. The manual says that the utility > > supports password attributes in MD5, SHA1, or Clear Text. So I am > > wondering how they are stored in the IPA DS. > > > All three of these methods are completely insecure. > Rob correct me if I am wrong but if you log as a Directory Manager and > do a ldap search you will see all the passwords in a user entry. > AFAIR they are prefixed with the {type} something like this. But I do > not remember them being MD5, SHA1 or cleartext by default. > > If you look at the Administration manual for the underlaying directory > server > http://www.redhat.com/docs/manuals/dir-server/pdf/ds80admin.pdf > you will find the section 16.1.x that talks about enabling different > plugins. > If you really want your IPA server to be insecure you can enable one of > those plugins and it will cause the creation of the passwords in a > corresponding scheme. > But this is all really insecure and should not be considered a viable > solution in a production environment. > > What are the Google Applications that you need the password for? > Can you present the original use case and explain your goals? > May be there are more secure ways to make Google Apps happy then > creating insecure hashes in the IPA. > > Thanks > Dmitri > > On Thu, Mar 18, 2010 at 6:10 PM, Rob Crittenden > > wrote: > > > > Walter Meyer wrote: > > > > I am testing out FreeIPA and am wondering if FreeIPA is > > compatible with the Google Apps password sync utility. > > Specifically my question in relation to FreeIPA is how the > > password attribute is stored in the DS? Is it in any of these > > Google Apps supported formats: MD5, SHA1, or Plain Text? If > > not can I change it to one of these, or is this a bad idea? > > Thanks in advance. > > > > > > I'm not familiar with the Google Apps password sync utility, do > > you have any pointers describing how it works? > > > > In general though IPA needs to receive password changes in > > cleartext so it can generate matching kerberos keys. We can > > currently accept password changes over LDAP and the kerberos > > password protocol. Setting a password using either of these > > methods keeps all passwords/keys in sync. This requires an > > encrypted channel using either SSL or SASL. > > > > rob > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Mar 19 18:02:45 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Mar 2010 14:02:45 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <4BA3976B.4040107@redhat.com> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> <4BA2A4E5.9020603@redhat.com> <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> <4BA3976B.4040107@redhat.com> Message-ID: <4BA3BC45.9040402@redhat.com> Dmitri Pal wrote: > Walter Meyer wrote: >> Sorry I should have linked to the manual for it: >> http://www.postini.com/webdocs/gads/admin >> >> The Google Apps utility actually syncs passwords from LDAP to Google >> Apps, not the other way around. The manual says that the utility >> supports password attributes in MD5, SHA1, or Clear Text. So I am >> wondering how they are stored in the IPA DS. >> > All three of these methods are completely insecure. > Rob correct me if I am wrong but if you log as a Directory Manager and > do a ldap search you will see all the passwords in a user entry. > AFAIR they are prefixed with the {type} something like this. But I do > not remember them being MD5, SHA1 or cleartext by default. I believe the default is SSHA (salted SHA1). > If you look at the Administration manual for the underlaying directory > server > http://www.redhat.com/docs/manuals/dir-server/pdf/ds80admin.pdf > you will find the section 16.1.x that talks about enabling different > plugins. > If you really want your IPA server to be insecure you can enable one of > those plugins and it will cause the creation of the passwords in a > corresponding scheme. > But this is all really insecure and should not be considered a viable > solution in a production environment. Well, it certainly would be insecure for anyone that can read password values. By default nobody but the Directory Manager can get at the hash values. > > What are the Google Applications that you need the password for? > Can you present the original use case and explain your goals? > May be there are more secure ways to make Google Apps happy then > creating insecure hashes in the IPA. Google Apps covers a broad spectrum of things from gmail, calendar to docs, groups (mailing lists) and more. I have to agree with Dmitri that I'd think long and hard about what implications there are changing the password storage schema and syncing them with another product. The Google sync documentation isn't exactly clear how the channel between the LDAP sync tool and the Google App server is protected. For example, the default configuration from the tool to the LDAP server is in the clear. So I think that yes it is possible, I don't think I'd recommend it at this point. You might check with the folks at Google. It could be that their documentation is behind the product so salted-SHA may already be supported. Then see if there is a way to secure all communication with SSL (it may very well work today, I didn't dive too deeply into the documentation). regards rob > > Thanks > Dmitri >> On Thu, Mar 18, 2010 at 6:10 PM, Rob Crittenden > > wrote: >> >> Walter Meyer wrote: >> >> I am testing out FreeIPA and am wondering if FreeIPA is >> compatible with the Google Apps password sync utility. >> Specifically my question in relation to FreeIPA is how the >> password attribute is stored in the DS? Is it in any of these >> Google Apps supported formats: MD5, SHA1, or Plain Text? If >> not can I change it to one of these, or is this a bad idea? >> Thanks in advance. >> >> >> I'm not familiar with the Google Apps password sync utility, do >> you have any pointers describing how it works? >> >> In general though IPA needs to receive password changes in >> cleartext so it can generate matching kerberos keys. We can >> currently accept password changes over LDAP and the kerberos >> password protocol. Setting a password using either of these >> methods keeps all passwords/keys in sync. This requires an >> encrypted channel using either SSL or SASL. >> >> rob >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > From dpal at redhat.com Fri Mar 19 18:03:01 2010 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 19 Mar 2010 14:03:01 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <6ba5d9ef1003191044hf7807dj1c3a1419297c620f@mail.gmail.com> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> <4BA2A4E5.9020603@redhat.com> <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> <4BA3976B.4040107@redhat.com> <6ba5d9ef1003191044hf7807dj1c3a1419297c620f@mail.gmail.com> Message-ID: <4BA3BC55.6000502@redhat.com> Walter Meyer wrote: > We would be using Google Apps for our email system (and other services > included with GA like Google Docs etc.) I'd like to have one password > for users when they access their email via Google Apps, ideally the > users and passwords would be centralized in IPA. > > According to the Google documentation they only support updating user > passwords with the utility or through the API's that are encoded in > MD5, SHA1, or clear text. > > Another option I have considered is implementing a SSO solution like > Shibboleth (integrated with IPA) and having users login to their email > and other Google Apps services using that, as Google Apps supports > SAML. But the SAML SSO solution wouldn't work with IMAP and users > would have to maintain a separate password for this. Yet another > option would be to write a web app that would send a password change > simultaneously to Google Apps via their API's and to the IPA server, > so the passwords would be the same as long as the end-user only used > the web app to change their password. > > http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html > > So my goal is to have one password for Directory Services (IPA) and > Google Apps services if possible. > I wonder if it would be better to take advantage of the passync utility provided by DS to replicate passwords and update them in the external source. Can Google Apps use a local DS instance as a back end? This way the IPA can be set up to update passwords in this instance via passync using of the shelf utilities provided by DS. > Thanks, > Walter > > On Fri, Mar 19, 2010 at 11:25 AM, Dmitri Pal > wrote: > > Walter Meyer wrote: > > Sorry I should have linked to the manual for it: > > http://www.postini.com/webdocs/gads/admin > > > > The Google Apps utility actually syncs passwords from LDAP to Google > > Apps, not the other way around. The manual says that the utility > > supports password attributes in MD5, SHA1, or Clear Text. So I am > > wondering how they are stored in the IPA DS. > > > All three of these methods are completely insecure. > Rob correct me if I am wrong but if you log as a Directory Manager and > do a ldap search you will see all the passwords in a user entry. > AFAIR they are prefixed with the {type} something like this. But I do > not remember them being MD5, SHA1 or cleartext by default. > > If you look at the Administration manual for the underlaying directory > server > http://www.redhat.com/docs/manuals/dir-server/pdf/ds80admin.pdf > you will find the section 16.1.x that talks about enabling different > plugins. > If you really want your IPA server to be insecure you can enable > one of > those plugins and it will cause the creation of the passwords in a > corresponding scheme. > But this is all really insecure and should not be considered a viable > solution in a production environment. > > What are the Google Applications that you need the password for? > Can you present the original use case and explain your goals? > May be there are more secure ways to make Google Apps happy then > creating insecure hashes in the IPA. > > Thanks > Dmitri > > On Thu, Mar 18, 2010 at 6:10 PM, Rob Crittenden > > > >> wrote: > > > > Walter Meyer wrote: > > > > I am testing out FreeIPA and am wondering if FreeIPA is > > compatible with the Google Apps password sync utility. > > Specifically my question in relation to FreeIPA is how the > > password attribute is stored in the DS? Is it in any of > these > > Google Apps supported formats: MD5, SHA1, or Plain Text? If > > not can I change it to one of these, or is this a bad idea? > > Thanks in advance. > > > > > > I'm not familiar with the Google Apps password sync utility, do > > you have any pointers describing how it works? > > > > In general though IPA needs to receive password changes in > > cleartext so it can generate matching kerberos keys. We can > > currently accept password changes over LDAP and the kerberos > > password protocol. Setting a password using either of these > > methods keeps all passwords/keys in sync. This requires an > > encrypted channel using either SSL or SASL. > > > > rob > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Fri Mar 19 18:06:12 2010 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 19 Mar 2010 14:06:12 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> <4BA2A4E5.9020603@redhat.com> <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> Message-ID: <20100319140612.08b2315e@willson.li.ssimo.org> On Thu, 18 Mar 2010 19:47:35 -0400 Walter Meyer wrote: > Sorry I should have linked to the manual for it: > http://www.postini.com/webdocs/gads/admin > > The Google Apps utility actually syncs passwords from LDAP to Google > Apps, not the other way around. The manual says that the utility > supports password attributes in MD5, SHA1, or Clear Text. So I am > wondering how they are stored in the IPA DS. By default we use Salted SHA (SSHA) for the userPassword attribute. You can change it by changing the passwordStorageScheme attribute (see chapter 7 of the directory server guide), but you will probably have to perform a password change for each user that needs synchronization if you already have passwords set, because the hash can be changed only when the clear text password is available. I have to say though that MD5/SHA1 are considered weak today, esp MD5. Also you should make sure you understand the implication of exposing your internal passwords over the network. By using the same hash for google apps it means you users will send their IPA password to google for authentication (hopefully over HTTPS) so if someone can phish or mitm them they will have the right password for both google apps *and* your company resources. Simo. -- Simo Sorce * Red Hat, Inc * New York From wgmeyer at gmail.com Fri Mar 19 20:18:26 2010 From: wgmeyer at gmail.com (Walter Meyer) Date: Fri, 19 Mar 2010 16:18:26 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <20100319140612.08b2315e@willson.li.ssimo.org> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> <4BA2A4E5.9020603@redhat.com> <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> <20100319140612.08b2315e@willson.li.ssimo.org> Message-ID: <6ba5d9ef1003191318m3bb54f5id6c9aecb5d52cd6f@mail.gmail.com> I will see if Salted SHA1 is supported and maybe Google hasn't documented it yet. If not, the sync is done with the Google Servers over SSL. And if only the Directory Manager can read the userPassword attribute, would storing the userPassword attribute in SHA1 be that insecure? What scenario could the passwords be compromised if I went with this setup? Unless the Directory Manager account was compromised wouldn't this be secure if all of the data was being transmitted over SSL? Also all logins to Google Apps are encrypted with SSL. Thanks, Walter On Fri, Mar 19, 2010 at 2:06 PM, Simo Sorce wrote: > On Thu, 18 Mar 2010 19:47:35 -0400 > Walter Meyer wrote: > > > Sorry I should have linked to the manual for it: > > http://www.postini.com/webdocs/gads/admin > > > > The Google Apps utility actually syncs passwords from LDAP to Google > > Apps, not the other way around. The manual says that the utility > > supports password attributes in MD5, SHA1, or Clear Text. So I am > > wondering how they are stored in the IPA DS. > > By default we use Salted SHA (SSHA) for the userPassword attribute. > You can change it by changing the passwordStorageScheme attribute (see > chapter 7 of the directory server guide), but you will probably have to > perform a password change for each user that needs synchronization if > you already have passwords set, because the hash can be changed only > when the clear text password is available. > > I have to say though that MD5/SHA1 are considered weak today, esp MD5. > > Also you should make sure you understand the implication of exposing > your internal passwords over the network. > > By using the same hash for google apps it means you users will send > their IPA password to google for authentication (hopefully over HTTPS) > so if someone can phish or mitm them they will have the right password > for both google apps *and* your company resources. > > 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 rcritten at redhat.com Fri Mar 19 20:28:22 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Mar 2010 16:28:22 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <4BA3BC55.6000502@redhat.com> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> <4BA2A4E5.9020603@redhat.com> <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> <4BA3976B.4040107@redhat.com> <6ba5d9ef1003191044hf7807dj1c3a1419297c620f@mail.gmail.com> <4BA3BC55.6000502@redhat.com> Message-ID: <4BA3DE66.8080101@redhat.com> Dmitri Pal wrote: > Walter Meyer wrote: >> We would be using Google Apps for our email system (and other services >> included with GA like Google Docs etc.) I'd like to have one password >> for users when they access their email via Google Apps, ideally the >> users and passwords would be centralized in IPA. >> >> According to the Google documentation they only support updating user >> passwords with the utility or through the API's that are encoded in >> MD5, SHA1, or clear text. >> >> Another option I have considered is implementing a SSO solution like >> Shibboleth (integrated with IPA) and having users login to their email >> and other Google Apps services using that, as Google Apps supports >> SAML. But the SAML SSO solution wouldn't work with IMAP and users >> would have to maintain a separate password for this. Yet another >> option would be to write a web app that would send a password change >> simultaneously to Google Apps via their API's and to the IPA server, >> so the passwords would be the same as long as the end-user only used >> the web app to change their password. >> >> http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html >> >> So my goal is to have one password for Directory Services (IPA) and >> Google Apps services if possible. >> > I wonder if it would be better to take advantage of the passync utility > provided by DS to replicate passwords and update them in the external > source. passsync is for syncing passwords with Active Directory. > Can Google Apps use a local DS instance as a back end? > This way the IPA can be set up to update passwords in this instance via > passync using of the shelf utilities provided by DS. If they could use DS as a local backend then could just authenticate directly against the IPA LDAP server. rob From rcritten at redhat.com Fri Mar 19 20:43:42 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Mar 2010 16:43:42 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <6ba5d9ef1003191318m3bb54f5id6c9aecb5d52cd6f@mail.gmail.com> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> <4BA2A4E5.9020603@redhat.com> <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> <20100319140612.08b2315e@willson.li.ssimo.org> <6ba5d9ef1003191318m3bb54f5id6c9aecb5d52cd6f@mail.gmail.com> Message-ID: <4BA3E1FE.9030009@redhat.com> Walter Meyer wrote: > I will see if Salted SHA1 is supported and maybe Google hasn't > documented it yet. If not, the sync is done with the Google Servers over > SSL. And if only the Directory Manager can read the userPassword > attribute, would storing the userPassword attribute in SHA1 be that > insecure? What scenario could the passwords be compromised if I went > with this setup? Unless the Directory Manager account was compromised > wouldn't this be secure if all of the data was being transmitted over SSL? > > Also all logins to Google Apps are encrypted with SSL. Ok, the SSL usage makes me feel better. Using a weaker password encryption scheme isn't ideal but if you are protecting transmission of it you are probably ok. The risk is that if somehow the hash did get exposed it is relatively easier to crack it than a salted hash. Risk is something you'll need to weigh specific to your environment, this may be acceptable. It doesn't make my alarm bells go off but I'm a pretty laid back guy :-) In fact, this would be very cool if it worked. You might want to file an RFE with the nice folks at Google to see if they'll support salted hashes if they don't now and potentially move to a more secure environment later. As Simo pointed out you'll want to modify the default password encryption scheme before adding your users so you don't have to force round after round of password changes on them. If you decide to try it out let us know how it works. cheers rob From wgmeyer at gmail.com Fri Mar 19 20:33:59 2010 From: wgmeyer at gmail.com (Walter Meyer) Date: Fri, 19 Mar 2010 16:33:59 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <4BA3DE66.8080101@redhat.com> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> <4BA2A4E5.9020603@redhat.com> <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> <4BA3976B.4040107@redhat.com> <6ba5d9ef1003191044hf7807dj1c3a1419297c620f@mail.gmail.com> <4BA3BC55.6000502@redhat.com> <4BA3DE66.8080101@redhat.com> Message-ID: <6ba5d9ef1003191333r3e778bfdq6a8647e9ee6fb5aa@mail.gmail.com> Google Apps uses its own user database, as of now there is no way to direct it to a backend one, so the only option is to sync with the Google Apps database. On Fri, Mar 19, 2010 at 4:28 PM, Rob Crittenden wrote: > Dmitri Pal wrote: > >> Walter Meyer wrote: >> >>> We would be using Google Apps for our email system (and other services >>> included with GA like Google Docs etc.) I'd like to have one password >>> for users when they access their email via Google Apps, ideally the >>> users and passwords would be centralized in IPA. >>> >>> According to the Google documentation they only support updating user >>> passwords with the utility or through the API's that are encoded in >>> MD5, SHA1, or clear text. >>> >>> Another option I have considered is implementing a SSO solution like >>> Shibboleth (integrated with IPA) and having users login to their email >>> and other Google Apps services using that, as Google Apps supports >>> SAML. But the SAML SSO solution wouldn't work with IMAP and users >>> would have to maintain a separate password for this. Yet another >>> option would be to write a web app that would send a password change >>> simultaneously to Google Apps via their API's and to the IPA server, >>> so the passwords would be the same as long as the end-user only used >>> the web app to change their password. >>> >>> >>> http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html >>> >>> So my goal is to have one password for Directory Services (IPA) and >>> Google Apps services if possible. >>> >>> I wonder if it would be better to take advantage of the passync utility >> provided by DS to replicate passwords and update them in the external >> source. >> > > passsync is for syncing passwords with Active Directory. > > > Can Google Apps use a local DS instance as a back end? >> This way the IPA can be set up to update passwords in this instance via >> passync using of the shelf utilities provided by DS. >> > > If they could use DS as a local backend then could just authenticate > directly against the IPA LDAP server. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From samh.work at gmail.com Fri Mar 19 22:01:15 2010 From: samh.work at gmail.com (Sam Hartsfield) Date: Fri, 19 Mar 2010 18:01:15 -0400 Subject: [Freeipa-users] Installing on Centos In-Reply-To: <2AA5506325476F4295EDDB5D15B08A560E5C2B@HAMMBX01.uk.betfair.local> References: <2AA5506325476F4295EDDB5D15B08A560E59B3@HAMMBX01.uk.betfair.local> <4BA0D228.4050302@redhat.com> <2AA5506325476F4295EDDB5D15B08A560E5C2B@HAMMBX01.uk.betfair.local> Message-ID: On Wed, Mar 17, 2010 at 10:28 AM, Gerrard Geldenhuis wrote: > > Thanks for all the feedback I have made some good headway and can at least start running the build, however I currently get this error: > > make[4]: Entering directory `/usr/src/redhat/BUILD/freeipa-1.2.2/ipa-server/ipa-gui' > tg-admin i18n compile > Traceback (most recent call last): > ?File "/usr/bin/tg-admin", line 5, in ? > ? ?from pkg_resources import load_entry_point > ?File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 2479, in ? > ? ?working_set.require(__requires__) > ?File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 585, in require > ? ?needed = self.resolve(parse_requirements(requirements)) > ?File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 483, in resolve > ? ?raise DistributionNotFound(req) ?# XXX put more info here > pkg_resources.DistributionNotFound: Cheetah>=2.0.1 > make[4]: *** [locales/ja/LC_MESSAGES/messages.mo] Error 1 > make[4]: Leaving directory `/usr/src/redhat/BUILD/freeipa-1.2.2/ipa-server/ipa-gui' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/usr/src/redhat/BUILD/freeipa-1.2.2/ipa-server/ipa-gui' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/usr/src/redhat/BUILD/freeipa-1.2.2/ipa-server' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/usr/src/redhat/BUILD/freeipa-1.2.2/ipa-server' > make: *** [all] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.70572 (%build) > > I have the following Cheetah related packages installed: > rpm -qa | grep -i cheetah > python-cheetah-2.0.1-1.el5.rf > python-turbocheetah-1.0-4.el5 > > I decided to stick with 389-DS, I don't know enough about the differences in the Centos-DS and 389-DS to make an informed decision about either. Defaults is thus good. I installed 389-DS from epel. > > > Regards Hi, I'm not sure about that particular error; you may still be missing something. I just compiled FreeIPA on a relatively clean install of CentOS 5.4. I didn't try installing/running, but I've run it on RHEL 5. I'm using 389-ds. I've attached my diffs for the specs of slapi-nis and freeipa; these are against the Fedora 11 versions. Before compiling, I needed to install the following packages: 389-ds-base-devel, mozldap-devel, TurboGears, and selinux-policy-devel. Note that to install, you will need to get packages for krb5-server-ldap, python-pyasn1, and python-tgexpandingformwidget. I may be mistaken, but I don't think the binaries are available in any repositories. The SRPMS are available here: http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/RHEIPA/SRPMS/ Let me know if I've left out anything important. -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa.spec.diff Type: application/octet-stream Size: 1941 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: slapi-nis.spec.diff Type: application/octet-stream Size: 515 bytes Desc: not available URL: From wgmeyer at gmail.com Sun Mar 21 19:43:29 2010 From: wgmeyer at gmail.com (Walter Meyer) Date: Sun, 21 Mar 2010 15:43:29 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <4BA3E1FE.9030009@redhat.com> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> <4BA2A4E5.9020603@redhat.com> <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> <20100319140612.08b2315e@willson.li.ssimo.org> <6ba5d9ef1003191318m3bb54f5id6c9aecb5d52cd6f@mail.gmail.com> <4BA3E1FE.9030009@redhat.com> Message-ID: <8486897522347685968@unknownmsgid> Thanks for all of the tips. I am wondering what the best way to modify the ldap (so I can change the password scheme) is. I tried getting the 389-console utility setup to connect but was unsuccesful. Should I just use the command line ldap tools? On Mar 19, 2010, at 4:43 PM, Rob Crittenden wrote: > Walter Meyer wrote: >> I will see if Salted SHA1 is supported and maybe Google hasn't >> documented it yet. If not, the sync is done with the Google Servers >> over SSL. And if only the Directory Manager can read the >> userPassword attribute, would storing the userPassword attribute in >> SHA1 be that insecure? What scenario could the passwords be >> compromised if I went with this setup? Unless the Directory Manager >> account was compromised wouldn't this be secure if all of the data >> was being transmitted over SSL? >> Also all logins to Google Apps are encrypted with SSL. > > Ok, the SSL usage makes me feel better. Using a weaker password > encryption scheme isn't ideal but if you are protecting transmission > of it you are probably ok. The risk is that if somehow the hash did > get exposed it is relatively easier to crack it than a salted hash. > Risk is something you'll need to weigh specific to your environment, > this may be acceptable. It doesn't make my alarm bells go off but > I'm a pretty laid back guy :-) > > In fact, this would be very cool if it worked. You might want to > file an RFE with the nice folks at Google to see if they'll support > salted hashes if they don't now and potentially move to a more > secure environment later. > > As Simo pointed out you'll want to modify the default password > encryption scheme before adding your users so you don't have to > force round after round of password changes on them. > > If you decide to try it out let us know how it works. > > cheers > > rob From rcritten at redhat.com Mon Mar 22 13:55:00 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 22 Mar 2010 09:55:00 -0400 Subject: [Freeipa-users] Password Attribute Syncing Support In-Reply-To: <8486897522347685968@unknownmsgid> References: <6ba5d9ef1003181458y4c02aec6k194dbf5723ddec28@mail.gmail.com> <4BA2A4E5.9020603@redhat.com> <6ba5d9ef1003181647u78707b8dn16621316f1fe8b77@mail.gmail.com> <20100319140612.08b2315e@willson.li.ssimo.org> <6ba5d9ef1003191318m3bb54f5id6c9aecb5d52cd6f@mail.gmail.com> <4BA3E1FE.9030009@redhat.com> <8486897522347685968@unknownmsgid> Message-ID: <4BA776B4.5030309@redhat.com> Walter Meyer wrote: > Thanks for all of the tips. I am wondering what the best way to modify > the ldap (so I can change the password scheme) is. I tried getting the > 389-console utility setup to connect but was unsuccesful. Should I > just use the command line ldap tools? We don't configure things so the console will work. You'll need to use the LDAP command-line tools. Something like: % ldapmodify -x -D "cn=directory manager" -W dn: cn=config changetype: modify add: passwordStorageScheme passwordStorageScheme: I'm assuming that you don't already have a scheme specified, the default. rob > > On Mar 19, 2010, at 4:43 PM, Rob Crittenden wrote: > >> Walter Meyer wrote: >>> I will see if Salted SHA1 is supported and maybe Google hasn't >>> documented it yet. If not, the sync is done with the Google Servers >>> over SSL. And if only the Directory Manager can read the >>> userPassword attribute, would storing the userPassword attribute in >>> SHA1 be that insecure? What scenario could the passwords be >>> compromised if I went with this setup? Unless the Directory Manager >>> account was compromised wouldn't this be secure if all of the data >>> was being transmitted over SSL? >>> Also all logins to Google Apps are encrypted with SSL. >> Ok, the SSL usage makes me feel better. Using a weaker password >> encryption scheme isn't ideal but if you are protecting transmission >> of it you are probably ok. The risk is that if somehow the hash did >> get exposed it is relatively easier to crack it than a salted hash. >> Risk is something you'll need to weigh specific to your environment, >> this may be acceptable. It doesn't make my alarm bells go off but >> I'm a pretty laid back guy :-) >> >> In fact, this would be very cool if it worked. You might want to >> file an RFE with the nice folks at Google to see if they'll support >> salted hashes if they don't now and potentially move to a more >> secure environment later. >> >> As Simo pointed out you'll want to modify the default password >> encryption scheme before adding your users so you don't have to >> force round after round of password changes on them. >> >> If you decide to try it out let us know how it works. >> >> cheers >> >> rob From harsha at gluster.com Mon Mar 22 14:36:31 2010 From: harsha at gluster.com (Harshavardhana) Date: Mon, 22 Mar 2010 20:06:31 +0530 Subject: [Freeipa-users] FreeIPA - Replicate Setup fails with SSL Error Message-ID: <4BA7806F.4090700@gluster.com> Hi Everyone, I have been recently configuring "Freeipa" server and client which i have achieved successfully. But i have hit a roadblock when i tried to "replicate" ipa server configuration from one already working node to another node. This is on "Fedora 11". I have followed exactly the same instructions written in "Replicate" documentation. But creating "ipa-replica-prepare" and then on the replica server with "ipa-replica-install". I have debug logs from the "replica-install" . It fails right at the time of "SSL" and complains about failing to connect with LDAP server on that node. Snippet from the debug logs --- 2010-03-22 13:23:11,660 DEBUG done configuring dirsrv. 2010-03-22 13:23:11,695 DEBUG Connection error: {'info': 'error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', 'desc': "Can't contact LDAP server"} 2010-03-22 13:23:11,697 DEBUG Unable to connect to LDAP server testserver.gluster.priv. File "/usr/sbin/ipa-replica-install", line 294, in main() File "/usr/sbin/ipa-replica-install", line 254, in main raise RuntimeError("Unable to connect to LDAP server %s." % config.host_name) ---- Can someone explain how can i fix this issue and the way forward in getting this working?. Thanks -- Harshavardhana http://www.gluster.com From rcritten at redhat.com Mon Mar 22 17:36:39 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 22 Mar 2010 13:36:39 -0400 Subject: [Freeipa-users] FreeIPA - Replicate Setup fails with SSL Error In-Reply-To: <4BA7806F.4090700@gluster.com> References: <4BA7806F.4090700@gluster.com> Message-ID: <4BA7AAA7.1040408@redhat.com> Harshavardhana wrote: > Hi Everyone, > > I have been recently configuring "Freeipa" server and client which > i have achieved successfully. > > But i have hit a roadblock when i tried to "replicate" ipa server > configuration from one already working node to another node. This is on > "Fedora 11". > > I have followed exactly the same instructions written in "Replicate" > documentation. > > But creating "ipa-replica-prepare" and then on the replica server with > "ipa-replica-install". > > I have debug logs from the "replica-install" . It fails right at the > time of "SSL" and complains about failing to connect with LDAP server on > that node. > > Snippet from the debug logs > --- > 2010-03-22 13:23:11,660 DEBUG done configuring dirsrv. > 2010-03-22 13:23:11,695 DEBUG Connection error: {'info': > 'error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify failed', 'desc': "Can't contact LDAP server"} > 2010-03-22 13:23:11,697 DEBUG Unable to connect to LDAP server > testserver.gluster.priv. > File "/usr/sbin/ipa-replica-install", line 294, in > main() > > File "/usr/sbin/ipa-replica-install", line 254, in main > raise RuntimeError("Unable to connect to LDAP server %s." % > config.host_name) > ---- > > Can someone explain how can i fix this issue and the way forward in > getting this working?. > > Thanks Can you give us some more information on your set up? Are you using the built-in IPA CA for your SSL certificates or did you replace them at some point? Can you confirm that ports 636 and 389 are open in the firewall on each of your IPA servers? rob From harsha at gluster.com Tue Mar 23 11:23:37 2010 From: harsha at gluster.com (Harshavardhana) Date: Tue, 23 Mar 2010 16:53:37 +0530 Subject: [Freeipa-users] FreeIPA - Replicate Setup fails with SSL Error In-Reply-To: <4BA7AAA7.1040408@redhat.com> References: <4BA7806F.4090700@gluster.com> <4BA7AAA7.1040408@redhat.com> Message-ID: <4BA8A4B9.9080002@gluster.com> >> Can someone explain how can i fix this issue and the way forward in >> getting this working?. >> >> Thanks > > Can you give us some more information on your set up? Are you using > the built-in IPA CA for your SSL certificates or did you replace them > at some point? > > Can you confirm that ports 636 and 389 are open in the firewall on > each of your IPA servers? > > rob My bad it was indeed "iptables". Fixed them and replication is working properly. Now i have another question regarding "referrals" does FreeIPA allow to add "referrals" for a configured for an already configured master. I saw the "replication" itself internally does "referral" but adding "nsslapd-referrals" URL in ldif file. But i just want to understand is that really so how it works?. Thanks -- Harshavardhana http://www.gluster.com From presbrey at gmail.com Thu Mar 25 20:58:26 2010 From: presbrey at gmail.com (Joe Presbrey) Date: Thu, 25 Mar 2010 16:58:26 -0400 Subject: [Freeipa-users] MultiHomed Server SSH login issue In-Reply-To: <4B82E85F.4080206@adurotec.com> References: <4B808CF5.2060303@adurotec.com> <20100222175614.GC16206@redhat.com> <4B82E85F.4080206@adurotec.com> Message-ID: <173a8c251003251358u22d72a95p6b08e033ac0b4cde@mail.gmail.com> Sorry for the late reply, David. You should apply this patch to OpenSSH: http://scripts.mit.edu/trac/browser/trunk/server/common/patches/openssh-5.0p1-multihomed.patch?format=txt I use it at MIT with Kerberos there and elsewhere in an IPA environment with: ipa-server-1.2.1-4.fc11.x86_64 openssh-5.2p1-2.fc11.x86_64 Load a principal for each of your reverse resolving IP hosts into /etc/krb5.keytab using ktutil and everything will "just work". -- Joe Presbrey On Mon, Feb 22, 2010 at 3:26 PM, David Christensen wrote: > Nalin, > > Thank you for the information it does help. ?You have confirmed what > today's research has yielded; the need to modify sshd's behavior and > have it accept authentication for any name that has a key present in the > keytab. > > I am running CentOS 5.4 and apparently the version of ssh that is > installed, 4.3p2 does not support "GSSAPIStrictAcceptorCheck". > > I need to do some additional digging. > > Thanks again. > > David > > On 02/22/2010 11:56 AM, Nalin Dahyabhai wrote: >> On Sat, Feb 20, 2010 at 07:31:33PM -0600, David Christensen wrote: >>> I have my ipa 1.2.2 setup in an environment where my servers have two >>> NICs each in a different VLAN. >>> >>> With the multi NIC setup I have two different DNS names for a single >>> host to control which interface is is used when accessing the host e.g. >>> host.example.com and host.priv.example.com. ?The hostname of the server >>> is set to host.example.com. >>> >>> I first configured the ipa-client on the host with the host.example.com >>> service principle and all is well; I can login via ssh and >>> authentication occurs via kerberos. ?I then setup another service >>> principle with the host.priv.example.com and downloaded the keytab to >>> the target server. ?However when I try to login via ssh I am prompted >>> for a password. >>> >>> Turning on verbose output for ssh and upping the syslog to debug, I came >>> across this: Error code krb5 144 which I discovered means "wrong >>> principal in request." >>> >>> Is what I am trying to do, having more then one host/ssh service >>> principle for a single host that is multihomed? >>> >>> If so what is causing the error code 144 when I can see that in my local >>> klist the ticket for the host.priv.example.com is present? >> >> In order for authentication to succeed, the client and server need to >> agree on what the server's principal name is. ?Based on your tests, it >> looks as though the client is happy to think the server's name is >> "host/host.priv.example.com", but the server continues to assume it's >> name is more or less host@`hostname`, which in this case works out to >> "host/host.example.com". >> >> At the API level, if an application avoids specifying its service name >> when accepting authentication, it'll able to accept authentication to >> any name for which it has a key in its keytab, which is what I think you >> want to have happen here. ?The big caveat is that each application (if >> it even supports this) has to be configured differently. >> >> In the case of sshd, I'd suggest setting >> ? GSSAPIStrictAcceptorCheck no >> in /etc/ssh/sshd_config and seeing if that makes things work. >> >> HTH, >> >> Nalin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users >