CIM installer - domain user account parameters not recognized

I'm trying to install a Cisco Interaction (Eim-Wim) but i have a problem. during a step installation, I can't authenticate the user. I tried some options, but not recognized by installation program. I tried with domain user and local admin, but not work. The lab is in domain and a single server. Help me.

Hi,
Please refer the below discisson on the same topic,
http://pdirequest.egain.com:8080/community/posts/list/66.page
Hope it helps,
Anand
Please rate helpful posts..

Similar Messages

Domain user account will not authenticate once user logs out and logs back in

Greetings,
I am having difficulty resolving an issue with a Mac user on my domain. the user can log in no problem from the initial start up, however when the user logs out and trys to log back in, the domain account and the password doesn't authenticate. the only way the user can log back in is by shutting down completely.

The guys around here who know anything about that hang out on Mac OS X Server forum. Many of them support mixed Server environments in their day jobs.
OS X Server

Software always installs to Domain Admin account on connected PC-cant install to Domain User account

I have completed the following steps:
Set up Windows Server 2012 R2 Essentials successfully
Successfully connected a Windows 8.1 Pro PC to the network by running the Essentials Connector software
The PC has the following users: Original local account created when I installed Windows 8, Domain Admin account created when I ran the Essentials Connector account, Domain User created after PC was connected to the network.
Everything seems to be working fine. I have installed MS Office 365 Pro, Skype, various other applications while logged in as the Domain User. Every one of these installs triggered a UAC prompt, which was expected, and after entering the Domain Admin
credentials the install proceeded successfully. After install, the software was available to the Domain User, shortcuts appeared in the Start Menu or Desktop, appropriate directories were created in the Documents folder.
All except for 3 applications - upon being prompted for permission to install, I enter the Domain Admin credentials, installation proceeds, but the software is installed to the Domain Admin account-not the Domain User account. Shortcuts appear on the Domain
Admin desktop-Not the Domain User account, etc. I've tried:
Downloading a new copy of the software to the Domain User desktop & running it from there
Right-click file, Install as Admin
click file, Install as a different user
Right clicking file, Properties>Compatibility & changing compatibility settings
Right clicking file, Properties>Compatibility>Run as Administrator
None of these options have changed the result, the software is still installed to the Domian Admin account as opposed to the Domain User account. Any idea why these 3 software wont install correctly but everything else has? Any suggestions as to how to install
the software to the profile that doesn't involve making the Domain User an Administrator? Thanks for any help!

Hi voltron5,
Many programs may provide options: "install for everyone" or "just for current user", when you install them.
Please check if there are such options during the installation process.
If those three programs are all third-party applications. I suggest you should contact with the corresponding
support and confirm this.
If those three programs are Microsoft applications, would you please let me know specific information of those
three applications? Such as their names and so on. Meanwhile, when complete the installation, please check the software path was added in administrator environment variables or system environment variables.
Hope this helps.
Best regards,
Justin Gu

