Purpose of mapuser in ktpass - kerberos

I just want to find out what the purpose of mapping a user to a service using ktpass is. For example I am on Windows and I run ktpass like this:
ktpass -out <keytab location> -princ <host/domain.com> -mapUser useraccount#domain.com -mapOp add .........
When we map a user to the -princ does it mean that only "useraccount" can authenticate the service? And how do we use the -add and -set option? what is the difference?
My issue is this: I have many users wanting to use a service I have, and authenticate through kerberos (JASS Krb5LoginModule) but I don't want to specify many user principal names in the jaas.config file. So I am thinking of using SPN instead, and mapping the users.

Option -mapUser useraccount#domain.com tells ktpass to store 'principal' in attribute userPrincipalName of this user in Active Directory, so that Active Directory would be able to find it, when clients ask for KerberosServiceTicket for this 'principal' and issue such ticket.
-mapUser specifies name of a user, which represents your service in Active Directory.
Using ktpass you're doing two things: generating keytab for your service (so that it could open Kerberos tickets received from clients, i.e. authenticate them), and registering principal in Active Directory (so that clients could get tickets for service at all).
In jaas.config file you specify just one principal name (for service), not for the clients. Once user logs into Active Directory domain, he/she has right to get service ticket for your service.

Related

Use of keytabs and service principals

I'm struggling with is the use of keytabs and service principals. I always thought keytabs were a combination of an encrypted password and Kerberos principal. For services or hosts, however there are no actual passwords unless I'm missing something.
In my case, I'm trying to use config Apache Kafka to run with Kerberos to Active Directory. Specifically I joined AD and created the SPN using the adcli command. I can create a keytab using the ktutil command for the service principal. However it prompts me for the password. I've tested using a service account password and the root password with no luck.
Any suggestions would be greatly appreciated.
I'm struggling with is the use of keytabs and service principals. I always thought keytabs were a combination of an encrypted password and Kerberos principal. For services or hosts, however there are no actual passwords unless I'm missing something.
There can be a password. Windows AD member hosts indeed have a "machine password" that is stored in the Windows LSA secrets storage – which is why they don't need a keytab. Similarly, "service" accounts1 in AD are just user accounts that have a (hopefully!) randomized password.
But to Kerberos, the original password doesn't actually matter. Only the derived key is what gets used. This means the key doesn't have to be derived from a password, and indeed in "traditional" MIT/Heimdal Kerberos the whole key is randomly-generated for host or service principals.
(Note that I said "derived", not "encrypted". For password inputs, the keys are the result of a one-way hash. Kerberos uses PBKDF2 for AES keys, while RC4-HMAC keys are "NTLM hashes".)
1 Oh, and don't try to re-use the "machine" account created via AD join for Kafka. Create a separate "user" account and assign it the SPN.
In my case, I'm trying to use config Apache Kafka to run with Kerberos to Active Directory. Specifically I joined AD and created the SPN using the adcli command. I can create a keytab using the ktutil command for the service principal. However it prompts me for the password. I've tested using a service account password and the root password with no luck.
ktutil could work, but there are two big issues to note:
First, when deriving the AES keys (using PBKDF2), you must use the correct salt. In Kerberos it can often be derived from the principal name, but not always; e.g. a renamed account will retain its original pre-rename salt. And in AD, all SPNs assigned to a custom user account will use that user's main account name as the salt, as the KDC knows about this relationship – but ktutil doesn't!
So you should always use the -f option to addent, which actually asks the KDC for the correct salt (just like kinit also would).
(RC4-HMAC keys use an NTLM hash, which is not salted. One of the reasons RC4-HMAC should become obsolete as soon as possible, and why you should also manually check whether the service account is indeed flagged for AES support.)
Second, you have to add keys for the same enctypes (algorithms) that the KDC thinks the service will support.
Fresh AD accounts are only considered to support arcfour-hmac (obsolete-ish), but I believe adcli sets the correct flags to indicate support for aes256 and aes128 as well. This means you need to repeat ktutil's addent 3 times, with different -e options.
ktutil: addent -password -p kafka/foo.example.tld#EXAMPLE.TLD -k 1 -e aes256-cts -f
ktutil: addent -password -p kafka/foo.example.tld#EXAMPLE.TLD -k 1 -e aes128-cts -f
ktutil: addent -password -p kafka/foo.example.tld#EXAMPLE.TLD -k 1 -e arcfour-hmac -f
ktutil: wkt kafka.keytab
It might be easier to find a Windows host with RSAT installed, which has ktpass.exe that'll create a keytab for you.
(And unfortunately, samba-tool domain exportkeytab is not an option, as it assumes it'll be run directly on a Samba-based AD DC and wants to access the raw database and extract the current keys, instead of doing the normal thing and going via LDAP.)

the web server certificate template could not be duplicated. Access Is denied

Windows Server 2016, ADFS, Certification Authority
I tried to create duplicate web server template, but it says that it's not an accessible. see below snap.
Now, My client is not technical, he provide me an account with most of the access, account is not an administrator, but I can assign many access to my self using AD Administrative service.
My only question is which access DO I need to provide to this account for creating duplicate web server certificate template?
In a multi-domain environment, I have had the same issue, if I did not select a domain controller in the root domain, respectively in the domain that hosts the CA. In my case, another domain was chosen by the console, because my computer for remote administration is in another domain (child domain).
Try the following:
Open "Certificate Template Console"
Right-click "Certificate Templates" in the left pane
Click "Connect to another writable domain controller ..."
Change the domain
click "Ok"
Try to duplicate once again. :)
I know this is an old thread, but thought I might add a fix that could help others. The account you use to login to the CA server should have Enterprise admin rights and should also be a member of local IIS_IUSRS group. If you have verified both, just logout and login to the box again and you should be able to duplicate a template.

