I have configured kerberos on linux machine to serve as a single point for user authorisation management. now I want to restrict few users from logging into specific linux hosts. for example.
I have user admin, developer and tester. and I have 3 linux client machine which are running with centos7., machine1, machine2 and machine3.
user admin can login to both 3 client machine.
user developer can login to client machine1 and machine2.
user tester can only login to client machine3.
need guidance to configure the above policy.
Related
I am new to the xmpp server and still learning. I have chosen ejabberd server for my chat application. I have started the server but can't able to access the web admin interface. as you can see the ejabberd#localhost is already running. configuration
I started the server and it was supposed to show web admin interface but unfortunately it is not showing. I don't know what am i doing wrong.
With that configuration, the webadmin page is in
http://localhost:5280/admin/
When the browser asks login credentials, provide the JID of some account in ejabberd with admin rights (it may be vinayak#localhost or something like that) and its password.
This means that you should have already registered an account in ejabberd, and grant it admin rights in ejabberd.yml configuration file, see https://docs.ejabberd.im/admin/installation/#administration-account
Can someone please help me with the following
Assume I have an AD Domain and a 'standalone Linux host' which is not joined to the AD domain and there is no trust relationship in place between the AD and Linux of any kind.
Next I have a Kerberos aware application running on the Linux Server (WEB Server for example or other app) which is .
In order to an AD user to authenticate to the Linux hosted WEB/App using a KeyTab file
(created in Windows and setup on Linux). Does the Linux host need to be AD-Joined, in order to keyTab (single sign one) authentication to work?
Meaning if the Linux server was never joined to any domain of any kind (standalone), Would I still be able to user a KeyTab file to authenticate a user coming in from an AD Domain?
Thanks all
Charlie
My goal is to create a HTTPS REST service that (in concept) allows a machine account to authenticate using the less- than documented machine$ account.
I have a REST endpoint for an AD connected intranet application. Right now IIS simply echoes the thread CurrentPrincipal when I navigate using Internet Explorer.
Now I'm using the HTTPClient , using default authentication, running a my username, and that also works.
My new goal is to send the AD Connected machineAccount (that ends in the dollar sign $) so that IIS responds with the kerberos name Domain\TestServer$
I attempted creating a Windows Desktop service, running as NetworkService or LocalSystem, and I'm not clear if HttpClientHandler.UseDefaultCredentials is sufficient for running in this (unusual) context or if a different approach is needed to authenticate using the machine account.
Is a PInvoke needed? Is there anything in logonuser32 that needs to be done?
We have a client/server based application that is developed internally. Clients and server communicate over a TCP/IP connection with an application-specific protocol. The clients run on Windows and the server runs on Linux. All machines are in the same Active Directory/Kerberos domain/realm.
Currently, the user enters a username and password when they start the application. The server checks the username and password (authentication). Based on the username, the server also determines access to resources (authorization).
We want to add Single Sign-On (SSO) capabilities to the application. That is, we do not want the user to enter a username and password but we want to automatically logon as the current Windows user.
Of course, determining the current Windows user has to be done securely.
I have come up with the following setup:
I use SSPI (Negotiate) on Windows and GSSAPI on Linux.
When the client connects to the server, it uses AcquireCredentialsHandle (Negotiate) to get the credentials of the current Windows user.
The client uses InitializeSecurityContext (Negotiate) to generate a token based on these credentials.
The client sends the token to the server.
The server uses gss_acquire_cred() to get the credentials of the service. These are stored in a .keytab file.
The server receives the token from the client.
The server uses gss_accept_sec_context() to process the token. This call also returns the "source name", that is the current Windows user of the client.
The server uses the "source name" as the username: the server performs no additional authentication. The server still performs authorization.
This works but I do have some questions:
Is this secure? It should not be possible for the client to specify any other username than the Windows user of the client process. If a user has the credentials to create a process as another user (either legally or illegally) than this is allowed.
Should I perform additional checks to verify the username?
Are there alternative ways to achieve SSO in this setup? What are their pros and cons?
What you've described here is the correct way to authenticate the user. You should not have to worry about the user specifying a different name; that's what Kerberos takes care of for you.
If the client is able to obtain a service ticket, then they must have been able to authenticate against the KDC (Active Directory). The KDC creates a service ticket that includes the user's name, and encrypts it with the service's secret key.
The client would not be able to create a ticket for the server with a fake name, because it doesn't have the necessary key to encrypt the ticket.
Of course, this all assumes that you've set everything up correctly; the client should not have access to the service's keytab file for example, and the service should not have any principals in its key tab except its own.
There's a pretty detailed explanation of how it works here.
I just read the article here: http://www.asp.net/aspnet/overview/developing-apps-with-windows-azure/building-real-world-cloud-apps-with-windows-azure/single-sign-on
I have just finished building an app that can authenticate users via WAAD, or via a local installation of ADFS on their corporate network (configuration point allows them to select one or the other).
The app will be hosted in Azure. Can someone tell me if it is possible for users who are on their corporate network to login to this Azure app WITHOUT entering their credentials?
Here is the flow:
user navigates to the cloud app
FAM detects they aren't authenticated, and redirects the browser to their ADFS server on the corporate network
ADFS server replies with 401 challenge (I assume this is what's happening)
user sees a user name/password box, and enters in credentials
user is redirected back to the cloud app with a token containing their claims
I don't understand why #4 is required if the user is already on their corporate network. Shouldn't ADFS use Windows Authentication here so they don't have to enter their password? Is there a way to configure ADFS to do this?
Thank you!
This can be accomplished by adding the Url of the ADFS endpoint to the local intranet or trusted sites of Internet Explorer. By default Internet Explorer will pass in the Windows credentials to sites in those two groups. If that doesn't work, you would have to double check that setting hasn't been modified.