Account Information Not Recognized: The user account has been disabled.(FW

Hi Expert ,
I'm working with SAP Business Objects 4.0 SP2 patch 5 and SAP Enterpriseportal. I want to use Single Sign On with trusted authentication in enterprise portal. EP administrator has created an infoview in order to be able to connect the portal and BO.
I have configured trusted authentication in BO but when I try to use the infoview from the portal the following error appear:
"Account Information Not Recognized: The user account has been disabled.(FWB 00012) "
the user used in the sap portal is also defined and active in sap BO.
In order to activate SSO in BO I executed the following steps:
1. Log onto the CMC.
2. Went to the Authentication management area.
3. Select the Enterprise option. The "Enterprise" dialog box opens.
4. Scroll down until I see "Trusted Authentication".
4.a. Click Trusted Authentication is enabled.
4.b. Click New Shared Secret.
4.c. Click Download Shared Secret.
5. Selected Update to commit the shared secret.
6. Saved the trustedprincipal.conf file in the boe server in the path:
'D:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects
Enterprise XI 4.0\win32_x86'
7. Modified the file 'D:\Program Files (x86)\SAP
BusinessObjects\Tomcat6\webapps\BOE\WEB-INF\config\default\global.properties'
sso.enabled=true
sso.sap.primary=false
trusted.auth.shared.secret=
trusted.auth.user.param=
trusted.auth.user.retrieval=REMOTE_USER
8.Restart Tomcat
Please could anyone help me to resolve the issue?
Thanks in advance for collaboration.
regards
gio'

Hi Giovanni,
The configuration you have wonu2019t work. You have two different web application servers: Netweaver and Tomcat. Your user credentials are only established in one of them: Netweaver. When you configure trusted authentication in Tomcat you have to authenticate the user in this Web Application server. The REMOTE_USER canu2019t pass from one server to another.
You can confirm this capturing your request using Fiddler in your browser.
If you want to configure the integration BI4 into SAP Enterprise portal, you can follow this guide:
http://wiki.sdn.sap.com/wiki/display/BOBJ/BI4IntegrationintotheSAPEntreprisePortal+7.0.x
Regards,
Julian

VMM Shared ISO error "User account does not have permission required to open attachment"

I had this error once because the local service account was selected during installation of VMM. I have reinstalled VMM with a Domain service account and the error went away. However, the error is back.
"User account does not have permission required to open attachment '\\[servername]\VMMLibrary\server.ISO'. Error: 'General access denied error' (0x80070005). (Virtual machine ID GUID)"
I tried to create this VM on Host1 and got the error.
I then went to Host2 and was able to create the VM while using the same ISO on the same VMM library that failed on the Host1.
Both hosts have agent 3.2.7634.0 and are both running Hyper-V Server 2012 R2.
What is wrong with Host1 and how do I correct it?
Thank you.

This is a share configuration permissions issue.
http://technet.microsoft.com/en-us/library/ee340124.aspx
Brian Ehlert
http://ITProctology.blogspot.com
Learn. Apply. Repeat.

Should I use Managed Service Accounts or individual, Domain User accounts?

I'm setting up a new SP 2013, and I'm trying to be very granular as it relates to "Least Privilege".
I'm trying to figure out which accounts could be created as Managed Service Accounts (MSA's) and which ones truly need to be created as Domain User accounts in order to run either specific SQL and/or SharePoint services.
At face value, I *think* any service could be successfully run using an MSA and yet any installation of either SQL Server 2012 and/or SharePoint 2013 should be done using a Domain User account created for that specific purpose (i.e., SP_FARM, SP_ADMIN, SQL_ADMIN,
etc.). In fact, I *think* the installation would HAVE to be done with an actual Domain User account, because (unless I'm wrong), MSA's do not have a shell and therefore CAN'T log on...which is by design?
Here's a Microsoft TechNet article that lists many of the accounts I'm referring to:
https://social.technet.microsoft.com/wiki/contents/articles/14500.sharepoint-2013-service-accounts.aspx
Note that it says MOST of the accounts are Domain accounts, but I don't *think* all of these need to BE
Domain accounts - I think MOST of them could be created as MSA's and assigned to run the specific service without any problems whatsoever?
So again, my question is: which accounts could be created as Managed Service Accounts (MSA's) and which ones truly need to be created as Domain User accounts in order to run either specific SQL and/or SharePoint service or to even perform a
successful installation of the software?
Ed

No, script 1 does not create Active Directory Managed Service Accounts (see here:
http://blogs.technet.com/b/askds/archive/2009/09/10/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting.aspx) These are not applicable to SharePoint and are not mentioned in any of those scripts, look at the PowerShell
commandlets, they are very different.
Script 1 creates active directory users. These are, as far as AD cares, just standard user objects. There is nothing at all special about them in AD.
At some point you would install SharePoint using those accounts, during that process they get resisted in SharePoint as SharePoint Managed Accounts.
Script 2 updates the settings on those managed accounts in bulk.

Windows AD login error: Account Information Not Recognized: Internal error.

I follow this documentation and everything is working fine.
http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e0edd98d-c43e-2b10-e09a-e0a89931cedc
1. create a domain user called bossosvcacct
3. I was able to mapped group into the CMC and I do see user being mapped into the system.
4. I did a test to make sure the kerbose is working correctly by running kinit username
I got everything working except for when I login I'm getting this error.
Account Information Not Recognized: Internal error.
This is what is in my log.
Commit Succeeded
Debug is true storeKey false useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
[Krb5LoginModule] user entered username: johndoeDOMAIN
Acquire TGT using AS Exchange
principal is johndoeDOMAIN
EncryptionKey: keyType=23 keyBytes (hex dump)=0000: 17 29 81 67 E0 91 65 B3 61 D6 1E D9 DF BB 65 F0 .).g..e.a.....e.
Commit Succeeded

What do you get if you login to client tools (deski/designer/CCM)?
commit succeeded is only the kinit part of the login, the CMS then needs to make a TGS request using the CMS service account. logging in with the client also requires this and is a good test. If clients work then the only known issues are for multi-domain/multi forest or encrypti0on mismatches between the service account and java configuration.
Let us know...
Regards,
Tim

"Unable to check revocation" error while checking CDP from non-domain user account

Hi!
I use 3-tier PKI infrastructure:
Stand-alone offline Root CA: RootCA;
Stand-alone offline Intermediate subordinate CA: SubCA;
Enterprise CA: EntSubCA.
In certificate we have three CDP point for CRL check:
ldap:///, http:// and file://
I have Windows 2008 R2 server joined to domain.
I use command certutil –verify –urlfetch <filename.cer> >check.txt for revocation checking of certificate.
When I use domain user account for revocation checking, all OK.
I have access to any CDP and all fine.
But when i use local server user account, I haven't access to ldap:/// and process failed although all other links is OK.
My question is "why check fail with non-domain user accout while other CDP point succesfully verifed"?
Here is the logfile from local user:
Issuer:
CN=EntSubCA
DC=DED
DC=ROOT
Subject:
CN=servername.domain_name
Cert Serial Number: 5a896145000300006ee2
dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1)
dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2)
dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8)
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
ChainContext.dwRevocationFreshnessTime: 5 Days, 23 Hours, 15 Minutes, 48 Seconds
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
SimpleChain.dwRevocationFreshnessTime: 5 Days, 23 Hours, 15 Minutes, 48 Seconds
CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=1000040
Issuer: CN=EntSubCA, DC=DED, DC=ROOT
NotBefore: 05.02.2015 20:03
NotAfter: 05.02.2016 20:03
Subject: CN=servername.domain_name
Serial: 5a896145000300006ee2
SubjectAltName: DNS Name=servername.domain_name
Template: Machine
70 e4 6b 16 05 a1 62 e3 6d 24 96 ff 44 74 ee a2 3e ce df 18
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
---------------- Certificate AIA ----------------
Failed "AIA" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
ldap:///CN=EntSubCA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?cACertificate?base?objectClass=certificationAuthority
Verified "Certificate (0)" Time: 0
[1.0] file://\\ca\crl\EntSubCA.crt
Verified "Certificate (0)" Time: 4
[2.0] http://webserver/crl/EntSubCA.crt
---------------- Certificate CDP ----------------
Failed "CDP" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
ldap:///CN=EntSubCA,CN=ca,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?certificateRevocationList?base?objectClass=cRLDistributionPoint
Verified "Base CRL (018d)" Time: 0
[1.0] file://\\ca\crl\EntSubCA.crl
Failed "CDP" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
[1.0.0] ldap:///CN=EntSubCA,CN=ca,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?deltaRevocationList?base?objectClass=cRLDistributionPoint
Old Base CRL "Delta CRL (018d)" Time: 0
[1.0.1] file://\\ca\crl\EntSubCA.crl
Old Base CRL "Delta CRL (018d)" Time: 4
[1.0.2] http://webserver/crl/EntSubCA.crl
Verified "Base CRL (018d)" Time: 4
[2.0] http://webserver/crl/EntSubCA.crl
Failed "CDP" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
[2.0.0] ldap:///CN=EntSubCA,CN=ca,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?deltaRevocationList?base?objectClass=cRLDistributionPoint
Old Base CRL "Delta CRL (018d)" Time: 0
[2.0.1] file://\\ca\crl\EntSubCA.crl
Old Base CRL "Delta CRL (018d)" Time: 4
[2.0.2] http://webserver/crl/EntSubCA.crl
---------------- Base CRL CDP ----------------
Failed "CDP" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
ldap:///CN=EntSubCA,CN=ca,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?deltaRevocationList?base?objectClass=cRLDistributionPoint
OK "Base CRL (018d)" Time: 0
[1.0] file://\\ca\crl\EntSubCA.crl
Failed "CDP" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
[1.0.0] ldap:///CN=EntSubCA,CN=ca,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?deltaRevocationList?base?objectClass=cRLDistributionPoint
Old Base CRL "Delta CRL (018d)" Time: 0
[1.0.1] file://\\ca\crl\EntSubCA.crl
Old Base CRL "Delta CRL (018d)" Time: 4
[1.0.2] http://webserver/crl/EntSubCA.crl
OK "Base CRL (018d)" Time: 4
[2.0] http://webserver/crl/EntSubCA.crl
Failed "CDP" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
[2.0.0] ldap:///CN=EntSubCA,CN=ca,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?deltaRevocationList?base?objectClass=cRLDistributionPoint
Old Base CRL "Delta CRL (018d)" Time: 0
[2.0.1] file://\\ca\crl\EntSubCA.crl
Old Base CRL "Delta CRL (018d)" Time: 4
[2.0.2] http://webserver/crl/EntSubCA.crl
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
CRL 018d:
Issuer: CN=EntSubCA, DC=DED, DC=ROOT
33 af 4d be 0e 35 45 94 bc 8b 3f d9 c1 60 e7 0c c4 83 17 b6
Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication
CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=SubCA
NotBefore: 13.11.2014 19:12
NotAfter: 13.11.2017 19:22
Subject: CN=EntSubCA, DC=DED, DC=ROOT
Serial: 6109015b000100000008
Template: SubCA
9b 04 17 9f c5 fe 52 ca a5 58 49 6c c6 18 fa db 13 b3 92 9e
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
Failed "AIA" Time: 0
Error retrieving URL: The network path was not found. 0x80070035 (WIN32: 53)
file://\\sub_ca\CertEnroll\sub_ca_SubCA(1).crt
Verified "Certificate (0)" Time: 0
[1.0] file://\\ca\crl\SubCA.crt
Verified "Certificate (0)" Time: 4
[2.0] http://webserver/crl/SubCA.crt
---------------- Certificate CDP ----------------
Verified "Base CRL (32)" Time: 0
[0.0] file://\\ca\crl\SubCA.crl
Verified "Base CRL (32)" Time: 4
[1.0] http://webserver/crl/SubCA.crl
---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
CRL 32:
Issuer: CN=SubCA
8d a9 9d 51 65 a3 8e 77 02 22 40 57 62 70 e8 f6 c5 2e 60 1e
CertContext[0][2]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=RootCA
NotBefore: 28.05.2008 12:09
NotAfter: 28.05.2058 12:19
Subject: CN=SubCA
Serial: 616bd19f000100000004
Template: SubCA
06 d2 47 e7 dc 8f a7 97 a2 b8 c3 92 03 19 24 0c 47 45 22 14
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
Verified "Certificate (0)" Time: 0
[0.0] file://\\ca\crl\RootCA.crt
Verified "Certificate (0)" Time: 4
[1.0] http://webserver/crl/RootCA.crt
---------------- Certificate CDP ----------------
Verified "Base CRL (1c)" Time: 4
[0.0] http://webserver/crl/RootCA.crl
Verified "Base CRL (1c)" Time: 0
[1.0] file://\\ca\crl\RootCA.crl
---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
CRL 1c:
Issuer: CN=RootCA
dc 98 2f 8d 16 9c 64 6e b2 74 89 95 9a 6c 1b 77 fd 58 63 fb
CertContext[0][3]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=RootCA
NotBefore: 27.05.2008 16:10
NotAfter: 27.05.2110 16:20
Subject: CN=RootCA
Serial: 258de6fbd3bbab92460530e9e9f10536
5d e4 56 38 13 0a 52 aa 66 51 25 61 19 33 c9 d7 a2 c7 dd 38
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
Verified "Certificate (0)" Time: 0
[0.0] file://\\ca\crl\RootCA.crt
Verified "Certificate (0)" Time: 4
[1.0] http://webserver/crl/RootCA.crt
---------------- Certificate CDP ----------------
Verified "Base CRL (1c)" Time: 0
[0.0] file://\\ca\crl\RootCA.crl
Verified "Base CRL (1c)" Time: 4
[1.0] http://webserver/crl/RootCA.crl
---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
CRL 1c:
Issuer: CN=RootCA
dc 98 2f 8d 16 9c 64 6e b2 74 89 95 9a 6c 1b 77 fd 58 63 fb
Issuance[0] = 1.2.700.113556.1.4.7000.233.28688.7.167403.1102261.1593578.2302197.1
Exclude leaf cert:
5b 8d 96 39 f8 a3 6f af f3 89 bc 8d 78 e2 da 53 21 b8 ff aa
Full chain:
ca 99 30 47 9b ad ab ce 97 cc 70 80 a5 4e 11 b3 1a 83 98 78
Verified Issuance Policies: None
Verified Application Policies:
1.3.6.1.5.5.7.3.2 Client Authentication
1.3.6.1.5.5.7.3.1 Server Authentication
ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)
CertUtil: The revocation function was unable to check revocation because the revocation server was offline.
CertUtil: -verify command completed successfully.