Kentico sync and AD authentication

My target site needs AD auth to browse and use the admin portal. All is fine there. This means syncing to this server via username and password authentication doesn't work. Does this mean i need to enable x.509 authentication?
If you mean using the Staging Module, the staging module's "Username and password" really is not linked to the actual CMS Users. You can put whatever Username and Password on the Destination server, and connect to it from the Source.
x.509 is also fine.
Tell me if you aren't talking about the Staging Module though.
You may need to do 1 of 2 things:
Enable mixed mode authentication. Yes the overall authentication doesn't need to use a physical cms_user user but since you have AD Authentication enabled, anytime another user or service tries to access a system page it may require them to log in.
Create a web.config location node in your /CMSPages/Staging/web.config file that excludes anyone or everyone to access a the SyncServer.asmx page within there.
Otherwise configure the x.509 certificate setup.

How to authorize clients in non-default directory to KeyVault

I created a KeyVault in my Azure subscription and a client application in one of my Azure AD directories. However, the client application is not registered in the default directory of the subscription.
When I run the following PowerShell cmdlet, it tries to look up the service principal in the default directory of the subscription and fails to find it.
PS > Set-AzureKeyVaultAccessPolicy -VaultName <vaultname>
-ServicePrincipalName <principal guid> -PermissionsToSecrets Get
I found an article describing how to change the default directory for a subscription in the management portal, but was wondering how to do the same using PowerShell.
The 'Select-AzureSubscription' cmdlet does not seem to support changing the default directory.
Nor does the 'Set-AzureKeyVaultAccessPolicy' support a parameter to indicate in which directory it should look.
Key Vault can only authorize applications (clients) registered in the directory associated with the Azure subscription, and the only way (currently) to change the 'home' directory associated with a subscription is through the Azure management portal.
I would imagine this is as designed behaviour, and can't imagine how / why it would change.
An Azure subscription has an Azure Active Directory attached to it, this is the directory it will use to authenticate against whenever someone tries to access resources.
While you can create trusts to other Active Directories simply creating an new AAD does not automatically enable that domain to be trusted by Azure.
Key Vault is designed to only be accessible to authenticated users, it is designed to provide secure data to those users. Since there is no authentication mechanism between the multiple directories you have created, there is no mechanism for Key Vault to determine who those directories belong to.
Key Vault needs to resolve a service principle through the Active Directory attached to the subscription it is running under (whether that is directly through that directory, or through another domain that it trusts). Anything else would create additional attack vectors and considerably weaken the product.

Kerberos: difference between UPN and SPN

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.