I have setup and installed sage 200c but my computer is a domain member and not a workgroup I have added the user into the sageadministrator group but yet I am still presented with this dialog. The same happens for the sageuser group I created.
My Admin group is called Sage200Administrators
And as you can see I am part of the domain group but my computer is also part of my company domain group is sage somehow getting confused.
This is my services account Sage200Services.
To User Accounts
You can see all my sage services are started ok
Related
I have a hybrid environment with on-prem exchange (almost done migrating) and O365 Email.
I create a new user in our on-prem AD via powershell. It syncs properly via AADConnect to our Azure environment and creates the O365 user and Exchange online (O365) email account. Using powershell I can correct proxy addresses and the msExchRecipient/Remote attributes.
The expected result is that I have an email account on both sides for the hybrid environment, with the on-prem Exchange srerver showing the Mailbox Type as "Office 365".
For one particular user, I ended up with email accounts in both on-prem and online exchange as expected. The user receives messages in their O365 account. However, messages that are trapped by our Mimecast server are not getting through. The Mailbox Type listed in on-prem is "User". This is messing up the mail routing for incoming messages from outside the domain.
Is there a way I can powershell my way out of this mess and somehow convert the mailbox type from "User" to "Office 365"? I can't migrate the user because the account already exists in O365. If I delete the O365 I would lose the email.
Should I have my powershell user creation script create the ad user, create the on-prem mailbox and also perform the migration? At least until we are fully migrated and out of our hybrid environment?
For this user, would it work to delete the AD and on-prem Exchange, and re-create both manually? How would I connect the on-prem to online exchange without losing the mail?
Any insight into this can of worms would be greatly appreciated.
One of the documents I referenced is this one about Recipient Type Values:
https://answers.microsoft.com/en-us/msoffice/forum/all/recipient-type-values/7c2620e5-9870-48ba-b5c2...
: Keith
I'am recently installed Azure DevOps Server 2019 in on-premises server.
However, i'am so confused : How i can block access from Domain Admin User Group : all memebers can access and manage all project and collection
I ask for idea to implement that
Thank you
EDIT :
I also try to delete the user admin group via TFS Console , but not work
azure devops server : revoke access from Domain Admin User
You could try to remove the Domain Admin User Group from its parent group, like Project Collection Administrators.
Check which group the domain admins group is a member of
In Team Foundation Server Administration Console tool, navigate to Group Membership page. Find out the Domain Admin User Group is under which groups, and remove:
Or you can move the member in that group:
Hope this helps.
It's work
I remove the AD domain admin group from the local group administrator , with this way ; only the specific user in the local group administrator , can access to all project
imagine there is a Powershell script running under the SYSTEM account on a Windows 10 machine and checks which domain user is currently logged on. No big deal.
Now: I want to check if this logged on user has administrator rights on this machine. Every check I could find so far is only looking at ".IsInRole([Security.Principal.WindowsBuiltInRole]::'Administrator')".
But this only checks if the user is a direct member of the local group "Administrators". But it is possible that within the local Administrators group there is a domain group, and the user is a member of this domain group instead. So he is admin, even if he is not a direct member of the Administrators group.
How can I check for both at the same time? I just want to check IF someone is admin, no matter where those admin rights come from. This check will also run under the SYSTEM account, not with the affected user account itself.
Any ideas?
If the Domain group is part of the local admins group, then by design, all users in that domain group are local admins and has all the rights and privileges that means. So, that code block would still apply.
You have to explicitly check for user rights and privileges assigned. There is no cmdlet for this built-in, so you have to code for it. To see your rights and privs, you can just use the good old whoami.exe...
whoami /priv
# Results
<#
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== ========
SeShutdownPrivilege Shut down the system Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
#>
... then compare that to the Windows Privilege list that are normally used for Administration actions.
Running this remotely as the logged-on user, cannot be done with PowerShell natively, it's a Windows Security boundary and thus, you'll need something like PSExec.exe from MS SysInternals to try that.
I had the Exchange Server Admins create an email account for me that I could use for EWS API testing (it was not an AD account). I used EWS api with no problem (using webCredentials). This app that uses EWS API consumes information from a mailbox and does stuff with it.
Now we had a service account created that will be used for a service on a server running the application. If I use the credentials for this service account (when I entered the credentials via WebCredentials) I get a 401 UnAuthorized.
I also used the EWSEditor and the same thing happens.
Any ideas about what I should be looking for or what to ask the AD/Exchange admins to check/change, etc?
I had the Exchange Server Admins create an email account for me that I could use for EWS API testing (it was not an AD account)
So this is technically incorrect, eg there is no such thing as an email account with Exchange you have an AD Account and the administrator then creates a Mailbox that is associated with that Active Directory Account (so be careful with what the admins are telling you if they are saying there is no AD Account).
Now we had a service account created that will be used for a service on a server running the application. If I use the credentials for this service account (when I entered the credentials via WebCredentials) I get a 401 UnAuthorized.
Is the service account mail enabled ? the easiest thing to do is ask them to Mail Enable (create a Mailbox) for the service account (if they don't want it to appear in the GAL then tell them to hide it). You should then be able to logon and at least access the Mailbox of the service account as you where with you previous code or the ewsEditor. To then access the Target Mailboxes you want to access you just need to be assigned rights (Eg add-MailboxPermissions and wait 15 minutes for application).
Windows Server 2016, ADFS, Certification Authority
I tried to create duplicate web server template, but it says that it's not an accessible. see below snap.
Now, My client is not technical, he provide me an account with most of the access, account is not an administrator, but I can assign many access to my self using AD Administrative service.
My only question is which access DO I need to provide to this account for creating duplicate web server certificate template?
In a multi-domain environment, I have had the same issue, if I did not select a domain controller in the root domain, respectively in the domain that hosts the CA. In my case, another domain was chosen by the console, because my computer for remote administration is in another domain (child domain).
Try the following:
Open "Certificate Template Console"
Right-click "Certificate Templates" in the left pane
Click "Connect to another writable domain controller ..."
Change the domain
click "Ok"
Try to duplicate once again. :)
I know this is an old thread, but thought I might add a fix that could help others. The account you use to login to the CA server should have Enterprise admin rights and should also be a member of local IIS_IUSRS group. If you have verified both, just logout and login to the box again and you should be able to duplicate a template.