What you have discovered is the reason to *not* use LDAP URLs for CDP and AIA extensions in your PKI. To access those URLs, the account must access to the URLs. In your output, it is quite clear that the local account does not have necessary permissions
(you also use FILE URLs for publication, which again is not recommended).
The best practice is to use a single URL for the CDP extension. It should be an HTTP URL that is hosted on a highly available (internally and externally accessible) Web cluster.
For the AIA extension, it should contain two URLs: one for the CA certificate - again to an internally and externally accessible, highly available Web cluster and one for the OCSP service - also
an internally and externally accessible, highly available Web cluster.
the other issue is that the root CA is *not* trusted when run by a non-domain account. How are you adding the trusted root CA. It is recommended to do this by running
certutil -dspublish -f RootCA.crt.
This will ensure that the computer account trusts the root CA. In your output, the root CA certificate is not trusted.
Brian

The connection was denied because the user account is not authorized for remote login

Using Terminal Server 2008 not able to get non administrator users to login to the remote desktop. Have tried from Windows server 2008 and from Windows servers 2003. Get error login in "The connection was denied because the user account is not authorized for remote login" from Windows Server 2008. Error "The requested session access is denied" from Windows Server 2000.

Is that seriously the only way to do this? Doesn't this render the "Allow log on through Terminal Services" GP Setting useless?
I would like to know this answer, as well. I have created a new AD group for my assistant admins called "Domain Admins (limited)". I have added this group to the GP setting "Allow log on through Terminal Services", but the
assistant admins cannot log in through RDP. It 'feels like' this is all I would need to do.
Craig
Found some good info
here. There are really two things required for a user to connect to a server via RDP. You can configure one of them via Group Policy but not the other.
1) Allow log on through Terminal Services can be configured through Group Policy, no problem.
2) Permissions on the RDP-listener must also be granted. If your user is a member of the local Administrators group or the local Remote Desktop Users group then this is handled. If you are trying to utilize a new, custom group (as I am),
then there isn't a way to do this via group policy (that I have found).
EDIT: Found the answer. I am creating a blog post to outline the steps. They aren't hard, but they're not self-explanatory. It deals with the Restricted Groups mentioned above, but it's still automate-able using Group Policy so that you
don't have to touch each computer. I think the above poster (Andrey Ganev) got it right, but
I had trouble deciphering his instructions.
Here is my blog post that walks through this entire process, step-by-step.

