locked
Active Directory Integration Pack - OverflowException RRS feed

  • Question

  • Hi,

    I`ve installed the Active Directory Integration Pack on both the Runbook Server and the machine running Runbook Designer.

    I`m having a problem with a very basic operation: Get User

    Here is my runbook set up:

    First step: Initialize data. Configured to request one property; Username (string)

    Second step: Get User. Configuration: My AD configuration. Properties: None. Filters: Sam Account Name Equals Username from "Initialize Data".

    When I test the runbook using the Runbook Tester I get the following error:

    Arithmetic operation resulted in an overflow.

    Exception: OverflowException
    Target site: Integer8ConversionUtility.LargeIntegerToTimeSpan

    Stack trace:
       at Microsoft.Accelerators.ActiveDirectoryCore.Integer8ConversionUtility.LargeIntegerToTimeSpan(IADsLargeInteger value)
       at Microsoft.Accelerators.ActiveDirectoryCore.LdapDirectory.MaxPasswordAgeFromActiveDirectory()
       at Microsoft.Accelerators.ActiveDirectoryCore.LdapDirectory.get_MaxPasswordAge()
       at Microsoft.Accelerators.ActiveDirectoryCore.Internals.SafeDirectoryFactory.CreateSearchResult(ISafeSearchResult underlyingSearchResult)
       at Microsoft.Accelerators.ActiveDirectoryCore.LdapSearcher.FindAll()
       at Microsoft.SystemCenter.IntegrationPack.ActiveDirectory.Helpers.GetExecutorHelper.DoAction(ExecutionProxy proxy, Object executionItem)
       at Microsoft.SystemCenter.IntegrationPack.ActiveDirectory.Execution.GetUserExecutor.DoAction(Object executionItem)
       at Microsoft.SystemCenter.IntegrationPack.ActiveDirectory.Execution.AExecutor.ExecuteGetAction(Object executionObject, ILdapDirectory directory)
       at Microsoft.SystemCenter.IntegrationPack.ActiveDirectory.Execution.AExecutor.Execute()
       at Microsoft.SystemCenter.IntegrationPack.ActiveDirectory.Execution.ActiveDirectoryProgram.ExecuteProxy(ExecutionProxy proxy)
       at Microsoft.SystemCenter.IntegrationPack.ActiveDirectory.AActiveDirectoryActivity.Execute(IActivityRequest request, IActivityResponse response)

    If I include the property ReturnDNOnly and configure it with a value of True, the specified user is retrieved successfully.

    I want to access more properties than the DN, so I`m wondering what the cause of this error might be.

    One additional observation: If I specify a username that I know doesn`t exist, the query is successful. Thus, it seems like the issue arise when a user is found in Active Directory.


    Jan Egil Ring

    Blog: http://blog.powershell.no
    Twitter: http://twitter.com/janegilring

    Monday, April 30, 2012 2:08 PM

Answers

  • I do have a lab environment where I`ve reproduced the error and can experiment with the password policies.

    If I set for example Maximum Password Age to a value of -1728000000000, it`s automatically converted to 2:00:00:00 when I press OK.

    I deleted the PSO Object to see if the operation succeeds with no PSO. However, I get the exact same error message.

    I have a third environment where no PSO have ever been created. There I can successfully perform the exact same runbook without errors. I created a PSO in that environment to see if that broke the runbook, however, it did not.

    I then started to look at the password settings in the default domain policy, and compared the settings in two domains where the runbook was not working with the domain it was working in. I noticed that Maximum password history was set to 0 (which means "Password never expire") in the two "broken" domains. I configured this value to 999 in the lab domain, and that fixed the issue.

    Although we can agree that a Maximum password history of 0 is a bad practice, I do consider this to be a bug.

    Thanks for your assistance Graham.


    Jan Egil Ring

    Blog: http://blog.powershell.no
    Twitter: http://twitter.com/janegilring


    Tuesday, May 1, 2012 11:48 AM

