I work for an MSP, We have a client that wants us to add a third DC to their production domain. We didn't build the domain. The previous admin gave us three or four different passwords to try.
When I did this, I put the password in, the DC joined the domain as a computer, but was not listed as a DC. Running DCDIAG showed access errors on some of the tests.
I then powered off one of the existing DCs, and demoted the third DC, removed it from the domain.
Is there anyway to non-destructively test the other passwords to see if they work. I am just afraid that I will screw something up with the adding and subsequent removal of a planned AD.
I find it rather odd that the DCPROMO process completed with an incorrect password. One would think that that would be tested before anything else was done.
Any help or ideas is greatly appreciated.
Thank you.
S
Domain Admin rights should be fine for promoting the server.
Leave the two DCs online.
Domain join the new server.
Run Install-ADDSDomainController.
Related
I am investigating if it is at all possible to track assigned permission sets, profiles and roles with the sfdx cli tools. So far my findings are that Permission sets and Profiles are trackable as they get converted to source but it is up to the administrator to assign profiles / permission sets after deployment.
Can anyone confirm this and point me to some documentation on the limits of what the sfdx cli can pull.
There's https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_unsupported_types.htm but that's not exactly what are you asking, the question is bit confusing.
PermissionSetAssignment table is well, a table. Normal data like Account, not metadata. Same with Users, their Roles, group memberships... You wouldn't typically store it in version control unless you're after some "golden copy" good test dataset to load to sandboxes/scratch orgs.
SF tried once to be smart with deploying queue memberships, record folder permissions and approval process assignees and the results are... Meh. You inspect the XML file and see usernames with sandbox suffix in them that they try to magically match during deployment to target org. It's "fun" when developer who created the report folder doesn't exist in production / username doesn't match (creator automatically gets added as Manager, it's extra step to remember and maybe remove that). It's even more "fun" when you keep working on the project in different sandboxes and git keeps reporting changes of suffix from ".dev" to ".proto" or ".hotfix"...
Try to rethink your question, what are you after? You can implement single sign on with piece of apex code running on login (or look into Identity Connect) so people's permissions will be synced based on their role in Active Directory/Google apps engine / what have you. Or if you really want you should be able to periodically query & upsert back CSV of PermissionSetAssignments. Or have a script during deployment to run a bunch of permset assign commands?
What will you do when John Doe moves from Marketing department to Sales? Who's right, SF or git project? Would it really need a deployment to change it?
I have multiple Managed Service Identities (MSIs) that need the same set of permissions to use Microsoft Graph. I've given permissions to one of the MSIs directly and I got the expected result (after waiting for permissions to propagate).
To make life easier, I decided to create a security group, give that group the needed permissions, then assign the various MSIs to that security group. I've verified that the AppRoleAssignments are correct for the security group, but the group members do not seem to inherit the access as expected (even after waiting to ensure permissions have had time to propagate).
Does anyone know if this scenario is supported?
I posted the same question in GitHub and I got my answer there. The net out is that this scenario is not currently supported, however, it may be a supported scenario in the future.
https://github.com/microsoftgraph/microsoft-graph-docs/issues/2797
On SQL Server 2008 R2 Standard edition whenever I try and update Data Source credentials via the Report Manager I cannot save the changes as it reports the message
"The password is not valid. Please retype the password".
I've looked online and someone thought it could be related to a known issue in Chrome. Unfortunately I've tried Chrome/I.E 11 and Firefox and they all report the same issue. I am choosing the "Credentials stored securely in the report server" option.
Has anyone any idea to work around this?
This could be similar: SSRS Report Manager (2008R2) will not save Windows credential password in data source
Ultimately it was a browser/javascript issue I think..
There was nothing I could do to force the password to be saved using the form as it is designed.
The only work around I found was I had to switch focus between the three radio button options ("Credentials stored securely in the report", "windows integrated security "and "Credentials Not required") and then test the connection (it fails). Then I had to switch back to "Credentials stored securley in the report" and it worked.
Edit, this workaround worked on Firefox and Chrome (I haven't tried I.E)
and I had this problem too.
initially I thought I had my MYCOMPANY\reports account password wrong, and I even tested the whole thing with a different account, only to find out the same problem was happening -
"The password is not valid. Please retype the password".
then I used my own account with all its super powers and still the same error message, which then concluded that it was not related to AD or firewall.
what I did is, changed the settings to use Windows Integrated Security, tried it and applied even if it didn't work, then switched to some other option and again applied and saved.
ultimately I came back to Credentials stored securely in the report server, put the account and password, and it worked.
half a day wasted, but it worked.
I don't want anyone wasting their days with this, I am sure you can have a better option for that, given the opportunity.
hence the post here including the picture and all.
have a good day!!!
It is a browser issue. We try it in IE and worked.
Retyped the entire connectionstring.... No copy paste... and it worked. Its strange that when I put in the userid and password before and it showed the connection successful, but the credentials just wouldn't stick. Typed the connectionstring manually and it worked.
Gosh this thing has been bugging me for yonks! I even went so far as to create a replacement data source and then used some voodoo scripts to go and re-associate the RDL's (Which only worked during testing I might add, but gained plenty experience with the inner workings of the database structures).
Switching focus to "Credentials not required" authentication method and back worked for me though. And this works in IE (In my experience SSRS web manager is too finiky on non-Microsoft browsers).
I had the same issue even with IE, and finally got it resolved as it was a line return or space on the connection string. just re-typed it again and it saved the password correctly after that.
weird that "test connection" worked all the time but after apply, it showed invalid password if I retried the "test connection"
Used Edge and still same. Unchecked the box and let the windows account go in as SQL Account. Finally got the error in SQL Server logs as the login is windows and cannot be used as SQL.
Checked back the checkbox and it worked. I have no idea why such thing happened though.
Specifically for IE Edge or IE 11: Open the developers console (F12) and change the compatibility from Edge to IE 10.
It still works oddly, but switching radio buttons helps refresh it.
I was dealing with this same issue for a while today, and tried all of the suggestions above. None of them worked, but I did find a solution:
The service account I was using needed to be granted Allow Local Log On in Group Policy.
I started working for a company in the field service industry. We have a program and client database build in Access. As of right now, they are scheduling their service calls in a notebook. I am trying to get this company into this era by having a web-based scheduling software.
I have basic schooling networking but I am not a programmer nor do I know Access. I have learned how to split the database and create a multi-user environment and converted it to accdb from mdb to work with Access 2013 instead of 2003 in which it was written. These steps have greatly helped but I am not sure where to go from here.
My next step is the scheduling software but the company's greatest concern is the protection of their client database. Not from outside hackers but there is always a concern of employees selling our client list to our competitors. Also, at this time, employees do not have web access for this reason, which they will need.
Is there any way to keep the accdb file from being sent via email etc. or copied to external media? If I set up permissions through the OS, won't that make the client files uneditable (for lack of a better word) in Access? Like address/tele # changes or notes? I'm not even sure what to even search for help.
Thank in advance for your time
I understand that Access 2013 can be installed on a Server 2008 R2 or 2012 server. Put a password on the database. That should keep hackers out, and as far as keeping employees out of the data that they shoudn't be in, I know the navigation bar can be hidden, but it is unfortunately able to be viewed again by the F11 key. It would've been nice if MS could have made the navigation bar ability an easy option (yes or no), and make it modifyable in VBA....They may have. Keeping users out of raw data is something I have yet to figure out too....
I'm a novice at this stuff, but I was able to write code, and a login screen of my own so that users can have their own login ID, and a password (or phrase), and enable them to change their own password if they forget it, or if they just just to change it. You can make the navigation bar disappear by the VBA code: DoCmd.LockNavigationPane True...but unfortunately F11 can re-enable it.
Hope this helps....
Has anyone made any headway with coming up with a single sign on solution
with Domain access to date for Drupal 7? I've been looking closely at two old
modules, one no longer maintained (SSO for D6) and one still maintained (CAS). I've also read that SAML might be a key to unlocking this, but am uncertain.
Facebook's FBConnect might be another option too or another way could be integrating OpenID from what I've read, and experienced on StackOverflow's sub sites.
I know that OpenID can do this since we are logged into all of *Overflows sub sites at the same time using one login. The question is how does it cross DNS servers? Does it handshake with one half of a matching hash? I cannot find any documentation on this, so am at a loss.
So, are there any solutions that are known to date, or information on what to start
looking into? I think I've made a good point at the possibilities. I read this thread, Domain Access SSO but am uncertain to what version it pertains to (Drupal. DA, SSO or otherwise). It looks like the "Solution" is to create a master table set with users and permissions, then share those across the domains? How might this work if there are already multiple sites created under Domain Access? Would you clone and rebuild the entire installation, or would you need to start from scratch? It really raises more questions than answers. I contacted the author with no response, so the questions still stand.
Any opinions out there on the who what or why would be greatly appreciated, I just need a start point to get the ball rolling. Thanks everyone.
I'm the author of the Domain Access SSO article mentioned in the original question. I don't recall being contacted about it, but then again I recently learned that my "contact" page on bleen.net hasn't been working in a while... but anyway, here is a bit of info:
That post referred to Drupal 6, SSO Module 6.x-1.0-rc1, and Domain Access module 6.x-2.0 (I think). That solution basically revolves around creating two separate drupal installs, one the master and one the client (there can be multiple clients). Basically, what happens is the necessary user tables for all teh clients are pointed instead to the master. In doing so, the master becomes (essentially) a shell site that does nothing but hold and verify user data.
Hope that makes sense and/or helps... to be honest i havent looked at that code in a long while now.
SAML is a good option. Check this module to integrate it with drupal:
http://drupal.org/project/simplesamlphp_auth
If you need a demo with this plugin working check this.