locked
RTCService Account privilegs in Active Directory RRS feed

  • Question

  • Hi,

    i deployed an OCS 2007 R2 in my enviroment.
    I created a pool and one consolidated Enterprise Edition Server.

    Everything went just fine, but I get this strange Error:

    Active Directory operation failed while verifying validity of service account password
    
    Active Directory operation failed with error code: 0x80070005 (General access denied error
    )
    Cause: The service account may not have required privileges to access Active Directory.
    Resolution:
    Check domain controller/global catalog server connectivity and whether the service account has sufficient privileges to access the Active Directory. If the problem persists, contact Product Support Services.
    I manually created the RTCService user. This account is member of

    |---Domain Users

    |---RTCComponentUniversalServices

    |---RTCHSUniversalServices

    I checked the password twice, this is not the problem.

    The Services under "services.msc" are all running. So starting services isn't the problem either.

    Do you have any idea how to solve this ?

    Thanks

    Friday, July 3, 2009 12:28 PM

All replies

  • Is there a reason you manually created the account instead of letting the deployment wizard create the account for you?  I've always let OCS create the service account during the initial installation so it's possible that by selecting an existing account (that was not provisioned by an OCS deployment procedure) the wizard only uses the existing account as-is and does not modify the permissions; it may assume that the account was properly configured, which in this does it does not appear to be.
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Friday, July 3, 2009 12:53 PM
    Moderator
  • The administrators in my company wanted to create an account by themselves maybe they did not trust the installer.
    But anyways, if the RTCService account is in the right User Groups this should be working without the wizard, doesn't it?

    Is there a workaround, or would you suggest running the wizard again, this time, letting the wizard create the users?

    Friday, July 3, 2009 12:59 PM
  • i made a new installation in my testlab, using manually created service accounts and everything works just fine.
    there must be some right issues in my AD but i haven't figured out what they are yet.
    if anyone has some ideas about those AD rights, that would be great.
    Wednesday, July 8, 2009 6:37 AM
  • I am experiencing the same error on my OCS 2007 Standard (non-R2) server and my accounts were created by the wizard. The errors do not go away when I add the user to the Domain Admins group. When the user was initially created, it was a member of:
    Domain Users
    RTCComponentUniversalServices
    RTCHSUniversalServices

    The password policy that applies to this account is:
    Enforce password history 10 passwords remembered
    Maximum password age 364 days
    Minimum password age 1 days
    Minimum password length 15 characters
    Password must meet complexity requirements Disabled
    Store passwords using reversible encryption Disabled

    The account level password settings are:
    Password never expires


    Does anyone know what specific requirements are needed by OCS to successfully verify the validity of this account? Since the test of adding the RTCService to Domain Admins does not make the error go away I am at a loss. Any assistance here would be greatly appreciated.

    Thanks,

    John

    • Edited by Akhnot Friday, July 17, 2009 3:18 PM
    Friday, July 17, 2009 3:00 PM
  • Hi Akhnot,

    I found this:

    http://support.microsoft.com/kb/830534/en-us/

    Seems that that should fix our problem.

    In my case Domain Admin privileges didn't solve the problem either.

    Regards
    • Marked as answer by Gavin-ZhangModerator Thursday, July 30, 2009 9:00 AM
    • Unmarked as answer by g3ocs Friday, July 31, 2009 5:33 AM
    Monday, July 20, 2009 6:56 AM
  • Hi g3,

    I actually restarted the OCS services after applying domain admin priv's (on a whim) and let it sit over the weekend, and the alarms went away. Unfortunately I had already made that post before the service restart. I took away Domain admin this morning and restarted the services, and the error is back. So after that experiment I would say that it is a security test that is failing but is not showing up in logs. I am currently in the process of trying to decipher what a DCDIAG's output using the RTCService as the user account should look like (I have only tried to use it with Domain admin/Enterprise admin priv's).

    Regarding the article (830534): I do have a domain Maximum password age defined (364 days) but have 'Password never expires' enabled on the RTCService account (this was under direction of MS Support).

    Thanks for the feedback,

    John
    • Marked as answer by Gavin-ZhangModerator Thursday, July 30, 2009 8:59 AM
    • Unmarked as answer by g3ocs Friday, July 31, 2009 5:33 AM
    Monday, July 20, 2009 5:25 PM
  • hi,

    if i disable "pasword never expires" and set the RTCService Account to expire on a specific date. the errors go away. it's kind of weird because i don't want my service account to expire.
    i will have a nother look.

    regards

    Tuesday, July 21, 2009 5:32 AM
  • Hi all

    Most of the problems I had in the past if changed something with OCS service accounts it was related to the caching functionality of WMI Service. This service caches the accountinfo, so if you changed anything on the service account, restarting this service can fix a lot ;-)

    Cheers
    Werner
    • Marked as answer by Gavin-ZhangModerator Thursday, July 30, 2009 8:50 AM
    • Unmarked as answer by g3ocs Friday, July 31, 2009 5:33 AM
    Wednesday, July 22, 2009 6:27 AM
  • interesting...who is Gavin-Zhang and why is he/she marking answers when so far nothing has worked?

    Anyway... I tried the password changes and restarted all services, no luck. Making the account domain admin seems the only "fix" for me and that's not a fix, it's a cheat. =)

    I'm thinking its a bug in the validity checking...maybe I'll spend a technet support incident and get MS Support to answer this themselves.
    Thursday, July 30, 2009 3:58 PM
  • i haven't fixed it either.
    domain admin cheating isn't an option in my enviroment.
    i hope there will be a workaround soon.

    Friday, July 31, 2009 5:33 AM
  • Hello all

    If it works with Domain Admins, you have a permission related issue which could be related to the DomainPrep. Try to run this again could be a solution then.

    Cheers
    Werner
    P.S. I do not know Gavin-Zhang also

    Friday, July 31, 2009 7:56 AM
  • sure you seem to be right werner, but according to this post:

    http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=66

    there are some issues with the function checking the validity of the service accounts.

    neither do i want to "domain admin" cheat this error away nor to set the accounts to expire at some specific date.

    so like akhnot said, let's hope there will be a fix, or a workaround. 
    Friday, July 31, 2009 8:28 AM
  • g3ocs

    Good link you provided, did not know this one :-)

    What I thought is, if there are permission related problems because you have created the accounts not with the wizzard, then running the wizzard again after creating the accounts give you the opportuny to select the existing accounts and let do the wizzard the work to set the permissions the right way.

    There is a related thread I found under:
    http://social.microsoft.com/Forums/en-US/partnermsglcs/thread/744df665-976d-4c17-9fbd-19456f223bdf

    Cheers
    Werner
    Friday, July 31, 2009 10:02 AM
  • I'll give it another try in my test enviroment, but i think i tried that already.

    These errors are driving me nuts =)
    Friday, July 31, 2009 10:21 AM
  • Werner,

    I can't seem to view that thread, possibly a different account type (I am not a MS Partner account holder).

    However, I did let the wizard create my accounts as I mentioned in my initial reply to this thread. Could you post the suggested resolution from that thread here?

    Thank you,

    John
    Friday, July 31, 2009 1:16 PM
  • Akhnot

    It is not finished yet with the final solution, I will keep you updated on this ...

    Cheers
    Werner

    Friday, July 31, 2009 1:23 PM
  • Hello all

    In the first message of this thread there is only mentioned the RTCService account. What is abot the RTCcomponentservice account?


    From a post of Paolo in another thread:

    Here are the other two possibilities based on my correct research.
    1. OCS service didn’t belong to proper group.
    2. Replication issue existed in domain. So that, the permission and data is not consist on all DCs.

    For possibility 1.
    We are using two service account by default. I assumed their name is not changed.
    a. RTCservice
    b. RTCcomponentservice

    RTCservice should be the member of following groups.
    - Domain users
    - RTCComponentUniversalServices
    - RTCHSUniversalServices

    RTCcomponentservice should be the member of following groups
    - Domain users
    - RTCComponentUniversalServices

    Check them both and verify if the group membership is correct.

    Cheers
    Werner

    Monday, August 3, 2009 9:58 AM
  • hi werner,

    group membership on both accounts is exactly as you described in your post.

    we have no replication issue in our domain either.

    but maybe this helps out someone else, thank you for yor help.
    Tuesday, August 4, 2009 10:40 AM
  • The task goes on, next one from Paolo:
    -----

    This issue occurs when OCS service tries to retrieve the password expiration time for the service account that it runs under. OCS performs this operation every hour to generate an event to warn an administrator if the password for the service account that it runs under is scheduled to expire.

    However, this behavior failed due to permission issue.

     

    This is similar to our issue due to “every hour” feature. Our error logged per hour exactly.

     

    So, let’s check:

    1.        If authenticated user have read and apply permission to “default domain policy”

    2.       Check if Password expire policy is set.

     

    To check group policy’s permission, we can use gpmc.msc admin tool.
    -------

    Cheers
    Werner

    Tuesday, August 18, 2009 10:35 AM