Kerberos authentication using mod_auth_kerb against ActiveDirectory and multiple Realms - active-directory

Our environment looks like this:
we've got a forest of ActiveDirectory servers that trust each other.
we've got a Linux Apache with mod_auth_kerb that authenticates against the "main" AD server.
For some combinations of clients & domains, we get the following error message:
krb5_get_init_creds_password() failed: KRB5 error code 68
Googling says this error:
is being returned by Active Directory because your users are
attempting to obtain a Kerberos TGT for a realm that
is not hosted on the server to which they are authenticating.
Is there a way to work around this?

You missed to add all necessary Realms/KDCs into your krb5.conf. GSSAPI cannot obtain a ticket for an unknown realm.
The above examplee works perfectly with gssapi in our forest env.
To ease the configuration work, you may configure your krb5.conf to query DNS to lookup the KDCs. This is what Windows does.

Related

Active Directory 2008R2 Serving Invalid TLS Certificate Over LDAP

I am creating a simple client to connect to the LDAP servers running on one of my windows 2008R2 Active Directory Domain Controllers.
I have successfully connected to the LDAP server over a non TLS connection. However, whenever I attempt to make a TLS connection, the handshake fails. After some digging, and downloading the certificate using the following command:
openssl s_client -connect <domain controller>:636
I found that the certificate being served from the LDAP server is invalid. I can see that the certificate is signed by our CA and my local system, that runs the application already has this trust established with the CA. However, It is missing all of the subject information in the certificate. The client application does not allow for this.
After speaking with the administrator, he indicated that the certificates being generated for the domain controller systems to serve TLS certificates over LDAP is automatic and is created by our internal Microsoft Certificate Server. He was not sure how to address this.
After numerous Google searches, I have come up pretty empty on how to resolve this. Is it something that is addressed on the certificate server? Is it something on the domain controller which is stripping the subject information? Is it some setting or configuration? Since, I do not have direct access to these systems I am at a loss on where to begin.
Any assistance would be appreciated.
Blindly trusting a certificate that is invalid is not an acceptable solution.
Ask your admin to export the root certificate for your environment (like, to a .cer file). Then you can use that file to add it as a trusted root certificate on the computer that needs to access it.
That's how we do it in our environment when we've needed to access an external domain over LDAPS.
Of course, that only works if the application accessing LDAPS uses the Windows certificate store. Some applications, like Java-based apps, don't, and you need to do it another way.
I was able to assist my Admin with updating the template the certificate server was using to include the subject and subject alternate name.
I found the following articles that helped determine the problem
https://blogs.msdn.microsoft.com/microsoftrservertigerteam/2017/04/10/step-by-step-guide-to-setup-ldaps-on-windows-server/
https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx
https://support.microsoft.com/en-us/help/931351/how-to-add-a-subject-alternative-name-to-a-secure-ldap-certificate
Ultimately going over each setting until we found the right solution that solved the problem of why the certificate server was sending and invalid certificate.

NT AUTHORITY\ANONYMOUS LOGON. failed with error:

I am setting up service broker between two servers. The environment I am implementing this does not have a domain.
The two SQL servers service run under "NETWORK SERVICE"
I am getting following error message
Service Broker login attempt by user 'NT AUTHORITY\ANONYMOUS LOGON.' failed with error: 'Connection handshake failed. The login 'NT AUTHORITY\ANONYMOUS LOGON' does not have CONNECT permission on the endpoint. State 84.'.
If I add NT AUTHORITY\ANONYMOUS LOGON to SQL server and grant the connect permission then everything works fine.
I am not sure granting the permission to NT AUTHORITY\ANONYMOUS LOGON is a good idea.
A little bit of Google research tells me, I need to configure SPN for Kerberos but I have no knowledge to do that.
Can you help, or direct me to a good article to refer please?
Configuration
SQL 2008 R2 and Windows 2008
I have come across this issue before also.
This guide got me through it. If you're not an AD admin you might need to get your server guys involved.
guide to fix double hop issue
I am setting up service broker between two servers. The environment I am implementing this does not have a domain.
Then you should use Certificate based authentication instead of Windows:
CREATE ENDPOINT [broker]
STATE = STARTED
AS TCP (LISTENER_PORT = 4022)
FOR SERVICE_BROKER (
AUTHENTICATION = CERTIFICATE [MyCertName]);
The setup is quite complex, as it involves exchanging certificates between the hosts, creating logins and users to map to the other host and granting endpoint connectivity. And you'll then need to also do the dialog security layer. You can read here How does Certificate based Authentication work, and this blog explains step by step how to do it: A simple secure dialog with transport certificates.
Note that even though the error message is about anonymous logon, this is not a Kerberos 'double-hop' issue (better known as constrained delegation).

