I'm trying to run Microsoft Office Communicator 2007 on client which is not part of an NT Domain, but which has VPN access to my corporate network. When trying to authenticate, however, MOC just hangs forever. Is there some way to configure MOC so that it connects, even if the client machine is not a member of the NT Domain?
I have verified that a corporate machine can connect from the same remote location, so it's not a networking issue.
I figured this out: you need to have the domain's certificate installed as a Trusted Root on the client machine. So, it's doable: you just need to really really trust the server if it's a self-signed certificate.
Related
I have below setup in my office
2 AD servers
1) corp.mycompany.ney
2) mydevenv.net
Client machines
1) Windows-1
2) Linux-1
My Windows-1 machine is in doamin of mydevenv.net and I am also able to log with user-account of corp.mycompany.net domain
However I can't do it with Linux-1 machine.
My Linux-1 machine is in mydevenv.net domain and I am able to login with user-account of mydevenv.net but not with user-account of corp.mycompmany.net
Is there any way to do that?
Note - I used Powerbreaker Identity Services (PBIS) to joine Linux-1 machine to Domain
However I can't do it with Linux-1 machine.
What errors you're getting?
Do the domains have trust? Is the cross-domain trust setup as mutual?
What are the compatibility levels in both domains? If one for example is 2003 and another 2008, then Kerberos tickets validation would be one-way as for example 2008 has more encryption types that 2003 "Function Level" doesn't support/
Read more on this here:
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/understanding-active-directory-domain-services--ad-ds--functional-levels
You may also need to craft /etc/krb5.conf on your Linux server to describe domain controllers for both domains in realms and/or domain_realm sections.
I've got 2 machines:
A corporate desktop machine which is running Windows 7 SP1 which resides on the corporate domain and which I log into using a corporate domain account.
A personal laptop that I use when working from home via the Cisco VPN client but presently sits on my desk connected to the corporate WiFi (though I had it connected to the wire and on the same subnet as my desktop machine today also). This machine is not on the corporate domain; I log into this machine with a Microsoft Account.
I need to run Visual Studio 2013 Release Management Client from both machines. The machine on my desktop works fine when entering either the IP address or the URL into the Release Management Server URL entry field and everything hooks up and all is glorious.
On my Windows 10 laptop however, it's a different story. Every attempt to connect is met with the error:
The server specified could not be reached. Please ensure the
information that is entered is valid (please contact your Release
Management administrator for assistance). <-- I'm the admin
I can ping the machine both with IP address and with hostname, ruling out DNS issues. Both client machines are on the same subnet. Both machines are using the same outbound port.
Checking the event log I see a bunch of Message: The remote server returned an error: (401) Unauthorized.
Checking with Fiddler, on my desktop machine, I can walk through the handshake of each of the stages of startup and all is good. But in Fiddler on my laptop I see 3 401 Unauthorized errors before Release Management Client bombs and returns the rather uninformative message I posted above.
I've attempted to create a shadow account on my laptop and do the Shift-Right Click-Run As Different User dance, but I must be missing something because I can't get this to run.
I've talked to the network administrator who suggests that I should be able to access all of the same resources from both machines and that it must be a Release Management issue.
Is this an incompatibility between VS2013 Release Management & Windows 10 or something else? Has anyone else had this issue and overcome it? I have access to be able to administer the Release Management environment if there's changes that need to be made there and I'm a local administrator on both machines. I'm not however a domain administrator if changes need to be made there.
I would bet you simply have a security issue as the workstation is not domain-joined and the WPF client is using Integrated Authentication.
Often creating a local "shadow" user with same username and password, and running the client app under that account (run as) works.
Another option is to join the workstation to the domain or use a domain-joined VM.
After fully investigating the situation, it appears to have been a combination of factors. I am posting a response because this appears to be a relatively common problem:
The workstation was sending an unexpected credential to the server. To get around this, you have to configure the user account on the server without a domain in the username and create a shadow account on your local machine. When running the client application, you must either log into this shadow account on the local machine or you must SHIFT+RIGHT CLICK and choose "Run as" entering your local shadow credentials. This will then pass the shadow account to the server which will now authenticate without referencing the domain. OR
Create a user account on the server that matches the credentials on your local machine including MACHINENAME\LocalUsername
There appeared to be a network issue when attempting to connect to the Release Management Server from the non-domain machine when connected inside the network. When connecting via the VPN from home, this situation was resolved, but only after we'd ensured the account and local machine accounts were correctly configured. The domain connected machine always connected properly.
Our setup:
Server1: Sharepoint is running
Server2: SQL Server is running
Our Sharepoint 2010 was working perfectly fine and then suddenly the website went down and when I tried accessing Central Admin I found the following issue in the error log:
System.Data.SqlClient.SqlException: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
I read on internet that this happens when the server loses trust with the domain so I removed the Sharepoint server from the domain and then added it back. Result: Same. No solution.
I also tried other methods where people have asked for updating the host file but that too did not work.
In order to check if the connection is working or not...i did UDL test where I created a file networkcheck.udl on Sharepoint server machine (Server1) and tried running with Windows authentication and tried to connect with DB server (Server2).
Result: Connection successful.
Can anyone please guide regarding this. I don't know why Sharepoint won't connect even after udl test being successful.
Because I don't know enough about your farm as a whole you may be best looking at this as a issue unrelated to SharePoint.
Are bother the servers in the same domain?
Like Dennis said have any of the passwords Expired/Changed?
Do you have anything other than localhost pointing to 127.0.0.1 in your Hosts file?
Check this thread and think of the problem away from SharePoint
SQL Server 2008 Windows Auth Login Error: The login is from an untrusted domain
Thanks
Truez
One of the possibilities of this error could be that the account from which the Server has been installed has been removed from the domain or the account password has been changed.
We're currently having an issue where when someone tries to access our TFS server via Visual Studio, they're hit with an Error TF30063: You are not authorized to access
The TFS server is on a different domain to what the client machines trying to connect are on. There is a domain trust between the two and other shared resources work fine.
I have found that it does temporarily work if you open up an RDP (remote) connection to the server in the background and login using your local domain credentials. After leaving your remote session connected and trying to connect again via Visual Studio, it works fine.
Another thing to point out which indeed would be related is, looking at the Administrator group permissions on the TFS server it does not resolve the usernames of the users in the list until they initiate an RDP connection atleast once after a reboot has occurred. Instead it shows their SID.
Things I’ve tried so far are;
Adding Windows and Generic Credentials to the Credential Manager on the TFS server for their domain accounts. I thought it might be an issue with the server not caching their credentials which meant an RDP connection needed to exist each time.
Enabling Windows Authentication in IIS
Adding the path to Trusted Sites in Internet Options
Enabling Network access: Allow anonymous SID/Name translation in Group Policy for the machine.
Creating a registry key under HKLM\System\CurrentControlSet\Control\Lsa called TurnOffAnonymouseBlock and set to 1 which essential is what the GP above does.
None of these however have seemed to fix the issue.
Any suggestions would be greatly appreciated!
If there is a domain trust in place, you should just add the users AD account that they log into their machine with, as a valid user in TFS.
For example, if TFS is in Domain A, and the user's laptop is in domain B (and they login to their laptop with a domain B account), then you need to ensure that Domain A trusts Domain B (either a two-way trust, or one way with A trusting B). Then you just need to make sure to add the user's domain B account as a TFS Contributor for example, and they should be able to access TFS without doing anything special.
A client has asked for additional security for a web app which would allow only company owned and approved tablet computers (brand not yet known) to connect to a PHP web app.
The app will be un/pw protected but the company would like to prevent all access except via the tablets.
MAC addresses would be great for this but these will be used in the field and use a myFi portable wifi to connect to the server so the MAC address will not be available.
Can anyone point me to a sound method for this secondary validation?
Your best solution here would be to deploy mutually-authenticated SSL between your client tablets and your server. You can use self-signed certificates here so you don't need to buy any from a CA. This will ensure that your server only accepts requests from tablets that have the client-side certificate (configure your server to only accept the self-signed client certificates deployed on your tablets for client authentication).