These the the options:
A. Users need VPN access.
B. User devices need to be scanned.
C. Multiple XenDesktop sites are in use in the environment.
D. Multiple authentication methods are used in the environment.
Answer should be B because without scanning user devices configuration policies can't be recognized.
Related
Assuming some web sites allow users to log in via Microsoft Login. Can we enforce that this users will only be able to use this setting only from within the Organization network in Intune? If yes, how? (Reference link)
Example: User is logging in to Bitbucket via Microsoft Login. He is unable to access Microsoft Login on his personal laptop. However, If he is using the Organization computer he should be able to access.
I believe this setting can be applied via IP Address? Or maybe there is another option.
We want to utilize TFS release management for our deployments. We have several environments (dev, qa, staging, prod). Each of them in separate AD forest. Build machine also resides in separate forest. No trust between them.
I set up target machines to accept CredSSP authentications for PS remoting. I was able to enter PS session on target machine from build machine. But no luck from TFS task 'Powershell on Target Machines'.
Here how my tasks looks in TFS:
TFS PS on Target Machines task
In logs:
2016-12-30T15:04:11.0279893Z System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server app.dev.local failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Negotiate authentication: An unknown security error occurred.
Is there any way to make TFS run PS on target machines that resides outside of build machine AD domain?
AD trust doesn't look like an option. And without proper PS remoting it doesn't look like release management can provide much value for us.
TL;DR;
No, you have two options.
Setup one way trust between your primary domain ans all of your sub domains so that your production domain credentials can be used on all of your sub domains.
use shadow accounts to allow cross domain authentication. These are local accounts with the same username and password across machines that allows auth. This is the official MSFT work around for non trust domain auth.
The long answer
Other than that, since you are well off the supported happy path, you would need to implement your own custom tasks that facilitated the cross domain authentication that you want. Should be a fairly simple task to implement your own tasks in PowerShell.
https://www.visualstudio.com/en-us/docs/integrate/extensions/develop/add-build-task
The reality is that there are only a few limited senarios that you need a "test AD" environment and it is never correct to have domains for Dev, QA, or Staging. AD is not designed that way and I have never seen it work for the benefit of the organisation or the development efforts. It is a product of over paranoid sysadmins and it is a lost cause.
The only reason to have a permanent additional domain is for your sysadmins to test their domain changes and configurations.
For software development projects that actively change AD, or require specific setups for testing, you would dynamically create your test domain along with the test machines required. That is how you create valid and repeatable tests against a Domain.
We have implemented Single Sign-On (SSO) using Kerberos in our production environment.
The configuration of our application is as below.
Operating System: Solaris10
Application Server: WebSphere7.0.0.11
Things are working fine for the Parent domain (MAIL.COM). But the users from child domains (like CO.MAIL.COM, BO.MAIL.COM..) are unable to login to the application.
We have the Kerberos Configuration file with the child domain details also. My doubt is "What are the changes needs to be done at the WAS console (realm related, domain related etc..)"
Thank you very much in advance..!!!
My build agents are not starting after I change the properties credentials to the domain account from the network service. I done this because the network service account cannot write to my drop folder.
Each time I add the network service to the drop folder share, it appears then disappears.
http://msdn.microsoft.com/en-us/library/bb778394.aspx I followed this but some steps are different, i have xp and it doesn't show the share tab so i go through security tab
So I guess I'm asking two questions here;
Agents are not starting after changing credentials.
Network service not able to write to the drop folder.
Thanks in advance
Yes, Network Service won't have permissions to write to a drop location. That's pretty standard. You need to be using a domain account.
The TFS Build Service will need to run as a domain user so it can write to the drop location.
The domain account for the build agent will need to be in the TFS Project Collection group for build service accounts (internal to TFS). I can't remember what it's actually called but you need to be a collection administrator to update it.
The domain account will also need some login as batch/service permissions but that should be done automatically when you reconfigure the service. Do you use the TFS Admin console to reconfigure the agent or did you just set the credentials on the service? (You should use the TFS Admin console).
I'm in the process of pulling a classic ASP app into Mvc2. I'll be deploying to an intranet and have been asked to enable support for Windows Authentication. The network I'll be deploying to has a few AD Domains and I'll only need to integrate with one in particular. Is it possible to use Windows Authentication and only allow authentication within a particular domain?
Along those same lines, it's not uncommon for a user to have an account in multiple domains (the account names themselves are typically different) - in the event a user logs in with an "unsupported" domain I'd like to kick them to a login form. Is this possible simply using Windows Auth or am I better off looking for an alternative?
Pro Tip:
Whatever you do don't implement Windows Authentication via IIS. Have a Forms Authentication page in your MVC app but use the LDAP authentication provider. This way you avoid the differences between how browsers implement Windows Authentication (only works well in IE and that's not a great reason).
The question "Is it possible to use Windows Authentication and only allow authentication within a particular domain?" has always has one and only one answer in my consulting experience: the answer is the permissions that you set for authenticated resources.
I've rarely found a deployment where there isn't some file, folder, server, COM+ object, SQL Role or database table that can't be "locked down" to only allow access by the subset of users you're targeting (e.g. "DOMAIN\Domain Users"):
Set permissions on the ASPX files (or the folder containing them, along with inheriting to the files) that are the "front door" (and optionally, all the others) so that they're only accessible to users in the "Domain Users" group for the allowed domain
restrict logon rights on the server that hosts the web site, so that only the Domain Users group have the appropriate rights - depending on the authentication provider used, this could be "allow logon locally" or "access this computer from the network"
set permissions at some layer of Component Services
restrict the SQL Server roles so that only "Domain Users" have the ability to read & execute the necessary database objects