Bind to domain failed: can't contact LDAP server

I'm trying to authenticate my users created in Active Directory through FreeRADIUS server but I get an Access-Reject and the debug shows the following:
bind to imendab.com:389 failed : can't contact LDAP server.
What should I do to fix this?
Looks like a network level issue rather than a problem with FreeRADIUS.
Make sure your LDAP server is running and listening on TCP port 389 (not just LDAPS on port 636). Make sure it is not firewalled. Check what's happening with tcpdump or similar packet trace, and try command-line LDAP tools on the RADIUS server to make sure that they can do a successful look up.
Note that usually to authenticate users against Active Directory you need to install Samba on the FreeRADIUS server and join it to the domain. You can't get password hashes out of AD over LDAP. The only exception is if you are using some kind of PAP method (e.g. plain PAP or EAP-TTLS/PAP).

LDAPS Connection from Local Active Directory Server to External Client

I am looking for a solution to my Active Directory problem.
Environment:
Attempting to authenticate users on an external Centos 6.4 website (outside our firewall) by connecting to Microsoft Active Directory which is located behind the firewall.
Currently, we use active directory within our firewall via the domain activedirectory.website.local and works fine. We are in the process of moving some of our sites to an externally hosted server so we need SSL. We have generated a self-signed ssl cert on the active directory server and have exported the ca.pem to the Centos server.
When I try to authenticate Active Directory through the terminal in the client Centos machine (located outside our firewall), I get an error:
TLS: hostname (firewall.website.com) does not match common name in
certificate (activedirectory.website.local)
This error occurs because:
I am trying to access active directory which is behind our firewall from a client computer from outside
the certificate says "Hey I'm generated from
activedirectory.website.local but you are asking for
firewall.website.com".
We talked to an SSL company about getting a commercial SSL for the .local server and they said they could sell us one for a year. Beyond that year they would not be able to extend the SSL due to some sort of regulation.
Due to the complexity of the network, I cannot change the domain name of activedirectory.website.local or firewall.website.com.
I'm sure someone has ran into this problem but I currently can't find any solutions on the web.
All I need from active directory is usernames and passwords for login authentication.
Thank you in advance!
First thing, (shitty ... caca boudin in french) can't you declare activedirectory.website.local with the right IP adress in /etc/hosts.
Another thing I see is to buy a certificate (or to create your own using your own CA) and install it on the Active-Directory service. Have a look to How to enable LDAP over SSL with a third-party certification authority.

IIS to SQL Server kerberos auth issues

We have a 3rd party product that allows some of our users to manipulate data in a database (on what we'll call SvrSQL) via a website on a separate server (SvrWeb).
On SvrWeb, we have a specific, non-default website setup for this application so instead of going to http://SvrWeb.company.com to get to the website we use http://application.company.com which resolves to SvrWeb and the host headers resolve to the correct website.
There is also a specific application pool set up for this site which uses an Active Directory account identity we'll call "company\SrvWeb_iis". We're setup to allow delegation on this account and to allow it to impersonate another login which we want it to do. (we want this account to pass along the AD credentials of the person signed into the website to SQL Server instead of a service account.
We also set up the SPNs for the SrvWeb_iis account via the following command:
setspn -A HTTP/SrvWeb.company.com SrvWeb_iis
The website pulls up, but the section of the website that makes the call to the database returns the message:
Cannot execute database query.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
I thought we had the SPN information set up correctly, but when I check the security event log on SrvWeb I see entries of my logging in, but it seems to be using NTLM and not kerberos:
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Any ideas or articles that cover this setup in detail would be extremely appreciated!
If it helps, we are using SQL Server 2005, and both the web and SQL servers are Windows 2003.
There are several possible reasons for kerberos failures which includes lack of SPN and duplicate SPN as well.
If SQL is running under custom account you would need to add SPN for SQL as well.
Also keep in mind, you should be adding SPN for the FQDN which is the host (A) entry in DNS and not a CNAME.
Check the value of NTAuthenticationProviders
http://support.microsoft.com/kb/215383
Try DelegConfig which would show what is missing if its SPN or something else.
http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1887

Resources