Did I import inetOrgPerson schema correctly for OpenLDAP on Alpine Linux? - linux

I'm trying to import a user into OpenLDAP on Alpine Linux. Here's the LDIF that I named searchUser.ldif:
# Search account
dn: uid=search,dc=home
changetype: add
objectClass: top
objectClass: person
objectClass: inetOrgPerson
cn: search
sn: search
uid: search
The command I used to import it is:
ldapadd -x -D "cn=Manager,dc=home" -w supersecret -f searchUser.ldif
The error I get is:
ldap_add: Invalid syntax (21) additional info: objectClass: value #2 invalid per syntax
My understanding of this is the objectClasses are numbered, starting with 0, and that #2 indicates the problem is with inetOrgPerson.
I've done this successfully using OpenLDAP on Raspberry Pi OS (debian). However, I get the feeling the Debian package automates some configuration steps that the Alpine package does not. One of those steps I think Debian does during the package install is to import inetOrgPerson schema.
I've tried to do the schema import manually. Here are the steps I took prior to trying the LDIF import...
I scripted my install of OpenLDAP on Alpine, like so:
export DOMAIN="dc=home"
echo "Installing packages..."
apk add openldap openldap-back-mdb openldap-clients
echo "Configuring for v2.3+ style slapd.d config directory..."
install -m 755 -o ldap -g ldap -d /etc/openldap/slapd.d
sed -i~ \
-e 's/^cfgfile=/#cfgfile=/' \
-e 's/^#cfgdir=.*/cfgdir=\"\/etc\/openldap\/slapd.d\"/' \
/etc/conf.d/slapd
rm /etc/openldap/slapd.conf
echo "Customizing for domain: ${DOMAIN}..."
sed -i~ \
-e 's/\.la$/.so/' \
-e "s/dc=my-domain,dc=com/${DOMAIN}/" /etc/openldap/slapd.ldif
echo "Importing configuration..."
slapadd -n 0 -F /etc/openldap/slapd.d -l /etc/openldap/slapd.ldif
chown -R ldap:ldap /etc/openldap/slapd.d/*
echo "Configuring slapd service..."
install -m 755 -o ldap -g ldap -d /var/lib/openldap/run
service slapd start
rc-update add slapd
The slapd service started and I could connect to it with command-line tools and from a client over port 389. So far, so good.
The next thing I did was to import schema for cosine and inetOrgPerson. I believe the Debian package did this automatically, because I don't recall having to do this previously.
Here's what I did on Alpine to import the schema:
slapadd -n 0 -F /etc/openldap/slapd.d -l /etc/openldap/schema/cosine.ldif
slapadd -n 0 -F /etc/openldap/slapd.d -l /etc/openldap/schema/inetorgperson.ldif
There were no errors.
I then created an organization using the command ldapadd -x -D "cn=Manager,dc=home" -w secret -f org.ldif and this LDIF as org.ldif:
dn: dc=home
objectclass: dcObject
objectclass: organization
o: Home
dc: home
dn: cn=Manager,dc=home
objectclass: organizationalRole
cn: Manager
This too was successful.
I can also create organizational units with this LDIF:
# Organizational unit for users
dn: ou=People,dc=home
changetype: add
objectClass: organizationalUnit
ou: People
# Organizational unit for groups.
dn: ou=Groups,dc=home
changetype: add
objectClass: organizationalUnit
ou: Groups
So I think my server is okay, but I may have done something wrong with the inetOrgPerson schema import that's causing the Invalid syntax (21) error.
Is the way I'm importing the inetOrgPerson schema correct? Is there a way to verify it?

I believe the problem was due to incorrect ownership for the new files in the /etc/openldap/slapd.d/cn=config/cn=schema directory. Once I fixed that, I was able to import the search user.
Because I ran the slapd commands as the root user, the resulting schema config files were owned by root. I discovered this when I restarted the slapd service and it failed with this error in /var/log/messages:
ldif_read_file: Permission denied for "/etc/openldap/slapd.d/cn=config/cn=schema/cn={1}cosine.ldif"
The solution was to change ownership on the files. This is the correct ownership:
alpine:/etc/openldap/slapd.d/cn=config/cn=schema# ls -l
total 32
-rw------- 1 ldap ldap 15575 May 5 12:43 cn={0}core.ldif
-rw------- 1 ldap ldap 11361 May 5 14:53 cn={1}cosine.ldif
-rw------- 1 ldap ldap 2855 May 5 14:53 cn={2}inetorgperson.ldif
So the answer to this question is...
Yes, importing with slapadd -n 0 -F /etc/openldap/slapd.d -l /etc/openldap/schema/inetorgperson.ldif worked fine, but the command should have been run as the ldap user so the ownership is correct. (Or run as root and change ownership after.)
One way to verify the schema is to look inside the /etc/openldap/slapd.d directory. Specifically, /etc/openldap/slapd.d/cn=config/cn=schema shows evidence of the schema I added.
Even with the potential for incorrect file ownership, I see this as a much easier way to add schema than some of the other tutorials I've found that involve creating and editing a temporary slapd.conf file.

Related

How to set specific user can run certain root command in redhat

i want to ask for a specific user to use certain root commands in redhat?
my server run redhat OS 7.6. i dont have any idea how to set a user that can run certain commands from root.
let say i have one user id name MY_CIT, so MY_CIT can run certain commands for example to create print queue #lpadmin -p printer -v socket://printer:9100 -E
so MY_CIT no need root access to trigger the command.
Anyone experience on this? kindly help. thanks
You'll be able to use file ACLs. As a test I removed execute permissions from the nano command, just to show how this will work.
You won't need to do this, however, you will need root permissions to the machine. Instead of nano, use 'lpadmin' as per your requirements
[root#server bin]# chmod o-x /bin/nano
[root#server bin]# ls -lah /bin/nano
-rwxr-xr-- 1 root root 202K Jun 10 2014 nano
To test, we change to user1 and try use nano to edit a file:
[user1#server ~]$ nano file1
-bash: /bin/nano: Permission denied
Now, as root again, we add an ACL to the nano program. This allows only user1 to execute the program.
[root#server bin]# setfacl -m u:user1:x /bin/nano
Display ACL with getfacl:
[root#server bin]# getfacl /bin/nano
getfacl: Removing leading '/' from absolute path names
# file: bin/nano
# owner: root
# group: root
user::rwx
user:user1:--x <<-- Note this
group::r-x
mask::r-x
other::r--
As user1, we are able to use the nano program, but not as user2:
[user1#server ~]$ nano file1
[user1#server ~]$ ls
file1
[user1#server ~]$ exit
logout
[root#server bin]# su - user2
[user2#server ~]$ nano file1
-bash: /bin/nano: Permission denied
ACLs allow admins to extend permissions past just user/group/other. You're able to set permissions for specific users on the system.
Run command with a root privilege:
sudo visudo
It opens file /etc/sudoers for edit.
Add this line at the end of the file (and after keep one blank line):
MY_CIT ALL = NOPASSWD: /usr/sbin/lpadmin
where:
MY_CIT - name of your user
/usr/sbin/lpadmin - path to executible file. Note please that in your distro path can be different. You can check this with command whereis lpadmin.
After user can run command lpadmin with arguments with sudo without password:
sudo lpadmin ...

Not able to create a directory using sudo -u username mkdir /var/log/test

I am unable to create a directory using sudo priveleges from root user and If I login to user , I can create an directory under /root using sudo. Also I have added to allow all commands in /etc/sudoers file and the details are below:
[root#linux home]# cat /etc/sudoers | grep tes
test ALL= NOPASSWD: ALL
Error
[root#linux home]# sudo -u test mkdir /var/log/test3
mkdir: cannot create directory ‘/var/log/test3’: Permission denied
Any Ideas ?
Thanks
By running 'sudo -u test', you're giving yourself lower privileges than the roor user because you're running the command as the user 'test', not 'root'. From the root user, you can just run:
mkdir /var/log/test3
Read man sudo for more info.
Or:
Run visudo and uncomment the wheel group, then add the user test to the wheel group.
If you don't mind me asking, why do you need to create a directory as a certain user from the root user? Especially since the directory you're making will not be user specific?
Also, in the sudoers file , you should what added test ALL=(ALL) NOPASSWD: ALL, not test ALL= NOPASSWD: ALL

Ldap create user with custom attributes and objectclasses

I am trying to add custom attributes and object classes in my LDAP(ODSEE) but having issues.
Initially, I had issues with adding the custom attributes and classes, but was finally it worked. My custom definitions look like below(got the test code from one of the sites for testing)
dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.3.6.1.4.1.4203.666.1.90
NAME ( 'personStatus' )
DESC 'person Status'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
MULTI-VALUE )
dn: cn=schema
changetype: modify
add: objectClasses
objectClasses: ( 1.3.6.1.4.1.4203.666.1.100
NAME 'YoLinuxPerson'
DESC 'Yo Linux Person’
SUP inetOrgPerson
AUXILIARY
MAY personStatus )
My user ldif is as below
dn: uid=acc, ou=People, dc=example,dc=com
**objectClass: YoLinuxPerson*******************Custom
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: aaaaa Vaughan
sn: Vaughan
facsimileTelephoneNumber: +1 408 555 3372
givenName: Kirsten
l: Sunnyvale
mail: aaaaa#example.com
ou: Human Resources
ou: People
roomNumber: 2871
telephoneNumber: +1 408 555 5625
uid: aaaaa
**personStatus: abcdefghij**********************Custom
userPassword:: e1NTSEF9WhgljhlWxzZUdDUVVFUW05OTg1bmJSUkpoNHdYUVgrZkE9P
I tried multiple ways but everything fails. If I remove the "personStatus: abcdefghij" the ldapadd command works, but if I have it there, it fails saying
[config]$ ldapadd -h -p -D "cn=" -w -f User.ldif
adding new entry uid=acc, ou=People, dc=example,dc=com
ldap_add: Object class violation
I also did a ldap search
- ldapsearch -D -w -h -p -b "cn=schema" -s base 'objectclass=*'
and it displayed all the results including the custom attribute (which I am having issues with), but i could not see the custom objectClass(which I can add to the user).
I tried with Apache Studio also, it fails with the same message. I am not sure what I am missing. Any help is appreciated. Thanks.
There's a problem with the objectClass definition :
Either it extends inetOrgPerson, and thus it's a STRUCTURAL objectClass,
Or it is AUXILIARY and doesn't need to extend inetOrgPerson.
But your issue may be that you need to restart DSEE to be able to set the entry with the new objectClass and attribute (I vaguely remember an issue in that domain, but it's been more than 5 years since I last played with DSEE).

How to do an initial setup of slapd OLC with ldapmodify

I've run into sort of a deadlock setting up an LDAP server on CentOS.
I use the on-line configuration files under /etc/openldap/slapd.d
The documentation tells you not to modify those files by hand, and the files are checksummed.
But I cannot use ldapmodify, because I can't log in (simple bind) - and I can't log in because I can't set a password for the user - and I can't set a password for the user because I can't use ldapmodify, because I can't log in, because I can't set a password, because ....
I could of course set it up by editing the files directly - and I have done it, and it works.
But it just bugs me, that I can't find a way to do it "properly".
Ubuntu (Debian Packages)
Ubuntu and maybe other distributions with debian packages try to be super smart and set up everything for you - which really becomes a problem when you want to do a non-interactive installation, because debconf will set random admin-passwords and also configure the base-DN according to your machine name. You might be able to guess the base-DN - but you can't guess the password, and as it is deleted from the debconf-DB after installation you can not read it out.
You can however configure the passwords and DN before you install the package:
export DEBIAN_FRONTEND=noninteractive
sudo debconf-set-selections <<EOF
slapd slapd/internal/generated_adminpw password changeme
slapd slapd/password2 password changeme
slapd slapd/internal/adminpw password changeme
slapd slapd/password1 password changeme
slapd slapd/domain string example.com
slapd shared/organization string example.com
EOF
sudo apt-get install -y slapd ldap-utils
Be very careful with your spaces here: putting two spaces before the password will set the password to __changeme_ (that is: (blankspace)changeme)
Thanks to OpenStackPro for showing how to configure the selections
You can test your setup with
ldapsearch -x -D "cn=admin,dc=example,dc=com" -w "changeme"
Which should output in something like
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 32 No such object
# numResponses: 1
This means, there is nothing in your LDAP-Database (yet), but at least you were able to log in :-)
If you get something like
ldap_bind: Invalid credentials (49)
you need to double check your admin-DN and password. You can check your admin-DN with
sudo slapcat -n0 | grep olcRootDN
CentOS 6.6 (and most likely RedHat, Fedora etc.)
Install the packages
sudo yum -y install openldap openldap-servers openldap-clients
First get a password-hash with
slappasswd -s changeme
Be aware that the CentOS-package uses my-domain.com instead of example.com, so you might need to adapt the commands accordingly.
Create an initial ldif, in a file like init.ldif:
dn: dc=my-domain,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: my-domain.com
dc: my-domain
dn: cn=admin,dc=my-domain,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword: {SSHA}rX8oWGKW6B7mKY+nUJhrv4g1pPH5KtQg
To write this config to your LDAP use:
sudo slapadd -F /etc/openldap/slapd.d -b "cn=config" -l init.ldif
Again, You can test your setup with
ldapsearch -x -D "cn=admin,dc=my-domain,dc=com" -w "changeme"
(see above at "Ubuntu")

Adding FTP user via bash script issue

I have a .sh file (lets say adduser.sh) that is executed via a cronjob that contains the commands to create an FTP user.
The adduser.sh file looks like so...
#!/bin/bash
mkdir /var/www/vhosts/domain/path;
useradd -d /var/www/vhosts/domain/path -ou <uid> -g <group> -s /bin/false <username>;
echo <password> | passwd <username> --stdin;
Now here is my problem. If I run it directly through SSH using...
sh adduser.sh
...no problems and it works as intended.
But if I let the cronjob run it the directory is created but the user is not added.
What gives?
As it stands, there is an alternative to useradd known as adduser. In Debian or Ubuntu, adduser is a perl script and performs sequential functions like create the user using adduser, assign it to a group, create home directory etc.
As per adduser man page-
adduser and addgroup are friendlier front ends to the low level tools
like useradd, groupadd and usermod programs, by default choosing
Debian policy conformant UID and GID values, creating a home directory
with skeletal configuration, running a custom script, and other
features.
In Fedora, RedHat, and CentOS, adduser is just a symbolic link to useradd.
[root#hobbit ~]# which /usr/sbin/adduser
lrwxrwxrwx 1 root root 7 2012-09-20 20:20 /usr/sbin/adduser -> useradd
If you are on any on the above OS then you can try adduser redirect 2> to a add_user.log file and check the file to see if something goes wrong.
I have resolved this simply adding /usr/bin/ to the useradd function.
#!/bin/bash
mkdir /var/www/vhosts/domain/path;
/usr/bin/useradd -d /var/www/vhosts/domain/path -ou <uid> -g <group> -s /bin/false <username>;
echo <password> | passwd <username> --stdin;
Thanks everyone for helping me get on the right track. Hope this helps someone out there.

Resources