Background
Microsoft SQL Server supports two different authentication methods: SQL Server authentication and Windows authentication. It's important to understand what the difference is to set up a SQL Server.
SQL Server authentication requires the SQL Server itself to maintain a database of usernames and passwords that are allowed access to the database. The SQL Server process is responsible for authenticating users by comparing the username and password (hash) against its own database. This method of logon does not allow single sign-on because it's not integrated with Windows, and the credentials you provide are completely unrelated to Windows account credentials (domain or local).
Windows authentication uses standard Windows authentication to access the database. SQL Server is still responsible for authorization ("Is Bob allowed in?"), but Windows now becomes responsible for authentication ("Is that really Bob?"). You cannot enter credentials when using Windows authentication; this is why the username and password input boxes are disabled in SQL Server Management Studio when you select Windows Authentication. Whichever user the client program is running as is the user that is authenticated to the SQL Server (you can override which user gets authenticated by using runas /netonly).
When a program attempts to access the SQL Server via Windows authentication, SQL Server asks Windows to authenticate the user. If it's a local user, Windows checks its local user database and returns yea or nay. If the account is a domain account and the computer is joined to any domain, Windows hands off to Active Directory for authentication. Active Directory will validate the user if it exists somewhere in the trusted forest (either the current domain, or in a domain which is trusted).
Your situation
Your copy of SQL Server is running on a non-domain computer. When you Remote Desktop into the computer, you are running programs as a local user. When you "Use Trusted Connection" (which really means "Use Windows authentication"), Windows knows who your local account is and validates it. SQL Server then allows you access.
When you run a program on a domain-joined computer and try to authenticate via Windows Authentication, you are trying to authenticate to a non-domain computer using a domain credential. The non-domain computer doesn't know how to authenticate via domain (by definition, it doesn't trust the domain), so the authentication fails.
Possible solutions
Use SQL Server authentication. Use a tool such as SQL Server Management Studio to create SQL Server logins for each user that needs access. You will not be able to use the "Use Trusted Connection" checkbox, and users will always need to enter their credentials for the SQL Server. Depending on what program is trying to access the SQL Server, it may provide some method for saving credentials in the registry or the users secure local storage so the user doesn't have to type them every time.
When you run SQL Server Management Studio locally, run it with the runas command as such:
runas /user:username /netonly "C:\Path\to\SSMS.exe"
This will allow you to use Windows Authentication because instead of passing your logged-in credentials, you'll pass credentials for the "username" account. This account should be one that exists on the target machine.
Join the computer running SQL Server to the domain and use. (You might also need to run the SQL Server as a domain account rather than a local account, but I'm not sure.) At that point, the SQL Server would be able to authenticate users using Active Directory, and "Use Trusted Connection" will work without entering any credentials. Of course, you'll still need to decide which users are authorized to access the database; you can use SQL Server Management Studio for this.
Promote the server running SQL Server to a domain controller of a brand new domain (of which it is the only member). Then you can create a trust between the two domains so the SQL Server computer can send credentials to the other domain for authentication, and Windows Authentication will work. No credentials need to be entered. You'll still need to authorize users in SQL Server Management Studio.
