We have an slapd server that has started generating many err=49 lines in /var/log/ldap for a particular service acc. err=49 is logged when the bind has failed. Through searching for the connections I can see that the source is localhost.
I have checked that the acc is active using ldapsearch. I have tried grepping through /etc for the service acc name to see what could be using to no avail.
How can I identify the source of the ldap queries to help investigate the issue?
Instead of trying to work from a connection perspective I continued looking from a log perspective:
awk '/from IP=127.0.0.1/ {print substr($3,1,5)}' /var/log/ldap |sort -n|uniq -c
This showed hits on the hour, searching cron.hourly found the suspect. My ideology of grepping for username was flawed based on the way the particular cron.hourly'ed script worked.
Related
I am trying to write a query via splunk to find SSH logs used for authentication in Linux. Any ideas as to the query needed to writer to achieve this? I am new to splunk so any information would help.
Here is what I have started but to no avail:
sshd "Invalid user" NOT port NOT "preauth]" | iplocation InvalidSSHIP
I strongly suggest you use the Splunk TA for Nix, https://splunkbase.splunk.com/app/833/
In it, you will find common inputs and field extractions for SSH event logs, as well as other common *nix formats.
If you follow this TA, you should be able to find the events you are looking for with the following search
index=os eventtype=ssh*
I'm trying to setting up a Zeek IDS cluster (v.3.2.0-dev.271) on 3 Ubuntu 18.04 LTS hosts to no avail - running zeek deploy command fails with the following output:
fatal error: problem with interface ens3 (pcap_error: socket: Operation not permitted (pcap_activate))
I have followed the official documentation (which is pretty generic at best) and set up passwordless SSH authentication between the zeek nodes.
I also preemptively created the /usr/local/zeek path on all hosts and gave the zeek user full permissions on that directory. The documentation says The Zeek user must be able to either create this directory or, where it already exists, must have write permission inside this directory on all hosts.
The documentation also says that on the worker nodes this user must have access to the target network interface in promiscuous mode.
My zeek user is a sudoer AND a member of netdev group on all 3 nodes. Yet, the cluster deployment fails. Apparently, when zeekctl establishes the SSH connection to the workers it cannot get a hold of the network interfaces and set caps.
Eventually I was able to successfully run the cluster by following this article - however it requires you to set up the entire cluster as root, which I would like to avoid if at all possible.
So my question is, is there anything blatantly obvious that I am missing? To the best of my knowledge this setup should work, otherwise I don't know how to force zeekctl to run 'sudo' in front of every SSH command it is supposed to run on the workers, or how to satisfy this requirement.
Any guidance will be greatly appreciated, thanks!
I was experiencing the same error for my standalone setup. Found this question from googling it. More googling the error brought me to a few blogs including one in which the comments mentioned the same error. The author mentioned giving the binaries permissions using setcap:
$sudo setcap cap_net_raw,cap_net_admin=eip /usr/local/zeek/bin/zeek
$sudo setcap cap_net_raw,cap_net_admin=eip /usr/local/zeek/bin/zeekctl
After running them both, my instance of zeek is now running successfully.
Source: https://www.ericooi.com/zeekurity-zen-part-i-how-to-install-zeek-on-centos-8/#comment-1586
So, just in case someone else stumbles upon the same issue - I figured out what was happening.
I streamlined the cluster deployment with Ansible (using 'become' directive at task level) and did not elevate when running the handlers responsible for issuing the zeekctl deploy command.
Once I did, the Zeek Cluster deployment succeeded.
I am working for an IBM Business Partner and I am trying to complete a first PoC ICP installation. The basic installation has worked. I did not configure LDAP during the deployment but I am trying to add an LDAP connection in the console now, afterwards.
Unfortunately, I always fail. And there seem to be a number for limitations and/or bugs in the LDAP connection of ICP to the point of making it unuseable.
First, I would like to connect to an IBM Domino Directory as my LDAP server. Anyone who has worked with a Domino directory before knows that many Domino deployments have an O=Org suffix where Org is a company name containing spaces. For example, in our case it is "O=ARS GmbH". I would normally need to use this as the base DN (search base). However, ICP does not allow spaces in this field ... that need to be fixed! Any other LDAP client product I tried to connect to our Domino directory over many years was able to deal with spaces in the base DN.
Next, in a Domino directory usually the groups do have a different suffix (e.g. search base) than users. But ICP only offers ONE base DN field and not separate base DN fields for users and groups. Any other LDAP client ... DOES offer this. This needs to be fixed in ICP as well.
Next, the bind DN field does not allow some commonly used special characters which are often found in account names, such as the - character. This needs to be fixed as well (as it happens, the special user ID we have in our Domino directory which we use for LDAP binding is named dir-client ...).
Well, after hitting all those blocking problems, I finally tried to connect to our Microsoft Active Directory. This time I could successfully complete the LDAP connection. After doing so, I turned to "Users" and discovered I need to "Import group". However, no matter what I try to enter as (correct) values into the CN and OU fields, I only end up with an "internal server error".
Further more, after I could save the LDAP connection to Active Directory, I could no longer log in to the console with the builtin admin account! But since I could not import any users/groups, I could not assign that role to an LDAP account ... luckily, I had a VM snapshot of the master server and could thus revert to the state before.
This is really frustrating ...
I ran into identical issue when hooking up to an openldap server running in a docker container. It took me awhile to figure out the ICP pod and container where the log file is to get more information than "Internal Server Error".
Here is how to find the relevant ICP pod/container log:
Look for the "auth-idp" pods in the kube-system namespace. I use:
kubectl get pods --namespace=kube-system | grep auth-idp
If you are running an HA cluster, you will have a pod on each master node.
In my case I have 3 master nodes. If you are running only a single master, then you will have only one auth-idp pod.
Again, in an HA scenario, you need to figure out which is your current master node. (The easiest, crude way to do that is ssh to your master VIP and see which node you land on.)
Now figure out which pod is running on the current master node. On each pod I use:
kubectl describe pod auth-idp-vq5bl --namespace=kube-system | grep IP
or
kubectl get pod auth-idp-vq5bl --namespace=kube-system -o wide
The one on the IP that is the current master node is where the log of interest will be.
The container in the pod that has the log of interest is: platform-identity-mgmt
To actually see the log file use:
kubectl logs auth-idp-vq5bl --namespace=kube-system --container=platform-identity-mgmt
At that point you will be able to scroll through the log and see a more detailed error message.
In the case of my error the log indicated my search filter for the group was not working properly. I decided to mess with the user ID map and user filter so I used a user ID map of *:cn and a user filter of: (&(cn=%v)(objectclass=inetOrgPerson)) Once I changed those in the ICP LDAP configuration, the user import succeeded. However, later I realized the logins were not working because the login is based on a search on userid or uid. So I changed the user ID map back to *:uid and the user filter back to (&(uid=%v)(objectClass=inetOrgPerson)). That corrected the login issue. I added some users to my LDAP group and reimported the group and the import worked as well. At this point, I'm not sure what was going on with the original import not working until I messed with the user ID map and user filter. Go figure.
In my OpenLDAP directory instance my groups are all under ou=groups and each group member is listed as, e.g., cn=Peter Van Sickel,dc=ibm,dc=com. I had to edit the group member to get it using the full DN of an actual user.
My users are all directly under the root DN: dc=ibm,dc=com.
As to specific issues with other LDAPs, it is my experience that each has its own set of idiosyncrasies to get things working as desired.
About once every 10 years I need to wrestle with SAMBA as I migrate to new hosts, and then I repress the traumatic memory until I have to relearn it all the next time :S Hence this newbyish question.
I have a Ubuntu VM with a couple of shares - one ("Public") is unsecured, the other ("Public2") is secured, with the intention that it should be accessed only by an authenticated user account defined on the Ubuntu box. Both shares appear in Windows Explorer on both XP and Win8.1. However, I can't for the life of me work out how to log into the secure Public2 share.
Leaving Windows clients out of it, I've tried simply looping back to the box using smbclient, which produces the following output, indicating it just can't authenticate:
michael#ubuntu:~$ smbclient //ubuntu/Public2 --user=michael%mypasswd
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 4.1.6-Ubuntu]
tree connect failed: NT_STATUS_ACCESS_DENIED
Meanwhile the unsecured share is accessible.
What (probably incredibly obvious) thing have I missed? Am I not specifying the username correctly?
/var/lib/samba/usershares/public (unsecure, works) contains:
#VERSION 2
path=/home/michael/Public
comment=
usershare_acl=S-1-1-0:F
guest_ok=y
sharename=Public
/var/lib/samba/usershares/public2 (which I can't access) contains:
#VERSION 2
path=/home/michael/Public2
comment=
usershare_acl=S-1-1-0:F
guest_ok=n
sharename=Public2
For users who are using for the command line option, use
$ sudo smbpasswd -a <user_name>
this will prompt you to assign the password.
WARNING: This refers to Samba 2. We are at Samba 4 now. Take care which version of Samba you are using. As stated in my comment, the GUI will break your configurations.
A work colleague has pointed me in the right direction:
The Linux user ID being used to access the Linux share needs to have a second "samba" password defined for it. The easiest way to do this is to install and run the GUI Samba Server Configuration app, which isn't installed by default.
The Samba documentation does explain this, but it's buried in the masses of documentation explaining all the various arcane aspects of samba.conf configuration etc.
The following article gets to the heart of the subject:
http://ubuntuhandbook.org/index.php/2014/05/ubuntu1404-file-sharing-samba/
You have to edit the '/etc/samba/smb.conf'
use sudo nano /etc/samba/smb.conf to edit the conf file.
Where Workgroup = [your Domain]
There is no 'second samba password'. There is linux password: /etc/passwd and then there is Samba password, which is either smbpasswd or passdb.tdb. Which one and where it is located depends on Samba version and setting in smb.conf. BOTH must be set. Both means Linux in /etc/passwd and in Samba (one of the above). This is in most cases the issue with this error message. Or try to restart Lanman service, or Windows.
But I want to comment on another, probably rarer case.
If you are using customized Samba and only in such case, there might be another (extended) reason for this error.
Samba might be compiled with additional permission checks, which will say "NO" (return false) after which Samba will announce error, the same as this Q is mentioning.
Check the log for errors. There might be a clue if it is such a case.
Again, this is specific for custom build Samba.
Specifically in my case, on QNAP NAS, Samba will call a binary /sbin/appriv -C -u 502 -S1
-C, --check Check user privilege.
-S, --samba [bit] The privilege of Samba
-u, --uid [uid] UID.
appriv is "appriv -> nasutil" which is QNAP own binary, not part of the linux or the GNU.
With so many options build in Samba, I can't find a reasoning for this additional check.
Especially when it could be satisfied with just a plain empty file returning "true".
Just a complication, possible source of issues, no safety advancement.
I've been updating old abandoned system from QNAP. Replaced Samba from another, newer NAS.
This is how I come about this issue and wasted a lot of time on it. Thanks QNAP.
Apparmor might also be the cause. You need to whitelist all share locations, otherwise you will always get the "permission denied" error.
Fix is adding to /etc/apparmor.d/local/usr.sbin.smbd:
"/path_to_share/" rk,
"/path_to_share/**" lrwk,
for each share. (The first line allows read-access to the base-directory, the second line allows read-write-access to everything within that base-directory recursively)
Source: https://wiki.archlinux.org/title/Samba#Permission_issues_on_AppArmor
Crosspost from: https://serverfault.com/a/1109267/592032
I configured ldaps by refering http://linuxtechres.blogspot.com/2010/04/how-to-configure-ldaps-or-starttls.html.
after that when I try to ldapsearch, it wont display any resulsts.
entries are there in ldap, as I will get error if I try to ldapadd them .
If I remove TLS related info from ldap.conf and slapd.conf , ldapsearch works nicely and display all entries.
Can someone help please?
Do you have some minimum level of confidentiality required in your config file? Also the way the ACLs work is that they stop processing after the first hit (in general) so if you have an ACL on a specific user type that is extremely limiting that may be what causes your situation. The admin account can always see everything in case you do mess things up.
Probably late for this, but... Have you tried the ldapsearch/ldapadd option "-ZZ"?
What you want to do is look at the slapd.log file and see what error the OpenLDAP server is returning when you try to connect. Then you will have a hint of where to go next.