locked
UAG SP2 DN Syntax Error RRS feed

  • Question

  • Since upgrading to SP2 i've noticed the error logs are filling up with the following (below) when a user logs in.

    Any ideas? There has been no changes except the sp2 patch.

    :::: Error Logs Contain ::::

    Warning 08/14/2012 12:09:16 108

    Unable
    To Retrieve Information from LDAP Server

    Information
    from the LDAP server at IP address xx.xx.xx.xx cannot be retrieved. The error
    code is Invalid DN Syntax.

    Thanks

    Craig







    • Edited by brad210 Tuesday, August 14, 2012 2:49 PM
    Tuesday, August 14, 2012 11:14 AM

Answers

All replies

  • could you verify the BASE DN Syntax on the authentication server settings under "Authentication and Authorization severs" option
    Thursday, August 16, 2012 11:23 PM
  • The base DN is correct, and then i have opted to modify it, simply by adding an OU=xxxx,DC=XXX,DC=XXX (simply to limit UAG's user base.

    Friday, August 17, 2012 8:09 AM
  • I too am seeing this event warning messages after upgrading to UAG Service Pack 2.  There were no changes to the Authentication Repositories other than applying SP2.  There is something amiss here.

    The base DN was set as DC=xxx,DC=xxx with subfolder tree search.  I also tried modifying the Base DN to a lower level OU structure, but still get the same warning messages in the event logs.

    • Edited by Redparadox Wednesday, August 22, 2012 8:09 PM
    Wednesday, August 22, 2012 8:07 PM
  • I also am getting the same error, I had to disable logging on the local server and push all logs to my syslog server that has more room.  Hope we get a solution soon.

    Cory

    Thursday, August 23, 2012 1:50 PM
  • I am getting the same error. The base DN looks OK.

    Any News?

    Monday, September 10, 2012 9:35 AM
  • I currently have a case open with Microsoft PSS regarding this issue.  Will let you know the results.  It is fairly obvious that if you have your authentication rooted at the top of the domain tree you will see these errors.
    Monday, September 10, 2012 11:51 AM
  • Same overhere. Get the error message on all memberservers. Only thing changed is the installation of SP2 of UAG.
    Tuesday, September 11, 2012 7:30 AM
  • This looks like a known issue internally to MS now and we have a fix for it . If someone has an urgent need for it raise a support case with CTS.

    btw Redparadox can you tell me your case id that you have with support ?.


    Faisal :>

    Tuesday, September 11, 2012 9:59 AM
  • The case number is: 112082274722130

    Tuesday, September 11, 2012 11:57 AM
  • thanks yes hotfix should resolve your problem as documented in this case id. Engineer will get in touch with you.


    Faisal :>

    Tuesday, September 11, 2012 12:39 PM
  • Will the hotfix be made public soon?

    Don Adams

    Tuesday, September 11, 2012 6:11 PM
  • The same error. When user logon to the portal, about 100 messages appears in Application log 

    Log Name: Application
    Source: Microsoft Forefront UAG
    Date: 12.09.2012 12:19:23
    Event ID: 108
    Task Category: None
    Level: Warning
    Keywords: Classic
    User: N/A
    Computer: computer_name
    Description:
    Information from the LDAP server at IP address xx.xx.xx.xx cannot be retrieved. The error code is Invalid DN Syntax.
    Wednesday, September 12, 2012 9:52 AM
  • Yeah I also have this problem, hammered SCOM with alerts until I saw it occuring

    also happened after applying SP2

    Wednesday, September 12, 2012 10:22 AM
  • Its private at the moment and will take some time to get this as public fix.

    Please escalate the case to Microsoft support to get the hotfix.


    Faisal :>

    Friday, September 14, 2012 1:13 PM
  • Hi Faisal

    Could you please advise me on how I go about escalating this to get the hotfix?

    Thanks
    Craig

    Monday, October 1, 2012 1:57 PM
  • Has this hotfix been made available yet?

    Thanks....

    Friday, November 2, 2012 1:56 PM
  • THis is a well known issue after SP2 related to group membership, Microsoft is aware of this issue and they released a private fix for it that will solve it. Please raise a case and they will provide the fix

    For more details please check my blog.

    http://itcalls.blogspot.com/2012/10/microsoft-uag-2010-web-monitor-all.html

    Friday, November 9, 2012 9:32 AM
  • THis is a well known issue after SP2 related to group membership, Microsoft is aware of this issue and they released a private fix for it that will solve it. Please raise a case and they will provide the fix

    For more details please check my blog.

    http://itcalls.blogspot.com/2012/10/microsoft-uag-2010-web-monitor-all.html

    Friday, November 9, 2012 9:32 AM
  • I am also suffering from this problem.

    Besides littering the event logs, does this issue cause any service impacting issues? i.e. with AD authentication?

    Or is the hotfix just to remove the event log messages?

    Saturday, November 10, 2012 8:25 AM
  • I am also having the same issue, This is the only form I can find with this issue, What has been done about it? anybody have a fix?

    Thanks

    Tuesday, December 11, 2012 2:50 PM
  • Hi all, having this same problem too. Would this issue affect the ability for users to Authenticate too? We seem to have an odd problem here and wondered if this is related?

    thanks. Phil


    Phil

    Tuesday, December 18, 2012 12:09 PM
  • AFAIK no authN issues due to this error.


    Faisal :>

    Tuesday, December 18, 2012 1:11 PM
  • the Fix would be publically available with UAG SP3. SP3 is expected to be available in Q1 2013.

    http://blogs.technet.com/b/edgeaccessblog/archive/2012/11/26/uag-2010-service-pack-3-is-in-the-works.aspx


    Faisal :>

    Tuesday, December 18, 2012 1:12 PM
  • Okay Faisal, thank you for this clarification. regards. Phil

    Phil

    Tuesday, December 18, 2012 1:59 PM
  • Applied this fix yesterday as we were experiencing this problem after upgrading to sp2, we now are experiencing regular crashes of the default application pool causing major problems with the service. We are currently running v4.0.2095.10003, is this the version that others are now running that have applied the fix or have we been supplied a diffferent version?

    many thanks,
    Peter

     
    Wednesday, December 19, 2012 11:01 AM
  • yes the fix is in private fix stage and not the final built , I believe you must have got this from support through a case. Can you contact the support team again by providing them the case id and ask for the latest built that handles this issue and app pool crashes as well .You need the following built v4.0.2095.10005.

    Should you need any further assistance , please keep working with support directly via the case you have opened. I am sure with v4.0.2095.10005 you will not see any of these issues as we provided this to few other customers.


    Faisal :>

    Wednesday, December 19, 2012 11:18 AM
  • Excellent, thanks for your help, I will get back to support asap.

    Thanks,

    Peter

    Wednesday, December 19, 2012 11:31 AM
  • The private hot fix I was given by MS to fix the issue actually upgraded my UAG to 4.0.2095.10006 so I think both .10003 and .10005 have been superseded now. This was a few weeks ago.

    I was told the same thing - that the messages in the event log were spurious and did not cause authentication issues.

    The reason I raised the call was my logon times dropped from instantaneous to 5-10mins for certain users after installing SP2. This was attributed to having a value of 0 for 'Level of nested groups' in my Authentication Server Search Settings. Changing this value to 2 has improved logon times to a couple of seconds but its nowhere near as quick as it was.

    Authentication appears to have changed a lot in SP2 - worth doing lots of testing after you apply it.

    My FIPS compliance settings also stopped working after applying SP2 so I had to disable the GPO setting to force FIPS compliance :(

    Wednesday, December 19, 2012 5:11 PM
  • We haven't yet received the latest hotfix, it will be interesting to see which version we get! At the moment the only way we can keep our service going is to recycle the default application pool every 15 minutes on both the servers!

    Thursday, December 20, 2012 9:10 AM
  • We have been supplied with v4.0.2095.10006 and this does seem to have stopped both the event log filling up with ldap errors and more importantly the default application pool pool crashing on a very regular basis.

    Friday, December 21, 2012 12:31 PM