SSAS issue with Domain user account

Hi
I have SSAS 2008 R2 set up running on Windows Server 2012 Standard.
The server is registered as a part of domain.
I have had an issue of domain user accounts accessing to a cube and it's starting to get worse. There has been no problem with a local user account (I set up a few for testing purpose).
I ran the role report from BIDS Helper and it finds all the domain user accounts invalid.
It looks like SSAS is not talking well with the domain server (Windows 2003 server standard) to verify user credentials. But the thing is that everyone is ok with the domain server except for SSAS. IT does not have a clue what's going on here and everything
is just pointing at me right now.
I'd like to know if there is anyway to monitor that communication between SSAS and domain server for user credential verification and any guideline on how to resolve it. Most of time, it just works again.. like 10 minitues later.. it resolves by itself.
But this time, not!!!
All I know is that 1. Registering the server as a part of domain 2. use domain user account to set the security.
MY IT department has set up network monitoring tool and says that they are 100% percent working (No connection loss. It's monitoring Active directory as well). The application installed is 'ManageEngine Applications Manager'
I don't know what to do here.
P.S Will it be related something like 'Error
while Add user to SSAS Server - The trust relationship between the primary domain and the trusted domain failed' but it's all the domain accounts including mine are not working.
Cheers!!!

First check your DNS servers setting on the server you have SSAS installed. You should only use the IP addresses of the DNS servers (e.g. Domain Controllers) of your domain. Active Directory relies on proper DNS server settings. Adding public DNS servers,
even if they are on the bottom of the list, will mess up name resolving Active Directory names. This should have been done when IT had provisioned the server. Same goes for own workstation if you run your development/management software not on the server.
Second make sure SSAS is running under a service account that has access to Active Directory. This can be either a domain account, the local system account, or the network service account. Running SSAS under a local account or the local service account will
not work because local accounts do not have access to Active Directory. Running SSAS under either a Managed Service Account or a Virtual Account will not work because those features require the domain at least the Windows Server 2008 R2 functional
level.
Third make sure the account you use to log on to SSAS is a domain account and has appropriate permissions in SQL Server and SSAS. Local accounts and SQL Server account do not have access to Active Directory

SharePoint farm - SQL Server - MSSQLSERVER service is running as "Local System" - Can I change it to Domain User account?

Hi there,
In my SharePoint 2010 farm - on the SQL Server:
The MSSQLSERVER service is running under Local System.
1. Can I change it to run as a normal Domain User account?
2. Does it need any extra privileges?
3. Is it a safe thing to do?
Brief description will be very useful.
Thanks so much.

You need to create Service account with password never expire option+ User never change password
Then you need to go through below recommendation from Microsoft
Security Considerations for a SQL Server Installation
Planning for Services, Accounts, and Connections
Hope you got starting point
Please 'propose as answer' if it helped you, also 'vote helpful' if you like this reply.

Windows 2012 : A domain user who does not belong to the Administrators group can change the passwords

Hello,
Can a domain user
that does not belong to the Administrators group,
be able to change your password ?
I tried to create a domain user account
without administrative access. This user account have
permission to access Windows Server
2012 via Remote Desktop.
I tried to access the same account
to the Active Directory Users and Computers,
i was amazed, because the user account it can changed
the password for multiple accounts,
included one administrator account.
Best regards,
Ricardo

Hi Ricardo,
I agree with Martin, we can check the membership about this user account. Besides, we can refer to following steps to check the memberships:
Start the ADUC on windows 2012.
Right-click the user account and select
Properties, then click the Member Of tab.
Check which group is the user account belongs to.
In addition, i suggest you create a new user account, and check if the new account can change other user’s password.
Best Regards,
Erin

Why domain users account allowed to logon to servers directly?

I'm using Windows Server 2008 R2 with ADDS.
By default, normal user account (domain users) should not be allowed to logon to Server directly, I mean the physical server or via RDP. They should get the message:
"You cannot log on because the logon method you are using is not allowed on this computer"
I had checked the GPO, under the Computer Configuration -> Windows Setting -> Local Security Policy -> Local Policy -> User Rights Assignment -> Allow Log on Locally, here only contains:
Administrators, Account Operators, Backup Operators, Server Operators, Print Operators
And, nothing set on the Deny Logon Locally.
But, tested that, those accounts with just Domain User Group are able to logon to Server!?
How or where should I check, to not allow normal user account to logon to server directly?
Thank you.

Hi,
>>By default, normal user account (domain users) should not be allowed to logon to Server directly, I mean the physical server or via RDP.
By default, standard domain user accounts can log onto workstations and member servers, and they can’t log onto domain controllers unless we allow them to do so via group
policy.
By default, standard domain user accounts can’t remote desktop onto other computers unless they have been added to Remote Desktop User groups of the computers.
Regarding allowing log on locally, the following article can be referred to for more information.
Allow log on locally
http://technet.microsoft.com/en-us/library/cc756809(v=ws.10).aspx
Regarding remote desktop user groups, the following article can be referred to for more information.
Configure the Remote Desktop Users Group
http://technet.microsoft.com/en-in/library/cc743161.aspx
>>How or where should I check, to not allow normal user account to logon to server directly?
We can utilize group policy setting
Deny logon locally to prevent users from locally logging onto the targeted computers.
Regarding this setting, the following article can be referred to for more information.
Deny logon locally
http://technet.microsoft.com/en-us/library/cc957048.aspx
TechNet Subscriber Support
If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.
Best regards,
Frank Shen

Query to retrieve windows domain user account

I am totally new to Oracle. Right now, I have a requirement which needs the windows domain user account and local user accounts to be found and linked to. I ve been searching on google, but no use. Frankly, I have no idea even what I am supposed to do and I am not sure what I wrote here is even framed correct. Please help me out. Thanks a lot.

Hi,
I think you've made your first Oracle mistake: think that Oracle is working just the same as MS SQL Server :-)
First, before trying to do anything, you must read the TFM: Database Concepts(click) in order to begin to understand how Oracle works.
I'm going to try to explain fast and simple.
Oracle user accounts are different accounts than OS accounts. That is the first important point to get. A domain user "toto" will not automatically gat an Oracle "toto" account.
There are 3 types of user authentication:
. Password: typical authentication, no link between OS account and Oracle account
. External: User is authentified by the O.S. This means that the DBA has to create a special account that'll be "linked" to the O.S. account (whether it's a local or domain account)
. Global: The user is authentified by the enterprise directory service.
You can see these 3 approaches in the SQL Statements: CREATE USER doc(click). So, there is some way to link the Oracle user account to the O.S. user account, but not straight forward!
I need to verify if my oracle database user account is a windows domain user or not, if he/she is one, then if he/she is a local user account or a global user accountWhen I read this, the closest thing I can think of is the 3 types of authentication. And the info can be found in DBA_USERS (columns USERNAME, EXTERNAL_NAME and PASSWORD - obfuscated of course).
With these info, maybe can you see why your requirement is a bit strange? Anyway, read the references I linked and come back here with more questions / comments :-)
HTH,
Yoann.

My user name is not recognized for sync

On my new computer my user name is not recognized for the sync set up. I have sync on my other computers.

Is this the only account you have on your system? Is it an admin account?
You can try resetting the password using the Mac OS X install disc. The steps are outlined here: http://docs.info.apple.com/article.html?artnum=106156
Scroll to the part titled: "Resetting the original administrator account password."
Hope it helps.

CIM installer - domain user account parameters not recognized

Similar Messages

Maybe you are looking for