[389-users] AD --- LDAP Sync Strange Issue
Hi I have successfully create an AD -- LDAP oneway agreement which was synching data all right. After I run the following experiment: * Remove ALL the entries for the Domain (dn: dc=test,dc=com) in LDAP * Re-build the agreement * Re-initiate the Connection (Initiate full re-sync) And now the Domain (dn: dc=test,dc=com) is still empty, it is not re-creating the Users/Groups (cn/ou) Any idea what this might be happening? I was expecting (maybe wrongly) after re-creating the Agreement it would do anything from scratch, but does not seem to be the case. Anything at all I might be missing? Thanks! -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Passsync not changing passwords
Yes, logging is set to 1. No errors at all, as if passsync is not detecting a password change. I am going to reboot the server after production hours again to see if that resolves it. Dan Franciscus Systems Administrator Information Technology Group Institute for Advanced Study 609-734-8138 - Original Message - From: Noriko Hosoi nho...@redhat.com To: 389-users@lists.fedoraproject.org Sent: Wednesday, February 18, 2015 2:01:41 PM Subject: Re: [389-users] Passsync not changing passwords On 02/18/2015 05:17 AM, Daniel Franciscus wrote: Hello, We have two Windows server 2003 domain controllers and I installed passsync on both servers in order to sync password changes to our 389 LDAP. On one domain controller, it appears passsync is working correctly as I can see in the passsync.log when I change a password through that domain controller. On the other domain controller, when I change a password I do not see any activity in the passsync.log at all. I have passsync on both domain controllers set to verbose logging. I also restarted both domain controllers after installing passsync. On the domain controller that is not syncing passwords the log appears as: 02/18/15 07:52:59: PassSync service initialized 02/18/15 07:52:59: PassSync service running 02/18/15 07:52:59: No entries yet 02/18/15 07:52:59: Password list is empty. Waiting for passhook event Does anyone have an idea of what the issue could be? What is the version of PassSync? The latest is 1.1.6. http://www.port389.org/docs/389ds/releases/release-passsync-1-1-6.html Did yo have a chance to enable passhook log? In the regedit, go to: HKEY_LOCAK_MACHINE -- SOFTWARE\PasswordSync then, set 1 to Log Level. If you add or modify a password on the Windows Server 2003 domain cotroller, what do you get? Any errors? blockquote Dan Franciscus Systems Administrator Information Technology Group Institute for Advanced Study 609-734-8138 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users /blockquote -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Passsync not changing passwords
On 02/18/2015 05:17 AM, Daniel Franciscus wrote: Hello, We have two Windows server 2003 domain controllers and I installed passsync on both servers in order to sync password changes to our 389 LDAP. On one domain controller, it appears passsync is working correctly as I can see in the passsync.log when I change a password through that domain controller. On the other domain controller, when I change a password I do not see any activity in the passsync.log at all. I have passsync on both domain controllers set to verbose logging. I also restarted both domain controllers after installing passsync. On the domain controller that is not syncing passwords the log appears as: 02/18/15 07:52:59: PassSync service initialized 02/18/15 07:52:59: PassSync service running 02/18/15 07:52:59: No entries yet 02/18/15 07:52:59: Password list is empty. Waiting for passhook event Does anyone have an idea of what the issue could be? What is the version of PassSync? The latest is 1.1.6. http://www.port389.org/docs/389ds/releases/release-passsync-1-1-6.html Did yo have a chance to enable passhook log? In the regedit, go to: HKEY_LOCAK_MACHINE -- SOFTWARE\PasswordSync then, set 1 to Log Level. If you add or modify a password on the Windows Server 2003 domain cotroller, what do you get? Any errors? Dan Franciscus Systems Administrator Information Technology Group Institute for Advanced Study 609-734-8138 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Passsync not changing passwords
On 02/18/2015 11:45 AM, Daniel Franciscus wrote: Yes, logging is set to 1. No errors at all, as if passsync is not detecting a password change. Sorry, I was not precise about the passhook log. cd C:\windows\system32 ls passhook* You should be able to see 3 files: passhook.dat, passhook.dll, and passhook.log. Do you see any logs in the passhook.log file? For instance, my test shows these messages on successful sync. Do you see them? 02/18/15 14:16:34 user AD_sync_user6 password changed 02/18/15 14:16:34 0 entries loaded from file 02/18/15 14:16:34 1 entries saved to file If empty even if you update any password on AD, you may need to reboot the Windows machine... I am going to reboot the server after production hours again to see if that resolves it. Dan Franciscus Systems Administrator Information Technology Group Institute for Advanced Study 609-734-8138 *From: *Noriko Hosoi nho...@redhat.com *To: *389-users@lists.fedoraproject.org *Sent: *Wednesday, February 18, 2015 2:01:41 PM *Subject: *Re: [389-users] Passsync not changing passwords On 02/18/2015 05:17 AM, Daniel Franciscus wrote: Hello, We have two Windows server 2003 domain controllers and I installed passsync on both servers in order to sync password changes to our 389 LDAP. On one domain controller, it appears passsync is working correctly as I can see in the passsync.log when I change a password through that domain controller. On the other domain controller, when I change a password I do not see any activity in the passsync.log at all. I have passsync on both domain controllers set to verbose logging. I also restarted both domain controllers after installing passsync. On the domain controller that is not syncing passwords the log appears as: 02/18/15 07:52:59: PassSync service initialized 02/18/15 07:52:59: PassSync service running 02/18/15 07:52:59: No entries yet 02/18/15 07:52:59: Password list is empty. Waiting for passhook event Does anyone have an idea of what the issue could be? What is the version of PassSync? The latest is 1.1.6. http://www.port389.org/docs/389ds/releases/release-passsync-1-1-6.html Did yo have a chance to enable passhook log? In the regedit, go to: HKEY_LOCAK_MACHINE -- SOFTWARE\PasswordSync then, set 1 to Log Level. If you add or modify a password on the Windows Server 2003 domain cotroller, what do you get? Any errors? Dan Franciscus Systems Administrator Information Technology Group Institute for Advanced Study 609-734-8138 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] CORE creation is not working
So a few weeks back we installed the CORE RPM and we were able to get a test core file on our Dev environment, but dev is 1.2.11.15-32, and in prod we are unable to get the core to generate with version 1.2.11.15-48. We have had two failure where the dirsrv hangs and becomes unresponsive and need to get a CORE to see what is causing the issues. When we installed the CORE RPM here are the additional setting we put in place: sysctl -w fs.suid_dumpable=1 and ulimit -u unlimited Can anyone suggest a reason for the CORE file not getting generated or why we can do a test core in Dev and not in prod? Also any know issues with the dirsrv service stopping or hanging with the -48 version? Phillip Jordan Lead Engineer, Web Hosting 555 W. Adams Chicago, IL 60661 This email including, without limitation, the attachments, if any, accompanying this email, may contain information which is confidential or privileged and exempt from disclosure under applicable law. The information is for the use of the intended recipient. If you are not the intended recipient, be aware that any disclosure, copying, distribution, review or use of the contents of this email, and/or its attachments, is without authorization and is prohibited. If you have received this email in error, please notify us by reply email immediately and destroy all copies of this email and its attachments. PGP.sig Description: PGP signature -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] CORE creation is not working
On 02/18/2015 09:12 AM, Jordan, Phillip wrote: So a few weeks back we installed the CORE RPM and we were able to get a test core file on our Dev environment, but dev is 1.2.11.15-32, and in prod we are unable to get the core to generate with version 1.2.11.15-48. That's a good thing, right? That is, perhaps the crash has been fixed in -48? We have had two failure where the dirsrv hangs and becomes unresponsive and need to get a CORE to see what is causing the issues. AFAIK, there is nothing about debugging crashes (i.e. getting core files), or debugging hangs other than what's here: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes When we installed the CORE RPM here are the additional setting we put in place: sysctl -w fs.suid_dumpable=1 and ulimit -u unlimited Right. See above. Can anyone suggest a reason for the CORE file not getting generated or why we can do a test core in Dev and not in prod? Also any know issues with the dirsrv service stopping or hanging with the -48 version? It's possible that the -48 version has a problem with hanging. See the Debugging Hangs section in the link above and provide stack traces. ** *Phillip Jordan*** Lead Engineer, Web Hosting 555 W. Adams Chicago, IL 60661 This email including, without limitation, the attachments, if any, accompanying this email, may contain information which is confidential or privileged and exempt from disclosure under applicable law. The information is for the use of the intended recipient. If you are not the intended recipient, be aware that any disclosure, copying, distribution, review or use of the contents of this email, and/or its attachments, is without authorization and is prohibited. If you have received this email in error, please notify us by reply email immediately and destroy all copies of this email and its attachments. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] Passsync not changing passwords
Hello, We have two Windows server 2003 domain controllers and I installed passsync on both servers in order to sync password changes to our 389 LDAP. On one domain controller, it appears passsync is working correctly as I can see in the passsync.log when I change a password through that domain controller. On the other domain controller, when I change a password I do not see any activity in the passsync.log at all. I have passsync on both domain controllers set to verbose logging. I also restarted both domain controllers after installing passsync. On the domain controller that is not syncing passwords the log appears as: 02/18/15 07:52:59: PassSync service initialized 02/18/15 07:52:59: PassSync service running 02/18/15 07:52:59: No entries yet 02/18/15 07:52:59: Password list is empty. Waiting for passhook event Does anyone have an idea of what the issue could be? Dan Franciscus Systems Administrator Information Technology Group Institute for Advanced Study 609-734-8138 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Question about accountunlocktime
Not a problem. I looked at my settings, and the only thing that is different on those settings you gave was passwordChange is set to on for me, where yours is off. I also didn't have the audit log enabled, so I just enabled it and I'm going to monitor it for a while and see what happens. But what I can't figure out is why your setup works and mine doesn't. Thanks, Harry -Original Message- From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of German Parente Sent: Tuesday, February 17, 2015 9:36 AM To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] Question about accountunlocktime Hi Harry, sorry for long delay. The feature it working quite well for me. For instance, user0 binding three times with wrong password is locked: [root@rh6 ~]# ldapsearch -p 1389 -h localhost -D cn=user0,ou=people,o=redhat -w wrong -b o=redhat cn=user0 ldap_bind: Invalid credentials (49) [root@rh6 ~]# ldapsearch -p 1389 -h localhost -D cn=user0,ou=people,o=redhat -w wrong -b o=redhat cn=user0 ldap_bind: Invalid credentials (49) [root@rh6 ~]# ldapsearch -p 1389 -h localhost -D cn=user0,ou=people,o=redhat -w wrong -b o=redhat cn=user0 ldap_bind: Invalid credentials (49) [root@rh6 ~]# ldapsearch -p 1389 -h localhost -D cn=user0,ou=people,o=redhat -w wrong -b o=redhat cn=user0 ldap_bind: Constraint violation (19) additional info: Exceed password retry limit. Please try later. I can see in audit logs after the third wrong bind: time: 20150217151208 dn: cn=user0,ou=people,o=redhat changetype: modify replace: passwordRetryCount passwordRetryCount: 3 - replace: accountUnlockTime accountUnlockTime: 20150217141508Z If I try to bind with right credentials: ldapsearch -p 1389 -h localhost -D cn=user0,ou=people,o=redhat -w user0 -b o=redhat cn=user0 ldap_bind: Constraint violation (19) additional info: Exceed password retry limit. Please try later. NOTE: in my case, passwordLockoutDuration: 180 So, more than three minutes later: ldapsearch -xLLL -p 1389 -h localhost -D cn=user0,ou=people,o=redhat -w user0 -b o=redhat cn=user0 [root@rh6 ~]# user0 arrives to bind ok. We can see in audit logs that the password retry count has been reset'd (we check accounts locked only if the retry count is greater than the max failures allowed). time: 20150217151719 dn: cn=user0,ou=people,o=redhat changetype: modify replace: passwordRetryCount passwordRetryCount: 0 - My settings: nsslapd-pwpolicy-local: on passwordChange: off passwordLockout: on passwordUnlock: on passwordLockoutDuration: 180 passwordResetFailureCount: 660 and passwordmaxfailure: 3 Thanks and regards, German. - Original Message - From: harry devine harry.dev...@faa.gov To: 389-users@lists.fedoraproject.org Sent: Friday, 13 February, 2015 7:27:10 PM Subject: Re: [389-users] Question about accountunlocktime passwordunlock is set to On, and passwordunlockduration is set to 1800. Thanks, Harry -Original Message- From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of German Parente Sent: Friday, February 13, 2015 11:51 AM To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] Question about accountunlocktime Hi Harry, could you check the value of attribute type passwordUnlock under cn=config ? thanks and regards, German. - Original Message - From: harry devine harry.dev...@faa.gov To: 389-users@lists.fedoraproject.org Sent: Friday, February 13, 2015 1:31:04 PM Subject: Re: [389-users] Question about accountunlocktime OK, I get that. What I don't get is why it won't automatically UNLOCK after lockout duration. The accountunlocktime stays set forever, and as long as that's set, the user can't log in and one of the admins has to clear the accountunlock time attribute manually. Thanks, Harry -Original Message- From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of William Sent: Thursday, February 12, 2015 9:54 PM To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] Question about accountunlocktime On Fri, 2015-02-13 at 01:49 +, harry.dev...@faa.gov wrote: Any insight on this The value is utc. My current time is 13:16 UTC+10:30. When I lock the account I get: accountUnlockTime: 20150213031647Z Split up is 2015-02-13 0316.47 UTC Which is 1316 - 1030 = 0246 Add to this that my passwordLockoutDuration is 1800 aka 30 minutes: 0246 + 0030 = 0316. Thus: 2015-02-13 0316.47 UTC This is why you may see the accountUnlockTime in the past. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Question about accountunlocktime
- Original Message - From: harry devine harry.dev...@faa.gov To: 389-users@lists.fedoraproject.org Sent: Wednesday, 18 February, 2015 2:35:37 PM Subject: Re: [389-users] Question about accountunlocktime Not a problem. I looked at my settings, and the only thing that is different on those settings you gave was passwordChange is set to on for me, where yours is off. I also didn't have the audit log enabled, so I just enabled it and I'm going to monitor it for a while and see what happens. But what I can't figure out is why your setup works and mine doesn't. hi Harry, passwordChange is not related to account lock but to the ability to change passwords by user itself. However, I have also tested with passwordChange: on and it's also working for me. Could you please send the exact message you see to realize account is still locked ? Thanks and regards, German. Thanks, Harry -Original Message- From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of German Parente Sent: Tuesday, February 17, 2015 9:36 AM To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] Question about accountunlocktime Hi Harry, sorry for long delay. The feature it working quite well for me. For instance, user0 binding three times with wrong password is locked: [root@rh6 ~]# ldapsearch -p 1389 -h localhost -D cn=user0,ou=people,o=redhat -w wrong -b o=redhat cn=user0 ldap_bind: Invalid credentials (49) [root@rh6 ~]# ldapsearch -p 1389 -h localhost -D cn=user0,ou=people,o=redhat -w wrong -b o=redhat cn=user0 ldap_bind: Invalid credentials (49) [root@rh6 ~]# ldapsearch -p 1389 -h localhost -D cn=user0,ou=people,o=redhat -w wrong -b o=redhat cn=user0 ldap_bind: Invalid credentials (49) [root@rh6 ~]# ldapsearch -p 1389 -h localhost -D cn=user0,ou=people,o=redhat -w wrong -b o=redhat cn=user0 ldap_bind: Constraint violation (19) additional info: Exceed password retry limit. Please try later. I can see in audit logs after the third wrong bind: time: 20150217151208 dn: cn=user0,ou=people,o=redhat changetype: modify replace: passwordRetryCount passwordRetryCount: 3 - replace: accountUnlockTime accountUnlockTime: 20150217141508Z If I try to bind with right credentials: ldapsearch -p 1389 -h localhost -D cn=user0,ou=people,o=redhat -w user0 -b o=redhat cn=user0 ldap_bind: Constraint violation (19) additional info: Exceed password retry limit. Please try later. NOTE: in my case, passwordLockoutDuration: 180 So, more than three minutes later: ldapsearch -xLLL -p 1389 -h localhost -D cn=user0,ou=people,o=redhat -w user0 -b o=redhat cn=user0 [root@rh6 ~]# user0 arrives to bind ok. We can see in audit logs that the password retry count has been reset'd (we check accounts locked only if the retry count is greater than the max failures allowed). time: 20150217151719 dn: cn=user0,ou=people,o=redhat changetype: modify replace: passwordRetryCount passwordRetryCount: 0 - My settings: nsslapd-pwpolicy-local: on passwordChange: off passwordLockout: on passwordUnlock: on passwordLockoutDuration: 180 passwordResetFailureCount: 660 and passwordmaxfailure: 3 Thanks and regards, German. - Original Message - From: harry devine harry.dev...@faa.gov To: 389-users@lists.fedoraproject.org Sent: Friday, 13 February, 2015 7:27:10 PM Subject: Re: [389-users] Question about accountunlocktime passwordunlock is set to On, and passwordunlockduration is set to 1800. Thanks, Harry -Original Message- From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of German Parente Sent: Friday, February 13, 2015 11:51 AM To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] Question about accountunlocktime Hi Harry, could you check the value of attribute type passwordUnlock under cn=config ? thanks and regards, German. - Original Message - From: harry devine harry.dev...@faa.gov To: 389-users@lists.fedoraproject.org Sent: Friday, February 13, 2015 1:31:04 PM Subject: Re: [389-users] Question about accountunlocktime OK, I get that. What I don't get is why it won't automatically UNLOCK after lockout duration. The accountunlocktime stays set forever, and as long as that's set, the user can't log in and one of the admins has to clear the accountunlock time attribute manually. Thanks, Harry -Original Message- From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of William Sent: Thursday, February 12, 2015 9:54 PM To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] Question about
Re: [389-users] admin-console issues
On 02/18/2015 07:43 AM, Fernando Fuentes wrote: Team, Due to a small requirement by ovirt I had to change my nsslapd-minssf from 0 to 1. All of my systems continue to work as they use ssl. But the admin-console is now unable to log in. Can you configure the admin-console to use ssl? I keep getting a unauthorized access when I try to login. If I put it back to 0 it works just fine. I am sure I am missing a setting somewhere on the admin-console settings to make this work. Thank you for the help. Regards, -- Fernando Fuentes Technical Lead Systems Administrator Email:ffuen...@aasteel.com American Alloy Steel, Inc. Houston, Texas Website:http://www.aasteel.com Phone: 713-462-8081 Fax: 713-462-0527 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] admin-console issues
I have tried with no success. Though I am sure I am doing it wrong. I was trying to look for a document on this but could not find one. Is there how to on this? Thanks for the help. Regards, On 02/18/2015 08:45 AM, Rich Megginson wrote: On 02/18/2015 07:43 AM, Fernando Fuentes wrote: Team, Due to a small requirement by ovirt I had to change my nsslapd-minssf from 0 to 1. All of my systems continue to work as they use ssl. But the admin-console is now unable to log in. Can you configure the admin-console to use ssl? I keep getting a unauthorized access when I try to login. If I put it back to 0 it works just fine. I am sure I am missing a setting somewhere on the admin-console settings to make this work. Thank you for the help. Regards, -- Fernando Fuentes Technical Lead Systems Administrator Email:ffuen...@aasteel.com American Alloy Steel, Inc. Houston, Texas Website:http://www.aasteel.com Phone: 713-462-8081 Fax: 713-462-0527 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- Fernando Fuentes Technical Lead Systems Administrator Email: ffuen...@aasteel.com American Alloy Steel, Inc. Houston, Texas Website: http://www.aasteel.com Phone: 713-462-8081 Fax: 713-462-0527 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] admin-console issues
Awesome! I will try this today. Thanks again! Regards, On 02/18/2015 08:57 AM, Rich Megginson wrote: On 02/18/2015 07:53 AM, Fernando Fuentes wrote: I have tried with no success. Though I am sure I am doing it wrong. I was trying to look for a document on this but could not find one. Is there how to on this? https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_SSL.html Thanks for the help. Regards, On 02/18/2015 08:45 AM, Rich Megginson wrote: On 02/18/2015 07:43 AM, Fernando Fuentes wrote: Team, Due to a small requirement by ovirt I had to change my nsslapd-minssf from 0 to 1. All of my systems continue to work as they use ssl. But the admin-console is now unable to log in. Can you configure the admin-console to use ssl? I keep getting a unauthorized access when I try to login. If I put it back to 0 it works just fine. I am sure I am missing a setting somewhere on the admin-console settings to make this work. Thank you for the help. Regards, -- Fernando Fuentes Technical Lead Systems Administrator Email:ffuen...@aasteel.com American Alloy Steel, Inc. Houston, Texas Website:http://www.aasteel.com Phone: 713-462-8081 Fax: 713-462-0527 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- Fernando Fuentes Technical Lead Systems Administrator Email:ffuen...@aasteel.com American Alloy Steel, Inc. Houston, Texas Website:http://www.aasteel.com Phone: 713-462-8081 Fax: 713-462-0527 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- Fernando Fuentes Technical Lead Systems Administrator Email: ffuen...@aasteel.com American Alloy Steel, Inc. Houston, Texas Website: http://www.aasteel.com Phone: 713-462-8081 Fax: 713-462-0527 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] admin-console issues
On 02/18/2015 07:53 AM, Fernando Fuentes wrote: I have tried with no success. Though I am sure I am doing it wrong. I was trying to look for a document on this but could not find one. Is there how to on this? https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_SSL.html Thanks for the help. Regards, On 02/18/2015 08:45 AM, Rich Megginson wrote: On 02/18/2015 07:43 AM, Fernando Fuentes wrote: Team, Due to a small requirement by ovirt I had to change my nsslapd-minssf from 0 to 1. All of my systems continue to work as they use ssl. But the admin-console is now unable to log in. Can you configure the admin-console to use ssl? I keep getting a unauthorized access when I try to login. If I put it back to 0 it works just fine. I am sure I am missing a setting somewhere on the admin-console settings to make this work. Thank you for the help. Regards, -- Fernando Fuentes Technical Lead Systems Administrator Email:ffuen...@aasteel.com American Alloy Steel, Inc. Houston, Texas Website:http://www.aasteel.com Phone: 713-462-8081 Fax: 713-462-0527 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- Fernando Fuentes Technical Lead Systems Administrator Email:ffuen...@aasteel.com American Alloy Steel, Inc. Houston, Texas Website:http://www.aasteel.com Phone: 713-462-8081 Fax: 713-462-0527 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] CORE creation is not working
The hang is on the .48 version and hence our issue of not being able to get a CORE file. From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of Rich Megginson Sent: Wednesday, February 18, 2015 10:25 AM To: 389-users@lists.fedoraproject.org Subject: Re: [389-users] CORE creation is not working On 02/18/2015 09:12 AM, Jordan, Phillip wrote: So a few weeks back we installed the CORE RPM and we were able to get a test core file on our Dev environment, but dev is 1.2.11.15-32, and in prod we are unable to get the core to generate with version 1.2.11.15-48. That's a good thing, right? That is, perhaps the crash has been fixed in -48? We have had two failure where the dirsrv hangs and becomes unresponsive and need to get a CORE to see what is causing the issues. AFAIK, there is nothing about debugging crashes (i.e. getting core files), or debugging hangs other than what's here: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes When we installed the CORE RPM here are the additional setting we put in place: sysctl -w fs.suid_dumpable=1 and ulimit -u unlimited Right. See above. Can anyone suggest a reason for the CORE file not getting generated or why we can do a test core in Dev and not in prod? Also any know issues with the dirsrv service stopping or hanging with the -48 version? It's possible that the -48 version has a problem with hanging. See the Debugging Hangs section in the link above and provide stack traces. Phillip Jordan Lead Engineer, Web Hosting 555 W. Adams Chicago, IL 60661 This email including, without limitation, the attachments, if any, accompanying this email, may contain information which is confidential or privileged and exempt from disclosure under applicable law. The information is for the use of the intended recipient. If you are not the intended recipient, be aware that any disclosure, copying, distribution, review or use of the contents of this email, and/or its attachments, is without authorization and is prohibited. If you have received this email in error, please notify us by reply email immediately and destroy all copies of this email and its attachments. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users PGP.sig Description: PGP signature -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] CORE creation is not working
On 02/18/2015 09:44 AM, Jordan, Phillip wrote: The hang is on the .48 version and hence our issue of not being able to get a CORE file. You don't need a core file in order to get a stack trace from a hang - see http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs *From:*389-users-boun...@lists.fedoraproject.org [mailto:389-users-boun...@lists.fedoraproject.org] *On Behalf Of *Rich Megginson *Sent:* Wednesday, February 18, 2015 10:25 AM *To:* 389-users@lists.fedoraproject.org *Subject:* Re: [389-users] CORE creation is not working On 02/18/2015 09:12 AM, Jordan, Phillip wrote: So a few weeks back we installed the CORE RPM and we were able to get a test core file on our Dev environment, but dev is 1.2.11.15-32, and in prod we are unable to get the core to generate with version 1.2.11.15-48. That's a good thing, right? That is, perhaps the crash has been fixed in -48? We have had two failure where the dirsrv hangs and becomes unresponsive and need to get a CORE to see what is causing the issues. AFAIK, there is nothing about debugging crashes (i.e. getting core files), or debugging hangs other than what's here: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes When we installed the CORE RPM here are the additional setting we put in place: sysctl -w fs.suid_dumpable=1 and ulimit -u unlimited Right. See above. Can anyone suggest a reason for the CORE file not getting generated or why we can do a test core in Dev and not in prod? Also any know issues with the dirsrv service stopping or hanging with the -48 version? It's possible that the -48 version has a problem with hanging. See the Debugging Hangs section in the link above and provide stack traces. ** *Phillip Jordan* Lead Engineer, Web Hosting 555 W. Adams Chicago, IL 60661 This email including, without limitation, the attachments, if any, accompanying this email, may contain information which is confidential or privileged and exempt from disclosure under applicable law. The information is for the use of the intended recipient. If you are not the intended recipient, be aware that any disclosure, copying, distribution, review or use of the contents of this email, and/or its attachments, is without authorization and is prohibited. If you have received this email in error, please notify us by reply email immediately and destroy all copies of this email and its attachments. -- 389 users mailing list 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Passsync not changing passwords
Ah, I do not see passhook.dat or passhook.log. I tried uninstalling and re-installing but I still do not see those files there. Dan Franciscus Systems Administrator Information Technology Group Institute for Advanced Study 609-734-8138 - Original Message - From: Noriko Hosoi nho...@redhat.com To: 389-users@lists.fedoraproject.org Sent: Wednesday, February 18, 2015 5:24:33 PM Subject: Re: [389-users] Passsync not changing passwords On 02/18/2015 11:45 AM, Daniel Franciscus wrote: Yes, logging is set to 1. No errors at all, as if passsync is not detecting a password change. Sorry, I was not precise about the passhook log. cd C:\windows\system32 ls passhook* You should be able to see 3 files: passhook.dat, passhook.dll, and passhook.log. Do you see any logs in the passhook.log file? For instance, my test shows these messages on successful sync. Do you see them? blockquote 02/18/15 14:16:34 user AD_sync_user6 password changed 02/18/15 14:16:34 0 entries loaded from file 02/18/15 14:16:34 1 entries saved to file /blockquote If empty even if you update any password on AD, you may need to reboot the Windows machine... blockquote I am going to reboot the server after production hours again to see if that resolves it. Dan Franciscus Systems Administrator Information Technology Group Institute for Advanced Study 609-734-8138 - Original Message - From: Noriko Hosoi nho...@redhat.com To: 389-users@lists.fedoraproject.org Sent: Wednesday, February 18, 2015 2:01:41 PM Subject: Re: [389-users] Passsync not changing passwords On 02/18/2015 05:17 AM, Daniel Franciscus wrote: blockquote Hello, We have two Windows server 2003 domain controllers and I installed passsync on both servers in order to sync password changes to our 389 LDAP. On one domain controller, it appears passsync is working correctly as I can see in the passsync.log when I change a password through that domain controller. On the other domain controller, when I change a password I do not see any activity in the passsync.log at all. I have passsync on both domain controllers set to verbose logging. I also restarted both domain controllers after installing passsync. On the domain controller that is not syncing passwords the log appears as: 02/18/15 07:52:59: PassSync service initialized 02/18/15 07:52:59: PassSync service running 02/18/15 07:52:59: No entries yet 02/18/15 07:52:59: Password list is empty. Waiting for passhook event Does anyone have an idea of what the issue could be? /blockquote What is the version of PassSync? The latest is 1.1.6. http://www.port389.org/docs/389ds/releases/release-passsync-1-1-6.html Did yo have a chance to enable passhook log? In the regedit, go to: HKEY_LOCAK_MACHINE -- SOFTWARE\PasswordSync then, set 1 to Log Level. If you add or modify a password on the Windows Server 2003 domain cotroller, what do you get? Any errors? blockquote Dan Franciscus Systems Administrator Information Technology Group Institute for Advanced Study 609-734-8138 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users /blockquote -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users /blockquote -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] acl on logs, 389 strips effective rights mask.
On Fri, 2015-02-13 at 03:31 -0500, German Parente wrote: Hi William, the access mode for the rhds logs is set in these configuration settings under cn=config: nsslapd-auditlog-mode nsslapd-errorlog-mode nsslapd-accesslog-mode I don't know whether we could use a value to just inherit from acl defined. It seems that setting these from 600 to 660 I end up with # file: access # owner: nobody # group: nobody user::rw- user:splunk:r-x #effective:r-- group::rwx #effective:r-- mask::r-- other::--- As opposed to before which was: # file: access # owner: nobody # group: nobody user::rw- user:splunk:r-x #effective:--- group::rwx #effective:--- mask::--- other::--- So it looks like there is some interaction between the mode settings and the acls mask. Any hints where in the source I could dig to find this? -- William will...@firstyear.id.au -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
