Home › Forums › OS X Server and Client Discussion › Open Directory › pwpolicy -setpolicy isDisabled is not getting stored

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • April 17, 2008 at 3:14 pm #372307
    eric_csm
    Participant

    Hi guys,

    I’ve an interesting issue here with an OD environment comprising 1 ODM and 4 ODR.

    Changes applied to the property isEnabled with WM or the CLI using pwpolicy setpolicy are not stored, even-though the action gets properly logged into ApplePasswordServer.Server.log as:

    [code]Apr 17 2008 15:14:30 SETPOLICY: {0x00000000000000000000000000000001, diradmin} set policies: isDisabled=1 isAdminUser=0 newPasswordRequired=0 usingHistory=0 canModifyPasswordforSelf=1 usingExpirationDate=0 usingHardExpirationDate=0 requiresAlpha=0 requiresNumeric=0 expirationDateGMT=4294967295 hardExpireDateGMT=4294967295 maxMinutesOfNonUse=0 maxMinutesUntilChangePassword=0 maxFailedLoginAttempts=0 minChars=0 maxChars=0 for user: {0x4701117b2c6b3e790000012f0000083c, bobk}[/code]

    The account was created in the same OD and has an OD password. The issue is affecting 300+ accounts. New accounts are not affected.

    I had to clean up 4000+ sync.gz junk files that dated back from Jul ’07 in the /var/db/authserv directory this hasn’t improved matters.

    A couple more things I’ve found while digging around.

    Firstly:
    At WM’s inspector, in config>Passwordserver>dsAttrTypeStandard: PasswordServerList I’ve found some worrying entries under the key [code]LastSyncFailedAttempt[/code] which date back from 2007-06-05. Does this mean that the authservermain and the KDC haven’t been syncing since then? Is this related with the policy issue? Has the PWS authservermain DB gone corrupt?

    Secondly:
    I decided to reboot the ODM to see what would came up at the system.log and I did found the following DNS entries:

    [code]Apr 17 12:16:38 csmodm mDNSResponder: Update _kerberos._tcp.CSMODM.MYDOMAIN.COM. refused
    Apr 17 12:16:38 csmodm mDNSResponder: Registration of record _kerberos._tcp.CSMODM.MYDOMAIN.COM. type 33 failed with error -65553
    Apr 17 12:16:38 csmodm mDNSResponder: Update _kerberos._udp.CSMODM.MYDOMAIN.COM. refused
    Apr 17 12:16:38 csmodm mDNSResponder: Registration of record _kerberos._udp.CSMODM.MYDOMAIN.COM. type 33 failed with error -65553
    Apr 17 12:16:40 csmodm /usr/sbin/serialnumberd[238]: serialnumberd: Firewall rule #1 added to allow port 626.
    Apr 17 12:16:44 csmodm /usr/sbin/serveradmin: servermgr_ipfilter:ipfw config:Notice:Disabled firewall
    Apr 17 12:16:46 csmodm mDNSResponder: ERROR: Only name server claiming responsibility for “_kerberos.csmodm.” is “.”!
    Apr 17 12:18:15 csmodm /usr/sbin/PasswordService: client response doesn’t match what we generated[/code]

    Although the machine resolves properly (reverse-forward) when queried from the CLI, is there something that we can check at the DNS server to ensure that is perfectly configured?

    Any clues greatly appreciated!

    Eric

    April 17, 2008 at 4:14 pm #372313
    eric_csm
    Participant

    Hi MacTroll,

    Thanks for your quick reply

    I have 4 ODR’s. All the machines are 10.4.9.

    I’m afraid I’m hands tied when it comes to test out the OD without the replicas.

    I can’t simply stop them since these are providing other services too.
    Getting the SASL port temporarily disabled for the ODR machines at the main firewall, not easy, the network admin is quite busy and won’t be able to do that for me in the near future.
    I don’t know if demoting them to standalone will be a good idea given the current state of the OD.

    What would you suggest to test the OD without the ODR without disrupting other services?

    Regarding the DNS problems… somebody has suggested me that these come by having a Windows DNS server as a nameserver for the zone… this is in fact the case my OSXS 10.4.9 DNS server has a Windows 2003 Server in its nameserver list.

    April 17, 2008 at 5:50 pm #372315
    Eden.Nelson
    Participant

    [i][quote]The account was created in the same OD and has an OD password. The issue is affecting 300+ accounts. New accounts are not affected.[/quote][/i]
    [code]LastSyncFailedAttempt
    2007-08-28T16:09:28Z[/code]
    This seems to be the last time it had a problem syncing, not the last time it synced correctly.

    I would double check the OD records for these accounts vs. a new account that is not effected.
    I would do this through dscl, its to hard to see the whole record in WGM.

    Also try switching one of the users password to crypt, and then back to OD.
    This will generate a new password slot, and do some work toward isolation of the problem.

    April 18, 2008 at 9:00 am #372323
    eric_csm
    Participant

    This morning I created a new account to continue testing, and to check its records against an old account records.

    Alas I decided to retest one of the old accounts by unchecking the “access account” checkbox, refreshing… and now the changes are stored! I closed WM, reopened it, went to the account and yes, the setting isEnabled=1 gets stored properly.

    Although I’m happy that this is working again, I’m now even more worried since I don’t have the slightest clue of why or when the problem decided to disappear.

    Questions arise:

    Was creating a new account the trigger to get the cogs turning again?
    Which entries should I look for in the logs for finding more about what really happened?

    I’ve found that the ODR’s were promoted in June ’07 (I took over the systems in Sept ’07), then should I really worry about the LastSyncFailedAttempt2007-08-28T16:09:28Z or is just a timestamp that reflects the date when the ODR were promoted? This key is found at the WM inspector > Config > passwordserver > passwordserverlist. The ApplePasswordServer.Replication.log shows recent activity:

    Apr 18 2008 09:30:56 SYNC PULL: providing data to 192.168.175.101 after 04/18/2008 09:25:13 AM
    Apr 18 2008 09:30:56 SYNC PULL: updating 307 records
    Apr 18 2008 09:31:09 SYNC PULL: providing data to 192.168.175.103 after 04/18/2008 09:25:50 AM
    Apr 18 2008 09:31:09 SYNC PULL: updating 306 records
    Apr 18 2008 09:31:46 SYNC PULL: providing data to 192.168.175.102 after 04/18/2008 09:25:24 AM
    Apr 18 2008 09:31:46 SYNC PULL: updating 306 records
    Apr 18 2008 09:33:57 SYNC PULL: providing data to 192.168.175.104 after 04/18/2008 09:25:42 AM
    Apr 18 2008 09:33:57 SYNC PULL: updating 308 records

    I am still worried about the /var/db/authserv/ sync files cleanup. As per my understanding there is a process in place that is in charge of cleaning up these files periodically.

  • Author
    Posts
Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.

Comments are closed

Copyright © 2025 AFP548. All Rights Reserved.