administration:ldap
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
administration:ldap [2013/01/26 22:20] – created damir | administration:ldap [2013/01/26 22:44] (current) – damir | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== cn=config ====== | ====== cn=config ====== | ||
- | in LDAP all configurations can be registered inside a file / | + | in LDAP all configurations can be registered inside a file / |
- | once the slapd configuration | + | Once the slapd configuration |
- | the manager can be defined as you like, but is common to use " | + | the manager can be defined as you like, but is common to use " |
- | the passage to cn=config method means that all the variation to the configuration are activated using the standard ldap< | + | the passage to cn=config method means that all the variation to the configuration are activated using the standard ldap< |
===== cn=config manager ===== | ===== cn=config manager ===== | ||
- | the cn=config manager is defined inside one of the files used by slapd to run the service: **/ | + | the cn=config manager is defined inside one of the files used by slapd to run the service: **/ |
< | < | ||
olcRootDN: cn=manager, | olcRootDN: cn=manager, | ||
olcRootPW: {SSHA}2c....... | olcRootPW: {SSHA}2c....... | ||
</ | </ | ||
- | | + | As you probably imagined, they define the name of the manager and the password associated. |
- | in both cases you can change the values of these fields by writing directly inside the file but in this case you must relaunch the slapd service. better to configure these fields correctly before going in production. | + | in both cases you can change the values of these fields by writing directly inside the file but you must relaunch the slapd service, so it' |
- | in case you need to change the password you can use the **slappasswd** command, that generate an encrypted password | + | In case you need to change the password you can use the **slappasswd** command that generate an encrypted password |
- | ====== add a schema | + | ===== add a schema ===== |
- | if you need to add a schema to the slapd configuration, | + | if you need to add a schema to the slapd configuration, |
- | to generate the ldif file containing the schema you can use the same command used to generate the initial cn=config structure from the existing slapd.conf file, but as this means that a new cn=config structure will be created, **never** use the transform command inside the production slapd.d directory. | + | To generate the ldif file containing the schema you can use the same command used to generate the initial cn=config structure from the existing slapd.conf file, but as this means that a new cn=config structure will be created, **never** use the transform command inside the production slapd.d directory.\\ |
- | It's for sure better that you create a new directory somewhere in the disc and move inside | + | It's for sure better that you create a new directory somewhere in the disc and move inside |
< | < | ||
mkdir / | mkdir / | ||
cd / | cd / | ||
cp / | cp / | ||
- | echo > | + | echo > |
# | # | ||
include / | include / | ||
EOF | EOF | ||
- | slaptest -f schema.conf -F / | + | |
+ | slaptest -f newschema.conf -F / | ||
ls -R / | ls -R / | ||
/ | / | ||
Line 44: | Line 45: | ||
</ | </ | ||
- | With the line codes above we created the //.ldif// containing the information about the kerberos schema we want to add (the schema is provided by the // | + | With the code lines above we created the // |
- | Once we have the needed //.ldif// file, we must edit it so it can be aded to an existing structure (the structure files created by slaptest are considered always as independent). | + | * The schema is provided by the // |
- | we do this by changing | + | * The ls -R command shows the structure created by the **slaptest** conversion utility |
+ | Once we have the needed //.ldif// file, we must edit it so it can be added to an existing structure (the structure files created by slaptest are considered always as independent, so you must not misc existing files with new ones). | ||
+ | We do this by changing some lines in the .ldif file the define | ||
- the line defining the record must be changed to remove any reference to the index position of the record | - the line defining the record must be changed to remove any reference to the index position of the record | ||
- | - the lines defining the creation of the record | + | - the lines defining the creation of the record |
in our case, we changed the first 3 lines of the file " | in our case, we changed the first 3 lines of the file " | ||
< | < | ||
Line 62: | Line 65: | ||
</ | </ | ||
- | then we deleted the last 7 lines of the files, | + | then we deleted the last 7 lines of the files, |
< | < | ||
entryUUID: ........ | entryUUID: ........ | ||
Line 70: | Line 73: | ||
modifiersName: | modifiersName: | ||
modifyTimestamp: | modifyTimestamp: | ||
- | </> | + | </code> |
- | and we inserted an empty line in place. remember that every .ldif file must contain an empty line to comlete the command. | + | to |
< | < | ||
[empty line] | [empty line] | ||
- | </.code> | + | </ |
+ | Remember that every .ldif file must contain an empty line to complete the command. | ||
- | once we did this we can add the new schema to the esisting | + | Once we do this we can add the new schema to the existing |
< | < | ||
ldapadd -x -D " | ldapadd -x -D " | ||
Line 93: | Line 97: | ||
add: olcAccess | add: olcAccess | ||
olcAccess: {0} to attrs=sambaLMPassword, | olcAccess: {0} to attrs=sambaLMPassword, | ||
- | | + | |
- | dc=kandou, | + | dc=....." write by dn.base=" |
- | | + | |
</ | </ |
administration/ldap.1359238834.txt.gz · Last modified: 2013/01/26 22:20 by damir