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.
Related
Ok, I have followed the steps from https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-active-directory-authentication?view=sql-server-2017 to try and fix this issue as well as the SUSE/Redhat documentation for connecting to an AD server.
The servers are on the domain, I can log into the servers with my domain credentials but when I attempt to login to SQL as a domain user ( that is a Sysadmin on the SQL Server ) I get a the Login failed, the login is from an Untrusted domain and cannot be used with integrated authentication ( Error 18452) when attempting to use SSMS from a Windows box that works if I log in with a local account from it. When I log in as the domain user on the linux box I get the SSPI Provider: Server not found in Kerberos database and Cannot Generate SSPI context. Iif I use sqlcmd for a local user connecting to the FQDN of either server it connects fine. I haven't touched Linux from an Admin standpoint in over 15 years.
This is on both a SUSE 12 SP2 and a Redhat 7.5 server in our test environment. Not a big deal for me but our users are complaining because they now need a local account to log in for testing purposes instead of just using their domain accounts like the Windows side of things. Any help is greatly appreciated, most of what I am finding online just points me back to the Microsoft document and I have basically rebuilt the servers a couple times trying to add it to the domain before installing SQL and also after installing SQL to see if that made any difference, get the same error both ways.
i have this situation:
windows domain (+active directory) (2008),
linux machine (debian, redhat),
and windows work stations (xp, vista, 7).
users are connecting to linux from win PCs using ssh (putty). thah means, thay must type username and password on every login.
my goal is create SSO. users login to windows(and domain) on startup (by domain name+pass), and when they are connecting to linux machine no password is required. i need configure linux machine. and make same changes in putty-core application in worstations. biggest problem is configure linux.
need some help
maybe using kerberos??
thanks
Best would be to use Centrify DirectControl Express and Centrify Putty (both FREE). Centrify DirectControl Express allows you to quickly and easily join a non-Microsoft system to an Active Directory domain, thereby giving you the advantage of a single administrative tool to administer authentication across a heterogeneous computing environment.
Distribute Centrify-Enabled Putty to your windows users, to be able to SSO into the Linux machines.
For more information, refer to:
http://www.centrify.com/express/centrify-directcontrol-express.asp
http://www.centrify.com/express/centrify-enabled-open-source-tools.asp
I've got a little server plugging along, with IIS and some other stuff. Is it possible to allow a second user access to the IIS Manager, with the ability to create and edit sites, but keep the two accounts' sites separate?
I'm not worried about security between the two accounts, just separating the two account's sites for neatness and so that one user doesn't accidentally change something tied to the other account. At the moment I have two users part of the administrators group, and if I open IIS Manager with either one they both show all the sites.
A similar question has already been asked: how to create hidden web site on IIS
Can you please expand the answer of that thread?
Update 1
Connecting to sites remotely would allow the other sites to appear hidden as you would only see the connecting site. See: How to use Internet Information Services (IIS) 7 Manager to connect remotely to your website.
Update 0
As for hiding sites and other features, check out: What is administration.config for IIS?
One little known feature of IIS7 is that it's UI is entirely extensible! This means that anyone can write a C# assembly and get it displayed through the IIS Manager UI. The possibilities here are endless, anything from someone writing a new certificate management system, a website provisioning system, etc.
I haven't found documentation stating that the actual sites can be hidden but it sounds like it should be possible.
An Overview of Feature Delegation in IIS 7.0 may also provide the ability to hide sites.
Other links:
How do I hide 'non-delegated' features in IIS 7?
Based on your description, Microsoft's documentation on Configuring Permissions for IIS Manager Users and Windows Users (IIS 7) might prove helpful. For instance:
Allow an IIS Manager User Account to Connect to a Site or an Application (IIS 7)
Note: For IIS Manager users to connect to sites and applications for which you grant permission, you must configure the management service to accept connections from users who have IIS Manager credentials. For more information about how to configure the management service, see Configuring the Management Service in IIS 7.
Configuring Permissions for IIS Manager Users and Windows Users (IIS 7) - Emphasis added.
Use the IIS Manager Permissions feature to allow users to connect to sites and applications in IIS Manager. Remove a user account when you no longer want the user to configure delegated features in a site or an application.
Permitted users can configure delegated features in any sites or applications for which you grant them permission. Users can be either IIS Manager users, which are credentials created in IIS Manager by using the IIS Manager Users feature, or Windows users and groups on the local computer or on the domain to which the computer belongs.
We are looking to replace our normal Win2008 R2 IIS server with a Azure Cloud based solution. Our Current use scenario is something like this:
Server A
Hosts 7 Websites.
All Websites are Managed and Maintained with Visual Studio 2010. They are Web Projects, not Web Services. Each of the Sites has unique domain names. www.comanyA.com, www.companyB.com Intranet.companyB.com, etc. There are three sites that are SSL enabled and have Verisign Certificates.
The Sites consist of many asp, aspx and image files. We also create file content on demand (Excel Exports) that users can then click to download. We also make a Connection to a SQL Server for Back-end Data. We would need a Secure Connection to a SQL Azure DB and or an On-Premiss SQL Database (depending on when we move our SQL to SQL Azure).
I Would also need the same Security Permissions setup so all the users have the same permissions that they do for the Existing IIS Server. So I'd like Active Directly Integration.
I'd really rather not have a VM Image that is just running in the cloud. I don't want to have to maintain the OS level of stuff, (Updates, etc)
Is this something that Azure Compute can do for me?
Thanks!
This is not actually a single question. The only real question here that I see is
"Is this something that Azure Compute can do for me?"
And answer is - depends :) To very high degree, Azure compute might and will help you!
To solve challenge #1 (Multiple Websites / no ssl) - the easieast. Check this and that blog posts.
Challenge #2 (Connecting to SQL Azure / On-Premise SQL Server) - second easiest. SQL Azure still supports only SQL Server Authentication and it requires encrypted connection. As for connecting to On-Premise SQL Server, you can use Windows Azure Connect (and here). You can even domain-join your compute instances in the cloud.
Challenge #3 (Active Directory integration) - part of it described in Challenge #2 - domain join your roles! But you could also review the Windows Azure Access Control Service and its ADFS integration.
Challenge #4 (Multiple SSL Enabled sites behind same endpoint). Well, this is the trickiest! In Windows Azure everything lives behind a load balancer. So, you could generally define only one standard HTTPS (on port 443) endpoint. And that's it. Although, you could now have separate SSL certificate for each different SSL enabled site, this is not possible in Windows Azure. For this to work in Windows Azure, you need a Subject Alternative Name certificate (here, here and here are just some examples).
Hope that this helps!
I need to realize OPC server, on Windows XP. I download OPC library, and OPC client (application not library). I realize my OPC server, when i use client on my machine all runs normally. But when i connect from remote computer i do not see my server. I understand that the technology dkom potentially dangerous. I get this manual, and did everything on it, but nothing changed. I disable my windows firewall, add 135 port in windowds firewall exception. In dcomcnfg grants local and remote access to "anonymous" and "all" groups, grants local and remote launch & activation to "administrators" and "all" groups. And nothing changed, i did not give the right of my DCOM component because i thought the following: i get list of servers not work with them. In my microsoft network no domain and active directory, can i achieve the desired result in this case?
There's a number of things which can go wrong with OPC DA over DCOM. From the top of my head, you could try the following:
Check if OPCEnum service is running on the server computer. This service provides the list of OPC servers on to the potential clients. It's part of the OPC foundation redistributable.
Make sure that whatever dcomcnfg changes you applied, they are done both on the server and client computer.
If you're using only local users, try creating a dedicated user for OPC access on both server and client computer, e.g. call him "opc". Then grant all the rights to this user in "COM security" section of dcomcnfg. Run both the server and client as "opc". Make sure the local users authenticate as themselves (see "Security options" in local policies).
If all else fails, a workaround can be to deploy the server on the client computer, register it, then remove it. Worked for me once.
The most common error is DCOMs have not been configured properly. I find this guide very useful:
ftp://ftp.nist.gov/pub/mel/michalos/Software/Github/MTConnectSolutions/MtcOpcAgent/doc/DCOM_Config_Step_by_Step.pdf
Also this other guide gives you a big understanding of a Remote OPC DA:
http://www.kepware.com/Support_Center/SupportDocuments/Remote%20OPC%20DA%20-%20Quick%20Start%20Guide%20(DCOM).pdf
I had a similar problem when I tried to communicate with a remote OPC server in a different PC. Please pay attention to the point number 2 of the second guide (2.Users and Groups), make sure both PCs are logging in under the same user account with the same password.
2.1 Domains and Workgroups When working within a workgroup, each user will need to be created locally on each computer involved in the
connection. Furthermore, each user account must have the same password
in order for authentication to occur. A blank password is not valid in
most cases. Because changes may need to be made to the local security
policy on each computer, remote connectivity within a workgroup has
the potential to be the least secure connection. For more information,
refer to Local Security Policies. When working within a domain, local
users and groups are not required to be added to each computer. A
domain uses a central database that contains the user accounts and
security information. If working within a domain is preferred, a
network administrator may have to implement the changes. Mixing
domains and workgroups will require both computers to authenticate
with the lesser of the two options. This means that the domain
computer will require the same configuration as it would if it were on
a workgroup. Local user accounts must be added to the domain computer.