All replies

  • The lines that stand out are:

    - Target site: Integer8ConversionUtility.LargeIntegerToTimeSpan

       at Microsoft.Accelerators.ActiveDirectoryCore.Integer8ConversionUtility.LargeIntegerToTimeSpan(IADsLargeInteger value)
       at Microsoft.Accelerators.ActiveDirectoryCore.LdapDirectory.MaxPasswordAgeFromActiveDirectory()
       at Microsoft.Accelerators.ActiveDirectoryCore.LdapDirectory.get_MaxPasswordAge()

    Are you using FineGrained Passwords? If so, what is the value of Max Password age?

    http://technet.microsoft.com/en-us/library/cc753858(v=ws.10).aspx - "values for the four time-related PSO attributes (msDS-MaximumPasswordAge, msDS-MinimumPasswordAge, msDS-LockoutObservationWindow, and msDS-LockoutDuration) must be entered in the d:hh:mm:ss format (recommended) or the I8 format"

    http://technet.microsoft.com/en-us/library/cc753858(v=ws.10).aspx


    Regards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk
    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

    Monday, April 30, 2012 2:23 PM
  • Yes, one Fine Grained Password Policy is defined in the domain.

    From ADSI Edit, the values is defined as follows:
    msDS-MaximumPasswordAge: 21:00:00:00
    msDS-MinimumPasswordAge: 1:00:00:00
    msDS-LockoutDuration: 0:12:00:00
    msDS-LockoutObservationWindow: 0:00:15:00

    I removed my user account from the group specified in the msDS-PSOAppliesTo property of the policy, which didn`t seem to make any difference.

    The article states that the I8 format must be used when configured the PSO using ldifde, however, this policy is configured using ADSI Edit.

    In order to work around the Orchestrator issue, should the I8 format be used also when using ADSI Edit?


    Jan Egil Ring

    Blog: http://blog.powershell.no
    Twitter: http://twitter.com/janegilring

    Monday, April 30, 2012 3:20 PM
  • Sorry - I posted the same link twice - had meant to post this one:

    http://technet.microsoft.com/en-us/library/cc754461(v=ws.10).aspx

    Your values certainly seem fine - 21 days. I don't know of any reason why it has to be in I8 format but if you can give it a try it might be worth it (depends on whether you can make these sorts of changes).

    As an alternative quick and dirty test - if you filter on Password never expires set to true, does this still error?

    Cheers

    Graham


    Regards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk
    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

    Tuesday, May 1, 2012 8:17 AM
  • I do have a lab environment where I`ve reproduced the error and can experiment with the password policies.

    If I set for example Maximum Password Age to a value of -1728000000000, it`s automatically converted to 2:00:00:00 when I press OK.

    I deleted the PSO Object to see if the operation succeeds with no PSO. However, I get the exact same error message.

    I have a third environment where no PSO have ever been created. There I can successfully perform the exact same runbook without errors. I created a PSO in that environment to see if that broke the runbook, however, it did not.

    I then started to look at the password settings in the default domain policy, and compared the settings in two domains where the runbook was not working with the domain it was working in. I noticed that Maximum password history was set to 0 (which means "Password never expire") in the two "broken" domains. I configured this value to 999 in the lab domain, and that fixed the issue.

    Although we can agree that a Maximum password history of 0 is a bad practice, I do consider this to be a bug.

    Thanks for your assistance Graham.


    Jan Egil Ring

    Blog: http://blog.powershell.no
    Twitter: http://twitter.com/janegilring


    Tuesday, May 1, 2012 11:48 AM
  • Hi Jan, great troubleshooting!

    Did you ever come up with another solution though that allows for a maximum password age/history setting of 0?

    Tuesday, October 30, 2012 3:33 AM
  • Thanks, unfortunately no.

    Jan Egil Ring

    Blog: http://blog.powershell.no
    Twitter: http://twitter.com/janegilring

    Thursday, November 1, 2012 7:14 AM