I have setup Kerberos following below document
http://docs.hortonworks.com/HDPDocuments/Ambari-2.2.0.0/bk_Ambari_Security_Guide/content/ch_configuring_amb_hdp_for_kerberos.html
Further, I would like to configure ranger to sync all Kerberos principals to create ACLS. There is an option to sync users from AD but I don't see any option to sync from Kerberos. See options in image below
Can anyone please help with options for doing this. Thanks
I'm not sure I understand what exactly you want to import, but I assume you have AD and local cluster KDC which are configured with trusted relations and you want all your principles to be represented in Ranger by standalone user accounts. If you have trusted relations configured that means that your entire list of principles would consist of both local KDC and AD and they all would be valid for authentication. But in ranger you work not with the actual Kerberos principles, but with the usernames, which are obtained from auth_to_local configuration setting according to the mapping rules specified there.
If you are running LDAP sync, it will pass all matching principles through the collection of rules in this configuration property and will create the end user account with names obtained after execution of these rules. You can check the end results using:
hadoop org.apache.hadoop.security.HadoopKerberosName principle#domain.com
For local KDC it really does not make sense to pass the principles from KDC through this mapping stage as at the end they all will be mapped to local UNIX accounts. That is why you can just point your group and passwd files in UNIX sync source and you can assume that all your local Kerberos principles would be represented in the Ranger database with proper user accounts.
You can find some more details about the aspects of Kerberos mappings in this article
Related
OPC-UA can restrict access to nodes via the userRole mechanism specified in OPC-UA Part 3, ch. 4.8.3:
When a Client attempts to access a Node, the Server goes through the list of Roles granted to the Session and logically ORs the Permissions for the Role on the Node.
A session should map user identity (or the certificate of the client application) to a role. Thus, the server can grant or deny access to nodes.
standard mapping rules can be used to determine which Roles a Session has access to and, consequently, the Permissions that are granted to the Session.
Now, the configuration schema of the server applications allows defining a UserRoleDirectory where I would expect files that somehow link a user (or client application certificate) to a role.
Unfortunately, the UserRoleDirectory appears to be undocumented.
So, the questions are:
Will the OPC Foundation's .NET sample server indeed use files in UserRoleDirectory for said purpose ?
If so, what format take the files in said directory ?
If not so, how to tie users or client instances to roles ?
I’m automating a service that needs to access a kerberized resource.
Passwordless kinit with a keytab works fine. The resource is then connected
to using SASL.
Is there a way, maybe via GSSAPI or libkrb5, to ensure a TGT is present
whenever the resource is being accessed? Forking kinit before every access
seems the pragmatic thing to do. However, there’s an obvious race between the
time of TGT acquisition and its use to acquire a TGS that I’d like to avoid.
I imagine something like receiving an fd for authentication whose validity is
guaranteed until it is being closed by the user.
I’d prefer to stay away from heavy-duty solutions like sssd to auto-renew the
TGT.
The answer turns out to be providing the client keytab for libkrb5 in the
KRB5_CLIENT_KTNAME parameter:
If no existing tickets are available for the desired name, but the name
has an entry in the default client keytab, the krb5 mechanism will
acquire initial tickets for the name using the default client keytab.
From the MIT Kerberos docs.
The wiki also has a write-up of the implementation.
We are having problems with the authentication via SAML. All users who have an Active Directory user can log into Artifactory - which is not what I want.
I configured Artifactory to use two specific AD groups to allow users in, but we can't seem to get ADFS to filter those same groups
As far as I've understood Artifactory doesn't do anything with SAML authentication besides checking if ADFS says user is allowed or not allowed - is that correct?
Does anyone have experience with that kind of problem or an idea on how to solve this?
We are using Artifactory 5.2.0 at the moment
Never used Artifactory but assuming it's just a SAML SP ...
What is the format of the AD groups? What claim type? You may need a claims rule to transform the attribute to the required format.
ADFS can pass groups as Roles using "Token Groups - Unqualified Names".
Or you can set an access rule in ADFS so that access is denied if the user is not a member of a group.
I'm now kerberizing a cross-platform application with GSSAPI.
While I'm not clear about the difference between UPN and SPN.
The development environment is a Samba4 AD DC server on CentOS 6.4 with a Windows server 2008 R2 a member box in the domain, say EXAMPLE.COM (You may be curious why not use Win2008 as DC directly. And as I stated previously, the application is cross-platform, I'm now testing in this setting. The normal Win DC-Linux MEM setting works fine.).
I create a new user foobar:users to run the application.
When I use foobar#EXAMPLE.COM, i.e. the UPN, to authenticate the application against Kerberos, I keep receiving
Kerberos: Principal may not act as server ERROR
Following a thread on Samba maillist, I think I should create a service principal name say app/dc.example.com for the UPN with samba-tool
samba-tool spn add app/dc.example.com foobar
This time I will receive another error
Samba4 KDC - no such entry found in hdb
My question is what's the difference between a UPN and SPN?
By samba-tool spn list foobar, it says foobar has servicePrincipalName app/dc.example.com.
How could I associate a UPN with an SPN?
Thank you very much.
Simply put,
UPN: An entity performing client requests to some service. Entity may be human or machine. See here.
SPN: An entity processing requests for a specific service, e.g., HTTP, LDAP, SSH, etc. Machine only. See here.
A UPN retrieves a service ticket for an SPN to use that actual service.
If your samba-tool call your request samba to register the SPN app/dc.example.com to the UPN foobar. Since You have not provided the realm of the SPN and UPN, Samba will assume the default realm of the machine this call is performed from. In Windows terms, you mostly bind an SPN to a machine UPN. Which is always: <name>$#<REALM>. Note the dollar sign.
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