-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathldap.html
1600 lines (1280 loc) · 59 KB
/
ldap.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Pocket Survival Guide - LDAP</title>
<link rel="stylesheet" href="psg.css" type="text/css">
<LINK REL="SHORTCUT ICON" HREF="favicon.ico" type="image/x-icon"/>
<META NAME="description" content="System Administrator Pocket Survival Guide - A series of notes for Sys Admin"/>
<META NAME="keyword" content="ISBN 1419630288, ISBN 1-41963-028-8, Sys Admin, System Administrator, LDAP, book review, Solaris, HP-UX, AIX, Linux, Note, Notes, Pocket, Survival, Guide, psg, data center, power, electrical, plug, LYS, LKS, LAPPLAPP"/>
<META NAME="Robots" CONTENT="all"/>
<META NAME="Author" CONTENT="Tin Ho"/>
</head>
<body>
<div class="navheader">
<table summary="Navigation header" width="100%">
<tbody>
<tr>
<th colspan="4" align="center">
<A HREF="http://tin6150.github.io/psg/ldap.html">Sys Admin Pocket Survival Guide - LDAP</A>
</th>
</tr>
<tr>
<td align="left"><a accesskey="h" href="psg.html">Home</a></td>
<td align="center"><a accesskey="n" href="netapp.html">NetApp</a></td>
<td align="center"><a accesskey="s" href="sol.html">Solaris</a></td>
<td align="center"><a accesskey="p" href="hpux.html">HP-UX</a></td>
<td align="right"><a accesskey="a" href="aix.html">AIX</a></td>
</tr>
</tbody>
</table>
<hr></div>
<div class="chapter" lang="en">
<div class="titlepage">
</div>
</div>
<div id="google_translate_element"></div>
<script type="text/javascript">
function googleTranslateElementInit() {
new google.translate.TranslateElement({pageLanguage: 'en', layout: google.translate.TranslateElement.InlineLayout.HORIZONTAL}, 'google_translate_element');
}
</script>
<script type="text/javascript" src="//translate.google.com/translate_a/element.js?cb=googleTranslateElementInit"></script>
<H1>LDAP</H1>
LDAP is a user database, and it does in Unix what MS Active Directory does in Windows.
From Operating System Admin perspective, LDAP would typically be used to replace NIS (or NIS+ or scattered local passwd files). If you are pondering if you should migrate to LDAP, you'll wish the answer was 'NO' :)
<BR>
LDAP is much more complex than NIS, and OS support is still not rock solid as in NIS [this was written back in 2006]. Automount maps retrieval from LDAP is quite complex and not well supported. Older OS LDAP support is rather spotty, and forget about OS that have been EOL-ed by the vendor!
<BR>
So, in short, unless you know you need LDAP, stay away from it :) And if you do use it, hopefully this page has some useful info for you.
<BR><BR>
<div align="CENTER">
<A HREF="https://www.explainxkcd.com/wiki/index.php/327:_Exploits_of_a_Mom"><IMG SRC="fig/xkcd_bobby_tables_327.png"></A>
</div>
<A ID="tree"></A>
<H2>LDAP Tree Conceptualization</H2>
While LDAP is a user "database" repository, do not think of it as a Relational Database. It has no resemblance to RDBMS. The only thing that bear resemblance from RDBMS is the "key" and maybe "attributes", other than that, forget everything you learned about Relational DB when working with LDAP. Definately forget about those Boyce-Codd Normal Form!!
<H5>File Cabinet Numbering</H5>
...
<H5>Special File System Tree</H5>
...
<BR><BR>
<A ID="user"></A>
<H2>LDAP User Management</H2>
To disable/lock out a user, one can add the attribute to the user dn:
<TT>nsAccountLock: true</TT>.
The GUI console provide a way to click "disable" under the Accounting tab.
However, OS support for this flag is spotty. For example,
RHEL 3 does, but Solaris 8 does not.
Thus, the admin should change the user default shell to something like
/bin/false.
<BR><BR>
The Unix sys admin tradition is to also change the user's password to some random text to
prevent the user from logging in. Sure, theoretically, there is a chance the password could
still be guessed, but this isn't likely in practice, and may involve non-print characters.
Finally, note that if POSIX account is completely disabled,
it would delete the UID info, which are typically
undesirable due to the need to keep UID/GID for historical reference (files ownership, etc).
<BR><BR>
<A ID="profile"></A>
<H2>LDAP Profile Management</H2>
Some OS need a profile to be stored on the LDAP server so that client side
LDAP config can be updated in a single server location, rather than updating
on each machine.
In practice, profile may add too much complexity for too
little gain.
<BR>
<BR>
Sun also claims profile add security, preventing user from joining a machine
to LDAP w/o the LDAP admin knowledge. However, if the user have root in one
client, files in /var/ldap can be copied from one machine to another. The
encrypted password is copied, obliviating the need to know any password to
bind to the Directory. Lastly, most site allows anonymous bind just as ypcat
passwd is not secured anyway.
At the end of the day, the sys admin don't have a choice whether to use profiles or not.
Solaris and HPUX use
profiles, and AIX and linux don't.
<BR>
<BR>
Some admins like to create one profile for each version of a given OS, so that
vendor gratuitous changes in new version won't affect other versions. This
come at a cost of maintaining more profiles. Pick your own poison :)
On the other hand, if there are multiple sites, then site-specific profile
would typically make sense.
<BR><BR>
If there is only one domain, storing profiles near the root would be good.
eg OU=profiles,dc=unixville,dc=com.
But even if there are multiple domains, it maybe best to put them in the same
location anyway, using different name for profiles beloging to different
domain/site. This is mostly to ensure client bind process can locate the
profile easily and no guess work as to which part of the tree the profile came
from.
<BR><BR>
<H6>Solaris</H6>
So far, Solaris 8 thru 10 can use the same profile without any noticeable
problem. It seem easiest to create the profile from a Solaris 9 client and
bind using Directory Manager to seed this process.
<H6>HPUX</H6>
Each version of HP-UX add a bit more "feature" into the ldapux-profile.
11.00 has a basic profile, 11.11 added something, yet 11.23 bloated it up even
more. The nature of ldap client is that they ignore directives they don't
understand. As such, it worked pretty well to seed the initial profile using
an 11.23 client, binding as Directory Manager to upload the profile directly
to the LDAP server. Once done, the client can be reconfigured to bind as
proxy agent.
<BR><BR>
Lastly, I would like to mention that it is possible for LDAP-UX to use the
Solaris profile, at least for HP 11.11. However, latest versions of the two
OSes seem to diverge and maintaining separate profiles may reduce compatibility
problems down the road.
<BR><BR>
<A ID="gotchas"></A>
<H2>LDAP Gotchas</H2>
<H5>Smart Referals</H5>
Probably want to stay away from them from NIS migration perspective.
Linux is probably the only platform that supports it.
AIX will traverse them and loop thru the many servers set by the smart referals and cause
huge delays in telnet session connection, automount maps retrieval, and make machine
extremely sluggish.
<BR>
Solaris, it is a bit better. It still crosses the smart referal servers
more often than needed, resulting in delayed performance. Even when profile
is set that it should not follow the smart referals, it doesn't honor it.
Performance is acceptable if smart referals is a must. But even then,
I don't see automount maps referals to function correctly.
<BR>
HP-UX. Don't know if it cause problem yet, but it doesn't
provide the correct function of retrieving data from the
smart referal automount maps.
<BR>
<BR>
<H5>RSH vs REXEC</H5>
The protocol definition for RSH vs REXEC and other similar command:
(a) rsh use the Berkeley rcmd(3) library, and requires the binary to be setuid root
so that it run in priviledged ports and scan for .rhosts in remote server.<BR>
(b) rexec use the rexec(3) library. It does not scan .rhosts so no need to run as root. Instead,
it provide user password in clear text to remote server to login. remsh is the same as rsh, just renamed to avoid clash with the "restricted shell"<BR>
(c) rlogin is for remote console login. It handles less control character than TELNET.
Most system implements "rsh host" w/o a command as a call to rlogin for interactive login.
RSH is left for executing command on remote host and streaming the output back to the source machine.
RLOGIN also uses the Berkeley rcmd(3) library. <BR>
(d) rcp is remote copy akin to rsh wrapped around files directly. <BR>
(e) ssh default behaviour is to emulate rsh with command. For interactive login, it probably follows the rlogin algorithm, but hangles control characters much better, akin to telnet. Further, ssh is smart enough not to read user login/password from a std out redirect, but must ask on an interactive keyboard (expect can emulate keyboard login).
<BR>
<BR>
Note that <BR>
(1) RSH/RLOGIN/SSH scan user db differently than <BR>
(2) TELNET/REXEC <BR>
At least in AIX, the former set seems to invariably look for local /etc/passwd user first,
whilst the latter look at LDAP. nsswitch.conf on other system may have effect on this,
but Solaris 8 RSH is looking at local passwd first for sure.
Further note that AIX 5.3 "rsh hostname cmd" behaves more like (2). It is a bizare world
of intricate details and buggy implementations a/o protocol :-/
Note that aix man page on rexec says it only look at COMPAT but in fact it look at LDAP first!
<BR>
<BR>
AIX has a variable <TT>AUTHSTATE</TT> that get set to:
<LI>compat when login using rsh
<LI>LDAP when login using telnet
<LI>files can be set manually to force UID to username resolution thru files first (still go thru other method if it fails to find it in files).
<BR>
It seems safe to set this variable in /etc/profiles and /etc/csh.cshrc to
"compat" and all seems to work well, sourcing local files first.
<BR><BR>
<H5>RSH issues</H5>
RSH is likely to work in LDAP environment. However, getting RSH to allow user
to login without prompting for password (use of the insecure .rhosts, etc) is
likely to be more problematic. Solaris may need patches and config on
pam.conf. HP-UX will need update on pam.conf, and perhaps a myriad of other
config depending on security model. Refer to HP PAM doc.
<BR><BR>
<H5>SSH issues</H5>
<LI>If you compiled OpenSSH from source, you will need to include PAM support.
<LI>If you got openssh package from SunFreeware.com, the older version won't
work with LDAP.
<LI>If you are using vendor provided SSH, and vendor supplied LDAP libraries,
then all should be good. If on the other hand third party LDAP libraries are
added, eg from PADL.com, then things may break.
<H5>Automount issues</H5>
The typical sys admin would put lot of automount maps on NIS, and just about every unix OS automount can retrieve these maps from NIS. However, such assumption would be very wrong when migrating to LDAP. While the LDAP server can store anything one throws at it, the data may not always be retrievable :(
There is an rfc defining how to store automount maps in LDAP, and when configured correctly, will work. But it need substantial client-side support. Autofs on just about every OS client need to be updated. Solaris 9 and older need patches. AIX 5.2 and older don't have upgrades available. HP-UX 11i can use the Enhanced-AutoFS package, but it need lot of OS patches and kernel recompilation to support it. Newer Linux can run up2date to patch the autofs rpm. See the
<A HREF="#client">client</A> section below for more details.
In general, treat each version of each OS as an independent entry in the configuration matrix, and test everything to ensure your config works!
<BR><BR>
<A ID="ldapcmd"></A>
<H2>LDAP command</H2>
<A ID="ldapsearch"></A>
<H3>ldapsearch</H3>
Query ldap directory server info, output in LDIF format. <BR>
Sample ldap search commands...
<H5>solaris 10 argument structure:</H5>
<PRE>
ldapsearch -b SearchBase [options] FILTER [attributes]
[options]
-h ldaphost # ldap server to connect to, default to localhost
-D bindDN # user used to connect to LDAP, default to anonymous
-d n # debug level, bits flags.
-e # minimizes base-64 encoding (like tab!)
-T # don't fold/wrap lines. ldiff treat lines starting with space as
# continuation of previous line, def width is 80 chars.
-p 1234 # use port 1234 (default ldap use 389, TLS is 636)
-L # ...
[attributes]
select the addributes to list. Default to all, but can limit to display only a certain ones, eg:
dn # list only the dn entry
dn cn # list both dn and cn entries, nothing else.
</PRE>
<!-- -->
<!--
# info similar to db export on "uid=tin,ou=People,ou=sc,ou=ca,ou=na,dc=unixville,dc=com"
ldapsearch -b "ou=People,ou=sc,ou=ca,ou=na,dc=unixville,dc=com" -h ldapsvr "uid=tin"
# search for tin in "sc domain"
ldapsearch -b "ou=People,ou=fb,ou=oh,ou=na,dc=unixville,dc=com" -h ldapsvr "uid=tin"
# search for tin in "OH domain"
ldapsearch -b "ou=People,ou=sc,ou=ca,ou=na,dc=unixville,dc=com" -h ldapsvr "uid=*"
# display all user in the specified domain
ldapsearch -b "ou=People,ou=sc,ou=ca,ou=na,dc=unixville,dc=com" -h ldapsvr "uid=*" dn
# display all user, but only the dn attributes
ldapsearch -b "ou=People,ou=sc,ou=ca,ou=na,dc=unixville,dc=com" -h ldapsvr "uid=*" dn cn uidNumber
# display all user, but only the attributes: dn, cn, and uidNumber
-->
<PRE>
ldapsearch -b "dc=unixville,dc=com" -h ldapsvr uidNumber=5001
ldapsearch -b "dc=unixville,dc=com" -h ldapsvr -p 389 gidNumber=5001
# find entry with a given uid or gid number.
ldapsearch -b "dc=unixville,dc=com" -h ldapsvr memberUid=tin dn
# find all gruops whereby tin is a member of (unix secondary group membership)
# display only the dn (name of group and "domain" group is defined in)
ldapsearch -b "l=sf,l=us,dc=unixville,dc=com" -h ldapsvr uid=* dn
# list all user in a the "domain" l=sf,l=us
ldapsearch -b ou=Groups,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com -h ldap007 cn=* dn
# list all group names of a given domain.
ldapsearch -b "dc=unixville,dc=com" -h ldapsvr "uid=tin*" dn cn uidNumber
# find all username starting with tin, display only the fields dn, cn, uidNumber.
ldapsearch -b "ou=us,dc=unixville,dc=com" -h ldapsvr "givenName=*tin*" dn givenName uidNumber
# find all user real name containing tin anywhere, case insensitive
ldapsearch -b "ou=us,dc=unixville,dc=com" -h ldapsvr -D "cn=Directory Manager" "givenName=tin" userPassword
# -D = perform search using specific user credentials
# Certain attributes such as shadow password can only be retrieved by
# priviledged user.
# Finally, some info is only available on the Directory Server (eg via
# export) but not as ldapsearch at all. eg attributes for Person entry:
# creatorsName, modifiersName, modifyTimestamp, nsUniqueId
ldapsearch -b "cn=config" -h ldapsvr -D "cn=Directory Manager" "objectClass=*"
# retrieve config info, objectClass=* serve as wildcart for "all"
ldapsearch -b "cn=config" -h ldapsvr -D "cn=Directory Manager" "objectClass=*" | grep passwordStorageScheme
# grep for the password encryption scheme (crypt, ssha, etc).
# aix 5.3 only supports crypt
# solaris and linux support both crypt, ssha.
ldapsearch -b "cn=schema" -h ldapsvr -D "cn=Directory Manager" "objectClass=*"
# retrieve all info on the schema of the directory tree
ldapsearch -h ldapsvr -b "o=NetscapeRoot" -D "cn=directory manager" "objectClass=*"
# retrieve fedora directory server internal config info
# NetscapeRoot cuz fedora/redhat ds is based off the old netscape directory server
ldapsearch -h ldapsvr -L -b automountMapName=auto_master,l=sf,l=ca,c=us,dc=element50,dc=com objectclass=*
# something similar to "ypcat auto.master"
ldapsearch -h ldapsvr -T -b automountMapName=auto_home,ou=us,dc=unixville,dc=com objectClass=* dn | grep -v ^$
ldapsearch -h ldapsvr -T -b "ou=us,dc=unixville,dc=com" automountkey=* automountInformation | grep home
# list automount maps entries for auto_home, similar to "ypcat auto.home"
ldapsearch -h ldapsvr -T -b automountMapName=auto_home,ou=us,dc=unixville,dc=com automountKey=tin
# retrieve automount info about /home/tin
ldapsearch -h ldapsvr -T -b dc=unixville,dc=com automountkey=/home
# find out where /home is refered and how it is defined (auto.master, auto_master, which domain/ou)
ldapsearch -h ldapsvr -b dc=unixville,dc=com nisnetgrouptriple=*lungfish* | less
# find out which netgroup a machine called lungfish belongs to, long output!
</PRE>
<BR>
<A ID="ldapsearch-aix"></A>
<H5>AIX</H5>
ldapsearch is located in /usr/ldap/bin. Parameters are similar to Solaris.
<A ID="ldapsearch-linux"></A>
<H5>Linux native</H5>
Parameters used by /usr/bin/ldapsearch from the opendap-client rpm, most of
them are similar to the Solaris ldapsearch:
<PRE>
ldapsearch [options] FILTER [attributes]
[options]
-x # no SASL (option not in Solaris)
-LL # suppress comments in output
-b SearchBase # specify the starting point where search will begin. Typically root.
-h ldaphost # ldap server to connect to, scan /etc/ldap.conf if configured.
-D bindDN # user used to connect to LDAP, default to anonymous
-d n # debug level, bits flags.
[------------- options -------------] [-- FILTER (req) --] [attr]
ldapsearch -b dc=hybridauto,dc=com -h ldap007 -x nsds5ReplConflict=* dn | grep -v ^$
# find all entries with replication conflict problem,
# where dn is has nsuniqueid appended to it. eg:
# nsuniqueid=f0b6791e-1dd111b2-80dba88a-997d0000+uid=duptest,ou=people,dc=hybridauto,dc=com
</PRE>
<BR>
<H5>FEDORA-DS</H5>
Parameters used by /opt/fedora-ds/shared/bin/ldapsearch installed by the RedHat/Fedora DS:
<BR>
<H5>Some strange Linux machines default ldapsearch</H5>
Probaly old school linux machines... <BR><BR>
<PRE>
ldapsearch -x -ZZ -s "dc=unixville,dc=com" -b ""
-x = no SASL
-ZZ = use TLS
-s = search base
</PRE>
<BR>
<A ID="ldapadd"></A>
<H3>ldapadd</H3>
ldapadd will add info to the directory server, erroring out if
the entry already exist (as defined by the dn).
Must be done when the Directory Server is running, live.
(ldif2db will overwrite, see below).
<H5>FEDORA-DS</H5>
<PRE>
ldapadd -x -W -c -D "cn=Directory Manager" -h ldapsvr -f data.ldif
ldapadd is really "ldapmodify -a", so it share the same options, see below
</PRE>
Sample data.ldif file used to add a user, a group and simple automountmap entry for the home directory.
<PRE class="cf">
#
# add a user
#
dn: uid=tin,ou=People,l=sf,c=us,dc=unixville,dc=com
uid: tin
cn: Tin Ho
givenName: Tin
sn: Ho
mail: [email protected]
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
userPassword: {crypt}solarisShadowOk
loginShell: /bin/bash
uidNumber: 168
gidNumber: 168
homeDirectory: /nfshome/tin
gecos: optional NIS gecos field
#
# eg for adding a group
#
dn: cn=sn-group,ou=Groups,l=sf,c=us,dc=unixville,dc=com
objectClass: posixGroup
objectClass: top
cn: sn-group
gidNumber: 168
memberUid: moazam
memberUid: rlee
memberUid: lys
#
# eg for automount entry (automount object need to be already defined prior to this add)
# this form is acceptable by Solaris and new Linux autofs (ditto for Aix and Hpox,
# but the old linux autofs will not understand it, so get rpm 4.1.3-174 or newer)
#
dn: automountKey=tin,automountMapName=auto_nfshome,l=sf,c=us,dc=unixville,dc=com
objectClass: automount
automountKey: tin
cn: tin
automountInformation: -rw casper:/export/home/&
</PRE>
<A ID="ldapadd_automount"></A>
When first setting up LDAP repository, initial maps for auto.master, auto.nfshome, etc need to be defined. It maybe easier to do this using the GUI, see
<A HREF="#GUI_automount">below</A>.
The LDIF files defined here can be used for addition or verification in subsequent ldapsearch.
<I>Pay special attention to dot(.) vs underscore(_) below.</I>
<PRE class=cf>
#
# auto.master direct map (Linux)
#
dn: automountMapName=auto.master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
objectClass: top
objectClass: automountMap
automountMapName: auto.master
dn: automountKey=/nfshome,automountMapName=auto.master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
objectClass: automount
automountKey: /nfshome
cn: /nfshome
automountInformation: ldap:automountMapName=auto_nfshome,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
dn: automountKey=/net,automountMapName=auto.master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
objectClass: automount
automountKey: /net
cn: /net
automountInformation: -hosts
#
# auto_master direct map (Solaris?)
#
dn: automountMapName=auto_master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
objectClass: top
objectClass: automountMap
dn: automountKey=/nfshome,automountMapName=auto_master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
objectClass: automount
automountKey: /nfshome
automountInformation: auto_nfshome -rw,hard,intr,vers=3,rsize=32786,wsize=32786
dn: automountKey=/net,automountMapName=auto_master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
objectClass: automount
automountKey: /net
automountInformation: -hosts
#
# auto_nfshome
#
dn: automountMapName=auto_nfshome,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
objectClass: top
objectClass: automountMap
</PRE>
<A ID="ldapmodify"></A>
<H3>ldapmodify</H3>
Change existing data already stored in the Directory Server
<H5>Solaris</H5>
<PRE>
ldapmodify -D uid=tinh,ou=people,dc=geneusa,dc=com -h ldapsvr -p 1389 -f ./data.ldif
</PRE>
<!--
ldapmodify -h bigbear.amgen.com -p 1389 -D uid=tinh,ou=people,dc=unix,dc=amgen,dc=com -f ./ldapmodify.data.ldif
Solaris kronos works. xena doesn't. voivod doesn't.
-->
<H5>FEDORA-DS</H5>
<PRE>
ldapmodify -x -W -c -D "cn=Directory Manager" -h ldapsvr -f data.ldif
-h specify the server to connect to to perform the add
-f FILENAME, if using path with filename, must use /full/path/to/file
If no filename is defined, ldapmodify expect all commands to come from std in, one line at a time;
empty line by itself to indicate end of record.
-x = simple auth instead of SASL
-W = prompt for password on the CLI
-c = continuos operation, instead of exiting when errors happens
-D USER = the user to perform the change as
-v = verbose
-n = dry run, don't acutally do anything
</PRE>
<PRE class=cf>
#
# modify user account try adding the objectClass=shadowAccount
# so that user can login to Solaris 8 and related machines
# Note that some ldapmodify binary may crook on comments!!
# (Solaris and many Linux can't parse #)
# Blank lines are potential problems, so avoid them :)
#
dn: uid=tin,ou=People,l=sf,c=us,dc=unixville,dc=com
changetype: modify
add: objectClass
objectClass: shadowAccount
</PRE>
<PRE class=cf>
#
# Add a password field to user whose account have empty password
# ie, no userPassword clause definated at all
#
dn: uid=mlee,ou=People,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
changetype: modify
add: userPassword
userPassword: {crypt}*notSet*
</PRE>
<PRE class=cf>
#
# Change user password field to indicate that it is in locked state.
#
dn: uid=tho,ou=People,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
changetype: modify
replace: userPassword
userPassword: {crypt}*AccountLocked-2006-07-26*
#
# Change account to lock state, not all OS honor this.
#
dn: uid=tho,ou=People,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
changetype: modify
add: nsAccountLock
nsAccountLock: true
</PRE>
<PRE class=cf>
#
# Change a group definition: add a user to its membership list
#
dn: cn=sysadmin,ou=Groups,ou=sc,ou=ca,ou=na,dc=hypbridauto,dc=com
changetype: modify
add: memberUid
memberUid: tho
memberUid: mlee</PRE>
<A ID="import"></A>
<H2>Import/Export</H2>
<A ID="db2ldif"></A>
<H3>db2ldif</H3>
<TT>/opt/redhat-ds/slapd-ldapsvr/db2ldif -s dc=unixville,dc=com -a export.ldif</TT><BR>
Export all site data for the domain uxville.com, place it in LDIF format.
This file can then be edited, eg sed 's/\t/ /g' to remove all tabs, and then reimported.
<BR>
For the <TT>-a</TT> option, output file may need to have full path specified, and output location may need to be writable by user "nobody". If option -a is not used, the output will be stored automatically in a location where "nobody" can write to, typically /opt/redhat-ds/slapd-ldapsvr/ldif.
<BR> <BR>
<TT>/opt/redhat-ds/slapd-ldapsvr/db2ldif -n userRoot</TT>
<BR>
Brief test, output info related to "default master db" that stores root-level data, such as profiles, etc. It does not output data in
sub-suffix databases related db that stores user data. so it is usually small.
<BR>
<BR>
<A ID="ldif2db"></A>
<H3>ldif2db</H3>
<TT>/opt/redhat-ds/slapd-ldapsvr/ldif2db -s "ou=us,dc=unixville,dc=com" -i /full/path/to/import.ldif</TT><BR>
Import data in ldiff format. Typically req to be importing a specific section of the domain.
It will <EM>overwrite</EM> data that already exist under the subtree of the import.
The import has to be done when the directory server is turned off.
If using replication with multiple servers, the other machines
need to be re-init from this master server that did the import.
<BR>
<BR>
<A NAME=ldif></A>
<H2>LDIF</H2>
LDIF is the standard data exchange format. It is a simple ASCII file
with special text formatting.
Each entry has a dn. Different entries are separated by blank lines.
line that begin with a space is considered to be continuation of
previous line, which are typically wrapped at 80 chars.
Anything not presentable in standard ASCII will be uuencoded in base64.
<BR>
Besides LDIF, there is also format based on the XML standard called ____. It seems
to be seldom used.
<BR>
< !--
<BR>
<!--
# additional objects from NIS maps that Solaris 10 will query
# network and netmasks
dn: ipNetworkNumber=172.27.33.0,ou=Networks,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
cn: vlan33
ipnetworknumber: 172.27.33.0
objectclass: top
objectclass: ipNetwork
description: vlan 33 in SC
ipnetmasknumber: 255.255.255.0
# The "Ethers" container to host the next entry
# Unlike Hosts, Services, etc, the PADL migration script does not define this object
# in base.ldif
dn: ou=Ethers,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
ou: Networks
objectClass: top
objectClass: organizationalUnit
objectClass: domainRelatedObject
associatedDomain: hybridauto.com
# bootparams and ether
dn: cn=jumpstart-client-test,ou=Ethers,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
bootparameter: root=jumpstart2:/jumpstart/OS
objectclass: top
objectclass: device
objectclass: bootableDevice
objectclass: ieee802Device
cn: jumpstart-client-test
# publickey
dn: cn=publicKeyEg+ipHostNumber=200.20.20.88,ou=Hosts,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
cn: publicKeyEg
iphostnumber: 200.20.20.88
description: Joe Smith Sample Only - orig example cn refered to host
nispublickey: 9cc01614d929848849add28d090acdaa1c78270aeec969c9
nissecretkey: 9999999998769c999c39e7a6ed4e7afd687d4b99908b4de99
objectclass: top
objectclass: NisKeyObject
objectclass: device
objectclass: ipHost
-->
Additional example of ldif file for various objects can be found at:
<A HREF="http://docs.sun.com/app/docs/doc/816-4556/6maort2ro?a=view">
http://docs.sun.com/app/docs/doc/816-4556/6maort2ro?a=view</A>
<BR><BR>
<A ID="fedora-ds"></A>
<H1>FEDORA-DS</H1>
Fedora Directory Server is the open source version of RedHat Directory Server.<BR>
The RH DS came from the Netscape Directory Server (6.1). The Netscape DS was also developed
by Sun and branded as iPlanet DS and later Sun ONE DS. HP also repackage the Netscape/Red Hat DSwith their LDAP-UX. Thus, these products are largely the same.
<BR>
<A ID="GUI"></A>
<H2>GUI Console</H2>
Fedora DS has a Graphical Console. There is two piece to it, an app/web server that typically configured to listen on port 5555, which can be started as: <BR>
<TT>
cd /opt/fedora-ds <BR>
./start-admin<BR>
</TT>
And a client part. A web browser can point to http://ldapsvr:5555/ and get lightweight ldap server queries, or use the full featured java client
which get started as:
<TT>
cd /opt/fedora-ds <BR>
./startconsole<BR>
</TT>
The GUI console can be used to perform admin task on the Directory Server configuration or for modifying data in the LDAP data tree.
Below are several examples of adding objects in the "database" tab.
<BR><BR>
<H4>Add Unix User</H4>
Right click on the People OU, click <TT>new, user</TT>. For Unix user, check on the Posix Account entry. Furthermore, go to advance attributes and add the "shadowAccount" attribute.
<BR><BR>
<H4>Add Unix Group</H4>
Right click on the Groups OU, click <TT>new, other object, posix group</TT>.
<BR><BR>
<A ID="GUI_automount"></A>
<H4>Add Automount Map</H4>
automount map is for defining an entirely new set of automount entries, such as /import, /products, etc.
<BR>
Here is an example for defining automount maps in LDAP for the first time,
adding a auto.master, auto_master and finally a sample indirect map for /nfshome .
<I>Pay special attention to dot(.) vs underscore(_) below.</I>
<BR>
<OL>
<BR><EM>Defining auto.master</EM> (master map used by Linux, AIX and HP-UX?)
<LI>Right click on the desired OU where the automount map should be added (eg, ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com)
<LI>Click <TT>new, other object, automountMap</TT>
<LI>Enter "<TT>auto.master</TT>" in the automountMapName field.
<LI>Then, inside this newly created auto.master object, right click, <TT> new, other object, automount</TT>
<LI>In the automountInformation field, enter info like "<TT>ldap:automountMapName=auto_nfshome,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com</TT>"
<LI>In the automountkey field, enter "<TT>/nfshome</TT>"
<BR><BR><EM>Defining auto<STRONG>_</STRONG>master</EM> (master map used by Solaris?)<BR>
<LI>Right click on the desired OU, as in step 1 above
<LI>Click <TT>new, other object, automountMap</TT>
<LI>Enter "<TT>auto_master</TT>" in the automountMapName field.
<LI>Then, inside this newly created auto_master object, right click, <TT> new, other object, automount</TT>
<LI>In the automountInformation field, enter info like "<TT>auto_nfshome</TT>"
<LI>In the automountkey field, enter "<TT>/nfshome</TT>"
<BR><BR><EM>Defining auto_nfshome</EM> (indirect map used by all systems)
<LI>Right click on the desired OU, as in step 1 above
<LI>Click <TT>new, other object, automountMap</TT>
<LI>Enter "<TT>auto_nfshome</TT>" in the automountMapName field.
<LI>Entries in auto_nfshome will be added in the section below "Add Automount Entry".
</OL>
The info can be verified by using ldapsearch and compare it against the ldif used in the
ldapadd section
<A HREF="#ldapadd_automount">above</A>.
<BR><BR>
<H4>Add Automount Entry</H4>
Sample automount entries would be the various user's home dir that are defined under /home.
Thus, /nfshome/tin with content of nfssvr:/export/home/tin would be one automount entry. <BR>
For user home directory that need atuomount entry to define which server to use for the actual mount,
To add a new entry:
<OL>
<LI>right click on the desired automount map (eg auto_nfshome)
<LI>click <TT>new, other object, automount</TT>.
<LI>Enter the mount key into the automountKey field
<LI>Enter mount path info and mount option into the automountInformation field
</OL>
<BR>
<A ID="password_encryption"></A>
<H4>Change Default Posix (Unix) Password Encryption</H4>
When creating unix user account using the GUI console, the password strings need to be encrypted in the same method that client OS expectes them to. While newer OS can support MD5 or SSHA, CRYPT is still the universal standard. Thus, it is best to set the console to encrypt user password using CRYPT by default. Solaris NIS use CRYPT by default.
<BR><BR>
Method 1 - What Red Hat consultant told me and I know it works:
<BR>
<OL>
<LI>Go to the Directory tab
<LI>Click on the config node in the tree, right click, select advance properties (in a nutshell, we are editing the properties for the node <TT>cn=config</TT>.
<LI>Scroll to the bottom where the attribute "passwordStorageScheme" is listed. By default, it says SSHA. Change it to say "<TT>CRYPT</TT>"
</OL>
Method 2 - What is described by the Admin Guide:
<BR>
<OL>
<LI>Go to Config tab,
<LI>Data node in the LDAP tree.
<LI>On right side, go to Password tab. Toward the bottom, it has option to choose
password encryption policy. The default is SSHA, change it to CRYPT.
</OL>
<BR>
To verify that default password is created using CRYPT, perform a password change on a test user, then perform ldapsearch on this user using the <TT>cn=Directory Manager</TT> credentials. Encryption method is prefixed as {CRYPT} or {SSHA}.
<A ID="backup"></A>
<H2>Backing up DB</H2>
<PRE>
/opt/fedora-ds/slapd-SVR/db2bak # run the backup
/opt/fedora-ds/slapd-SVR/bak/DATE/ # dir where the files are stored (mostly Berkeley DB files)
</PRE>
<H2>Index</H2>
Some fields are not indexed by default, and when used as a NIS replacement,
having these indexes would greatly improve performance.
<UL>
<LI>gidnumber
<LI>uidnumber
</UL>
<BR>
To create indexes,
<OL>
<LI>Go to config tab
<LI>Click on "data" on the ldap tree
<LI>Expand to the desired database container config, indexes tab should appear
on right
<LI>Click on attribute, and select the attribute that should be added to the
index.
<LI>Typically, equality is the box that need to be checked for indexing to be
performed on.
</OL>
The above steps need to be done on each LDAP server, on each database
repository (eg when different domains/OU use different database backend).
<BR><BR>
<H2>Replication Conflicts </H2>
Records from replications with conflicts are marked by nsds5ReplConflict.
If the conflicts are specific to a single domain (and espcially in a dedicated
consumer), the easiest way to remove them is to "Initialize the Consumer" from
the Replication Config.
<BR><BR>
Otherwise, refers to
<A HREF="http://www.redhat.com/docs/manuals/dir-server/ag/7.1/replicat.html#1106141">
http://www.redhat.com/docs/manuals/dir-server/ag/7.1/replicat.html#1106141</A>
<BR><BR>
<A ID="replication"></A>
<H2>Replication Agreement</H2>
<BR>
Example of setting up a new server for a new domain, and adding replication.
<table width="100%" border="1">
<tr>
<td>Step#</td>
<td>Central Master Server (eg ldap1)</td>
<td>Local Replica (new server, eg ldap3)</td>
</tr>
<tr>
<td colspan="3">I. Setup Directory Server Admin metadata</td>
<tr>
<td>0</td>
<td> </td>
<td>
Run ./setup to configure the directory server. <BR>
Enable "Change Log",
db dir = /opt/redhat-ds/slapd-ldap*/changelogdb/ (owned by nobody:nobody, chmod
755)<BR>
restart slapd <BR>
</td>
</tr>
<tr>
<td>1</td>
<td> </td>
<td>Create user "uid=replication manager" under "cn=config"
(in Directory tab)</td>
</tr>
<tr>
<td>2</td>
<td> </td>
<td>Remove unecessary data from the directory tree (eg: People, Group, Special
users)</td>
</tr>
<tr>
<td>3</td>
<td> </td>
<td>
For replication, userRoot, ensure to
<li>check "Enable Replica"
<li>uid=replication manager,cn=config
<li>dedicated consumer
</td>
</tr>
<tr>
<td>4</td>
<td>
<p>Replicate "userRoot" data to the new server</p>
<p>This will setup the root dc=hybridauto,dc=com to the new remote server.</p>
</td>
<td> </td>
</tr>
<tr>
<td colspan="3">II. Replicate existing domain/database to new server</td>
</tr>
<tr>
<td>5</td>
<td> </td>
<td>In config tab, create databases matching all desired subsuffices for the data/domain that
wish to be made available in this new server</td>
</tr>
<tr>
<td>6</td>
<td> </td>
<td>Check to ensure all subsuffix for db defined above exist, they should have been replicated from Part I.
</td>
</tr>
<tr>
<td>7</td>
<td> </td>
<td>Enable replication (on Local Replica, this would typically be dedicated
consumer, so read-only). </td>
</tr>
<tr>
<td>8</td>
<td>Add replication agreement for each database/domain defined in step 5.</td>
<td> </td>
</tr>
<tr>
<td colspan="3">III. Setting up new domain, getting data to new server</td>
</tr>
<tr>
<td>9</td>
<td>In config tab, create new subsuffix with db for it. eg, create ou=seattle,ou=on,ou=na,dc=hybridauto,dc=com</td>
<td> </td>
</tr>
<tr>
<td>10</td>
<td>In database tab, create a matching subsuffix</td>
<td> </td>
</tr>
<tr>
<td>11</td>
<td>Enable replication. (On Central Master Server and Backup Master Server,
this would need to be a "multi-master" replicatoin)</td>
<td> </td>
</tr>
<tr>