I have successfully run Active Directory and Squid Proxy (v.2.7) on our network. I wanted to give uniformed access to users on different departments so I wanted to make use of Kerberos for Squid to know what permission it should give to users knowing the Group it is assigned to the AD.
On the process of installing Kerberos inside the Squid Proxy Server (VM), I am stuck with an error when I tried to run msktutil. See below.
Can someone please explain to me what is the issue all about? And how do I start doing troubleshooting. I have research this matter in Google but getting vague responses.
root#debian:~# msktutil -c -b "CN-COMPUTERS" -s HTTP/debian.internal.local -k /etc/squid/PROXY.keytab --computer-name SQUIDPROXY --upn HTTP/debian.internal.local --server internal.servers.com.com --verbose
-- init_password: Wiping the computer password structure
-- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-oyfv6j
-- reload: Reloading Kerberos Context
-- finalize_exec: SAM Account Name is: SQUIDPROXY$
-- try_machine_keytab_princ: Trying to authenticate for SQUIDPROXY$ from local keytab...
-- try_machine_keytab_princ: Error: krb5_get_init_creds_keytab failed (Client not found in Kerberos database)
-- try_machine_keytab_princ: Authentication with keytab failed
-- try_machine_keytab_princ: Trying to authenticate for host/debian.internal from local keytab...
-- try_machine_keytab_princ: Error: krb5_get_init_creds_keytab failed (Client not found in Kerberos database)
-- try_machine_keytab_princ: Authentication with keytab failed
-- try_machine_password: Trying to authenticate for SQUIDPROXY$ with password.
-- try_machine_password: Error: krb5_get_init_creds_keytab failed (Client not found in Kerberos database)
-- try_machine_password: Authentication with password failed
-- try_user_creds: Checking if default ticket cache has tickets...
-- finalize_exec: Authenticated using method 4
-- ldap_connect: Connecting to LDAP server: internal.servers.com.com try_tls=YES
-- ldap_connect: Connecting to LDAP server: internal.servers.com.com try_tls=NO
SASL/GSSAPI authentication started
Error: ldap_sasl_interactive_bind_s failed (Local error)
Error: ldap_connect failed
--> Is your kerberos ticket expired? You might try re-"kinit"ing.
-- ~KRB5Context: Destroying Kerberos Context
Also, this might give you more information what the problem is.
root#debian:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user#INTERNAL.SERVERS.COM.COM
Valid starting Expires Service principal
18/12/2014 00:23 18/12/2014 10:23 krbtgt/INTERNAL.SERVERS.COM.COM#INTERNAL.SERVERS.COM.COM
renew until 19/12/2014 00:23
After a long research. I found 2 points of failure for getting this error.
On the host file, the realm was specified but kerberos was not about to resolve it.
Adding another value (dc1.myexchange.com) of the realm (myexchange.com) seem to enable the connection between the AD and Squid Server (where kerberos is running).
Assumption. Since I was able to kinit I assumed that the AD can see the query from the squid server. So, I was not able to check the DNS between the two servers.
Related
Need to connect SFDC Sandbox to Azure Data Factory but getting the following error when setting up the linked service and testing the connection:
Error code9603
DetailsERROR [HY000] [Microsoft][Salesforce] (80) Unknown error received from SOAP response, potentially a problem with user privileges. ERROR [HY000] [Microsoft][Salesforce] (80) Unknown error received from SOAP response, potentially a problem with user privileges. Activity ID: ba13abc8-5490-4d7a-afd4-cf4d5ddf5e86.
I confirm the security token for this account has been reset, the SFDC account has been assigned a profile of privileges where 'API enabled' is selected. I have also tried to pass the credentials through Azure Key Vault when setting up the linked account in Data Factory.
Are there any other permissions in Salesforce required so that we can check if everything is selected?
How can we find out what this unknown SOAP error is?
As API Enable is checked, there must be a problem with user access or organization access.
Follow the steps below:
Goto Setup -> Permission sets -> Check the name -> Goto systems permissions -> click on manage assignments
Check whether the integration user is added to those permissions or not. If not, add now.
If the integration is not possible, then mostly your organization or the account using for the operation is not having the API access.
Check whether the organization or the account which is being used for this operation is having API access or not, by visiting Organization Edition
My SNOWFLAKE database is SSO login enabled and the SSO connectivity works perfectly fine when I connect through my chrome browser.
When I try to connect to SNOWFLAKE database using DBeaver (external browser) I get the below error .
NOTE : I can confirm that I am able to see the identity verification (through explorer browser) page and the identity has also been verified. I feel the issue happens when the explorer browser confirms the identity verification back to DBeaver.
Can anyone please help ?
The above error is a generic message and could be seen due to misconfigurations either at the identity provider end or at the service provider end.
It is recommended to verify the configurations for your identity provider and make sure all the steps are performed correctly.
Below could be the common reasons for this error, However, there might be other improper configs as well which could lead to a similar error message.
a. Mismatch in user configuration details at Idp(Identity provider) and Snowflake.
b. SSO certificates are incorrect.
Solution
a. Username configured at the Identity provider end should match with the login_name at snowflake end for that user. For instance, If the SAML response shows NameID as abc#xyz.com. Then login_name configured at Snowflake end should be same as abc#xyz.com
SAML response snippet:
abc#xyz.com
Set the login_name same as the NameID configured at the identity provider side.
alter user set login_name='abc#xyz.com';
b. SSO certificate configured at Snowflake end should match with the certificate configured at the identity provider end.
Note:
The certificate value contains a number of new lines. Remove the new lines, forming a certificate value with a single line.
If the above suggestions did not help then please check the error codes for the failed login attempt in Snowflake Information Schema using the below query. And check the reason for that error code here. The below query retrieve up to 100 login events of every user your current role is allowed to monitor in the last hour and you can modify it appropriately.
select * from table(information_schema.login_history(dateadd('hours',-1,current_timestamp()),current_timestamp())) order by event_time
I'm working on configuring SSO in obiee 11.1.1.7.14, where in which I'm facing issue in the step while configuring krb5.conf and executing the kinit command.
few notes regarding the Active Directory
we have more than one domain controller and to balance the request we are maintaing the load balancer with port 3269.
And the integration between obiee and MSAD is successfully done with the load balancer name as host and port as 3269.
and few certificates have been added in the demotrust.jks and to the ovd store and SSL is enabled in the new provider.
Keytab file generated and placed in obiee domain home, krb5.conf and krb5Login.conf file modified accordingly.
I have created the keytab file and placed it in the obiee domain home, then modified the krb5.conf by keeping kdc as the one of the ip address of the domain controller and admin-server as the name of the domain controller. And while executing the
kinit -V -k -t /location/keytabfile.keytab HTTP/obiee_host_name
i have got and error "kinit(v5): Client not found in Kerberos database while getting initial credentials" . Please share your ideas/suggestions to solve this issue.
thanks in advance
We have a Active Directory server where 2 domain controllers are used for it. And a load balancer with port 3269 is used to connect to the Active directory from OBIEE and similar connections can be used in the krb5.conf and where ever required.
And consider the base domain as DOM1 and all our groups are created under sub-domain SUBDOM. So the SPN is set at the SUBDOM.DOM1.COM.
Here are the few suggestions we have followed to integrate AD with OBIEE and Solved the most of the kinit issues
Instead of specifying the principal name with the absolute path, just mention with the accout_name#FullyQualifiedDomainName.
Changes in KRB5.conf
Since the attribute "crypto" is specified as "all" while creating keytab and setting the SPN, all the encryption types which is present in the keytab file as to be mentioned in the krb5.conf (default_tkt_enctypes and default_tgs_enctypes).
Have included the primary domain controller IP address for the attribute kdc in [realms] section, this will be same as Michael-O specified in point 2.
in [domain_realm] of krb5.conf keep as .subdom.dom1.com=DOM1.COM.
include the host name of load balancer name in the admin_server attribute of [realms] section in krb5.conf
Once all the above changes are done, most of the kinit issues would be solved and the kinit command will be executed successfully by creating the initial ticket in the desired directory.
First of all, this is serverfault.
3269 is not Kerberos, this is SSL-backed global catalog. Pure LDAP not Kerberos. Not interesting here.
Do not put KDC IP addresses in the krb5.conf but rather rely on DNS SRV records just like Windows does.
You cannot kinit with a SPN. kinit expects a UPN (from AD) from the keytab. Something like accountname$#EXAMPLE.COM if this is a machine account. Always remember, a SPN is always bound to some account, whether machine or functional.
I am trying to authenticate my apache against kerberos.
I have two websites running on the same server, and I use VirtualHosts to achieve that and set DNS to have two names for this server to have a separate one for each website.
I added recently a new ldap/Kerberos server and trying to connect one of my websites to it, but I failed to get the correct credentials to get it works.
After adding some debugs, I found that apache looks for HTTP/fist-server-name instead of HTTP/second-server-name and for that reason couldn't find the correct principal in Kerberos database and keytab.
How to force apache to do its check against the second server name to validate the call from my second website? It looks adding ServerName attribute in apache configuration is not enough to do that!
I am able to do that by changing the server name orders in hosts file, but this can't help if I want to authenticate from the both server names!
Thanks.
I'm assuming that you're using mod_auth_kerb. You need to add:
KrbServiceName Any
to your Apache configuration. This will tell mod_auth_kerb to accept authentications to any principal for which there is a key stored in the keytab it uses, rather than making assumptions about what principal will be used and only accepting authentications to that principal.
You need to identify which Kerberos SPN you want to use for each website. You can check what SPNs are listed in your keytab by running: klist -k <Keytab> -- make sure that you're checking the keytab file that Apache uses.
In the VirtualHost declaration you need to change the KrbServiceName value to match the one that you identified from the keytab. Restart Apache and it should start using that when communicating with Kerberos.
An example would look something like:
KrbServiceName HTTP/yourservice.domain#REALM.COM
Make sure that AD has a service account and SPN that matches and that it can resolve via DNS back to the Apache server.
I found this recently in the MIT Kerberos documentation on Principal names and DNS:
Applications can choose to use a default hostname component in their service principal name when accepting authentication, which avoids some sorts of hostname mismatches. Because not all relevant applications do this yet, using the krb5.conf setting:
[libdefaults]
ignore_acceptor_hostname = true
will allow the Kerberos library to override the application’s choice of service principal hostname and will allow a server program to accept incoming authentications using any key in its keytab that matches the service name and realm name (if given). This setting defaults to “false” and is available in releases krb5-1.10 and later.
I have a replication set up with pull subscribers and it's deployed in our corporate domain. I have requested to create a dedicated account to run this replication off of.
On a pull subscription client in Sql Agent job I get this error:
Message
Unable to start execution of step 1 (reason: Error authenticating proxy DOMAIN\username, system error: Logon failure: the user has not been granted the requested logon type at this computer. ('Access this computer from network')). The step failed.
Where DOMAIN - is my domain name and username is this replication username that I requested from our admins.
This replication user can access both the distributor and the share folder where snapshots are stored. It also has this specific permission 'Access this computer from network' inherited from the group it's in.
Anyone encounter this sort of problem?
It turned out that the requested user wasn't added to a group that has all the necessary permissions. And so I've been struggling with this problem for several hours at which point I decided to go to our network administrator and see to it that the user was actually in the proper group. So yeah, I guess the message is right, a user has to have this permission 'Access this computer from network'. So, this basically answers my own question. Phew!