summaryrefslogtreecommitdiff
path: root/docs/guide/Chap09-AddingUNIXClients.xml
blob: 379e4e2f3735af226a5c9597f1f1c9f1754e3293 (plain)
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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
		"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [

  <!-- Stuff for xincludes -->
  <!ENTITY % xinclude SYSTEM "../entities/xinclude.dtd">
  %xinclude;

  <!-- entities files to use -->
  <!ENTITY % global_entities SYSTEM '../entities/global.entities'>
  %global_entities;

]>

<chapter id="unixclients">
  <title>Adding UNIX/LINUX Servers and Clients</title>

    <para><indexterm>
	<primary>Open Magazine</primary>
      </indexterm><indexterm>
	<primary>survey</primary>
      </indexterm>
	The most frequently discussed Samba subjects over the past two years have focused around Domain Control and printing. 
	It is well known that Samba is a file and print server. A recent survey conducted by Open Magazine found 
	that of all respondents: 97% use Samba for file and print services, and 68% use Samba for Domain Control. See the 
	<ulink url="http://www.open-mag.com/cgi-bin/opencgi/surveys/survey.cgi?survey_name=samba">Open-Mag</ulink>
	Web site for current information. The survey results as found on January 14, 2004, as shown in
	<link linkend="ch09openmag"/>.
	</para>

<figure id="ch09openmag">
	<title>Open Magazine Samba Survey</title>
	<mediaobject>
		<imageobject role="latex">
			<imagedata fileref="guide/images/openmag.png" scale="60" scalefit="1"/>
		</imageobject>
		<imageobject>
			<imagedata fileref="guide/images/openmag.png" scale="60" scalefit="1"/>
		</imageobject>
	</mediaobject>
</figure>

	<para>
	While Domain Control is an exciting subject, basic file and print sharing remains the staple bread-and-butter
	function that Samba provides. Yet this book may give the appearance of having focused too much on more
	exciting aspects of Samba deployment. This chapter directs your attention to provide important information on
	the addition of Samba servers into your present Windows network &smbmdash; whatever the controlling technology
	may be. So let's get back to Abmas and our good friends Bob Jordan and company.
	</para>

<sect1>
	<title>Introduction</title>

      <para><indexterm>
	  <primary>Linux desktop</primary>
	</indexterm><indexterm>
	  <primary>Domain Member</primary>
	  <secondary>server</secondary>
	</indexterm>
	Bob Jordan looks back over the achievements of the past year or two. Daily events are rather straightforward
	with not too many distractions or problems. Bob, your team is doing well, but a number of employees
	are asking for Linux desktop systems. Your network has grown and demands additional Domain Member servers. Let's
	get on with this; Christine and Stan are ready to go.
	</para>

      <para><indexterm>
	  <primary>Domain Member</primary>
	  <secondary>desktop</secondary>
	</indexterm>
	Stan Soroka is firmly in control of the Department of the Future, while Christine is enjoying a stable and
	predictable network environment. It is time to add more servers and to add Linux desktops. It is
	time to meet the demands of future growth and endure trial by fire. Go on, walk the steps
	with Stan and Company.
	</para>

	<sect2>
	<title>Assignment Tasks</title>

	<para><indexterm>
	    <primary>Active Directory</primary>
	  </indexterm>
	You must now add UNIX/Linux Domain Member servers to your network. You have a friend who has a Windows 2003
	Active Directory Domain network who wants to add a Samba/Linux server and has asked Christine to help him
	out. Your real objective is to help Christine to see more of the way the Microsoft world lives and use
	her help to get validation that Samba really does live up to expectations.
	</para>

	<para>
	Over the past six months, you have hired several new staff who want Linux on their desktops. You must integrate
	these systems to make sure that Abmas is not building islands of technology. You ask Christine to
	do likewise at Swodniw Biz NL (your friend's company) to help them to evaluate a Linux desktop. You want to make
	the right decision, don't you?
	</para>

	</sect2>
</sect1>

<sect1>
	<title>Dissection and Discussion</title>

      <para><indexterm>
	  <primary>winbind</primary>
	</indexterm>
	Recent Samba mailing list activity is witness to how many sites are using winbind. Some have no trouble
	at all with it, yet to others the problems seem insurmountable. Periodically there are complaints concerning
	an inability to achieve identical user and group IDs between Windows and UNIX environments.
	</para>

	<para>
	You provide step-by-step implementations of the various tools that can be used for identity
	resolution. You also provide working examples of solutions for integrated authentication for
	both UNIX/Linux and Windows environments.
	</para>

	<sect2>
		<title>Technical Issues</title>

		<para>
		One of the great challenges we face when people ask us, <quote>What is the best way to solve
		this problem?</quote> is to get beyond the facts so we can not only clearly comprehend
		the immediate technical problem, but also understand how needs may change.
		</para>

	<para><indexterm>
	    <primary>integrate</primary>
	  </indexterm>
		There are a few facts we should note when dealing with the question of how best to
		integrate UNIX/Linux clients and servers into a Windows networking environment:
		</para>

		<itemizedlist>
	  <listitem><para><indexterm>
		<primary>Domain Controller</primary>
	      </indexterm><indexterm>
		<primary>authoritative</primary>
	      </indexterm><indexterm>
		<primary>accounts</primary>
		<secondary>authoritative</secondary>
	      </indexterm><indexterm>
		<primary>PDC</primary>
	      </indexterm><indexterm>
		<primary>BDC</primary>
	      </indexterm>
			A Domain Controller (PDC or BDC) is always authoritative for all accounts in its Domain.
			This means that a BDC must (of necessity) be able to resolve all account UIDs and GIDs
			to the same values that the PDC resolved them to.
			</para></listitem>

	  <listitem><para><indexterm>
		<primary>local accounts</primary>
	      </indexterm><indexterm>
		<primary>Domain Member</primary>
		<secondary>authoritative</secondary>
		<tertiary>local accounts</tertiary>
	      </indexterm><indexterm>
		<primary>Domain accounts</primary>
	      </indexterm><indexterm>
		<primary>winbindd</primary>
	      </indexterm>
			A Domain Member can be authoritative for local accounts, but is never authoritative for
			Domain accounts. If a user is accessing a Domain Member server and that user's account
			is not known locally, the Domain Member server must resolve the identity of that user
			from the Domain in which that user's account resides. It must then map that ID to a
			UID/GID pair that it can use locally. This is handled by <command>winbindd</command>.
			</para></listitem>

			<listitem><para>
			Samba, when running on a Domain Member server, can resolve user identities from a
			number of sources:

			<itemizedlist>
		<listitem><para><indexterm>
		      <primary>getpwnam</primary>
		    </indexterm><indexterm>
		      <primary>getgrnam</primary>
		    </indexterm><indexterm>
		      <primary>NSS</primary>
		    </indexterm><indexterm>
		      <primary>LDAP</primary>
		    </indexterm><indexterm>
		      <primary>NIS</primary>
		    </indexterm>
				By executing a system <command>getpwnam()</command> or <command>getgrnam()</command> call. 
				On systems that support it, this utilizes the name service switch (NSS) facility to 
				resolve names according to the configuration of the <filename>/etc/nsswitch.conf</filename> 
				file. NSS can be configured to use LDAP, winbind, NIS, or local files.
				</para></listitem>

		<listitem><para><indexterm>
		      <primary>passdb backend</primary>
		    </indexterm><indexterm>
		      <primary>PADL</primary>
		    </indexterm><indexterm>
		      <primary>nss_ldap</primary>
		    </indexterm>
				Performing, via NSS, a direct LDAP search (where an LDAP passdb backend has been configured).
				This requires the use of the PADL nss_ldap tool (or equivalent).
				</para></listitem>

		<listitem><para><indexterm>
		      <primary>winbindd</primary>
		    </indexterm><indexterm>
		      <primary>SID</primary>
		    </indexterm><indexterm>
		      <primary>winbindd_idmap.tdb</primary>
		    </indexterm><indexterm>
		      <primary>winbindd_cache.tdb</primary>
		    </indexterm>
				Directly by querying <command>winbindd</command>. The <command>winbindd</command>
				contact a Domain Controller to attempt to resolve the identity of the user or group. It
				receives the Windows networking security identifier (SID) for that appropriate
				account and then allocates a local UID or GID from the range of available IDs and
				creates an entry in its <filename>winbindd_idmap.tdb</filename> and 
				<filename>winbindd_cache.tdb</filename> files.
				</para>

		  <para><indexterm>
		      <primary>idmap backend</primary>
		    </indexterm><indexterm>
		      <primary>mapping</primary>
		    </indexterm>
				If the parameter 
			<smbconfoption><name>idmap backend</name><value>ldap:ldap://myserver.domain</value></smbconfoption>
				was specified and the LDAP server has been configured with a container in which it may
				store the IDMAP entries, all Domain Members may share a common mapping.
				</para></listitem>
			</itemizedlist>
			</para>

			<para>
			Irrespective of how &smb.conf; is configured, winbind creates and caches a local copy of
			the ID mapping database. It uses the <filename>winbindd_idmap.tdb</filename>, and
                                <filename>winbindd_cache.tdb</filename> files to do this.
			</para>

			<para>
			Which of the above resolver methods is chosen is determined by the way that Samba is configured 
			in the &smb.conf; file. Some of the configuration options are rather less than obvious to the 
			casual user.
			</para></listitem>

	  <listitem><para><indexterm>
		<primary>winbind enable local accounts</primary>
	      </indexterm><indexterm>
		<primary>Domain Member</primary>
		<secondary>servers</secondary>
	      </indexterm><indexterm>
		<primary>Domain Controllers</primary>
	      </indexterm>
			If you wish to make use of accounts (users and/or groups) that are local to (i.e., capable
			of being resolved using) the name service switch (NSS) facility, it is imperative to use the 
			<smbconfoption><name>winbind enable local accounts</name><value>Yes</value></smbconfoption>
			in the &smb.conf; file. This parameter specifically applies only to Domain Controllers, 
			not to Domain Member servers.
			</para></listitem>
		</itemizedlist>

	<para><indexterm>
	    <primary>Posix accounts</primary>
	  </indexterm><indexterm>
	    <primary>Samba accounts</primary>
	  </indexterm><indexterm>
	    <primary>LDAP</primary>
	  </indexterm>
		For many administrators, it should be plain that the use of an LDAP-based repository for all network
		accounts (both for Posix accounts as well as for Samba accounts) provides the most elegant and
		controllable facility. You eventually appreciate the decision to use LDAP.
		</para>

	<para><indexterm>
	    <primary>nss_ldap</primary>
	  </indexterm><indexterm>
	    <primary>identifiers</primary>
	  </indexterm><indexterm>
	    <primary>resolve</primary>
	  </indexterm>
		If your network account information resides in an LDAP repository, you should use it ahead of any
		alternative method. This means that if it is humanly possible to use the <command>nss_ldap</command>
		tools to resolve UNIX account UIDs/GIDs via LDAP, this is the preferred solution, as it provides
		a more readily controllable method for asserting the exact same user and group identifiers 
		throughout the network.
		</para>

		<para><indexterm>
	    <primary>Domain Member</primary>
	    <secondary>server</secondary>
	  </indexterm><indexterm>
	    <primary>winbind trusted domains only</primary>
	  </indexterm><indexterm>
	    <primary>getpwnam</primary>
	  </indexterm><indexterm>
	    <primary>smbd</primary>
	  </indexterm><indexterm>
	    <primary>Trusted Domains</primary>
	  </indexterm><indexterm>
	    <primary>External Domains</primary>
	  </indexterm>
		In the situation where UNIX accounts are held on the Domain Member server itself, the only effective
		way to use them involves the &smb.conf; entry 
		<smbconfoption><name>winbind trusted domains only</name><value>Yes</value></smbconfoption>. This forces 
		Samba (<command>smbd</command>) to perform a <command>getpwnam()</command> system call that can
		then be controlled via <filename>/etc/nsswitch.conf</filename> file settings. The use of this parameter
		disables the use of Samba with Trusted Domains (i.e., External Domains).
		</para>

	<para><indexterm>
	    <primary>appliance mode</primary>
	  </indexterm><indexterm>
	    <primary>Domain Member</primary>
	    <secondary>server</secondary>
	  </indexterm><indexterm>
	    <primary>winbindd</primary>
	  </indexterm><indexterm>
	    <primary>automatically allocate</primary>
	  </indexterm>
	        Winbind can be used to create an appliance mode Domain Member server. In this capacity, <command>winbindd</command>
		is configured to automatically allocate UIDs/GIDs from numeric ranges set in the &smb.conf; file. The allocation
		is made for all accounts that connect to that Domain Member server, whether within its own Domain or from
		Trusted Domains. If not stored in an LDAP backend, each Domain Member maintains its own unique mapping database.
		This means that it is almost certain that a given user who accesses two Domain Member servers does not have the
		same UID/GID on both servers &smbmdash; however, this is transparent to the Windows network user. This data
		is stored in the <filename>winbindd_idmap.tdb</filename> and <filename>winbindd_cache.tdb</filename> files.
		</para>
	
	<para><indexterm>
	    <primary>mapping</primary>
	  </indexterm>
		The use of an LDAP backend for the Winbind IDMAP facility permits Windows Domain security identifiers (SIDs)
		mappings to UIDs/GIDs to be stored centrally. The result is a consistent mapping across all Domain Member
		servers so configured. This solves one of the major headaches for network administrators who need to copy
		files between/across network file servers.
		</para>

	</sect2>

	<sect2>
		<title>Political Issues</title>

	<para><indexterm>
	    <primary>OpenLDAP</primary>
	  </indexterm><indexterm>
	    <primary>NIS</primary>
	  </indexterm><indexterm>
	    <primary>yellow pages</primary>
	    <see>NIS</see>
	  </indexterm><indexterm>
	    <primary>identity management</primary>
	  </indexterm>
		One of the most fierce conflicts recently being waged is one of resistance to the adoption of LDAP, in
		particular OpenLDAP, as a replacement for UNIX NIS (previously called Yellow Pages). Let's face it, LDAP
		is different and requires a new approach to the need for a better identity management solution. The more
		you work with LDAP, the more its power and flexibility emerges from its dark, cavernous chasm.
		</para>

		<para>
		LDAP is a most suitable solution for heterogenous environments. If you need crypto, add Kerberos. 
		The reason these are preferable is because they are heterogenous. Windows solutions of this sort are NOT 
		heterogenous by design. This is fundamental &smbmdash; it isn't religious or political. This also doesn't say that 
		you can't use Windows Active Directory in a heterogenous environment &smbmdash; it can be done, it just requires 
		commercial integration products &smbmdash; it's just not what Active Directory was designed for.
		</para>

	<para><indexterm>
	    <primary>directory</primary>
	  </indexterm><indexterm>
	    <primary>management</primary>
	  </indexterm>
		A number of long-term UNIX devotees have recently commented in various communications that the Samba Team
		is the first application group to almost force network administrators to use LDAP. It should be pointed
		out that we resisted this as long as we could. It is not out of laziness or out of malice that LDAP has
		finally emerged as the preferred identity management backend for Samba. We recommend LDAP for your total
		organizational directory needs.
		</para>

	</sect2>

</sect1>

<sect1>
	<title>Implementation</title>

      <para><indexterm>
	  <primary>Domain Member</primary>
	  <secondary>server</secondary>
	</indexterm><indexterm>
	  <primary>Domain Member</primary>
	  <secondary>client</secondary>
	</indexterm><indexterm>
	  <primary>Domain Controller</primary>
	</indexterm>
	The Domain Member server and the Domain Member client are at the center of focus in this chapter.
	Configuration of Samba-3 Domain Controller has been covered in earlier chapters, so if your 
	interest is in Domain Controller configuration, you will not find that here. You will find good
	oil that helps you to add Domain Member servers and clients.
	</para>

      <para><indexterm>
	  <primary>Domain Member</primary>
	  <secondary>workstations</secondary>
	</indexterm>
	In practice, Domain Member servers and Domain Member workstations are very different entities, but in
	terms of technology they share similar core infrastructure. A technologist would argue that servers
	and workstations are identical. Many users would argue otherwise, given that in a well-disciplined
	environment a workstation (client) is a device from which a user creates documents and files that
	are located on servers. A workstation is frequently viewed as a disposable (easy to replace) item,
	but a server is viewed as a core component of the business.
	</para>

      <para><indexterm>
	  <primary>workstation</primary>
	</indexterm>
	One can look at this another way. If a workstation breaks down, one user is affected, but if a
	server breaks down, hundreds of users may not be able to work. The services that a workstation
	must provide are document and file production oriented; a server provides information storage
	and is distribution oriented.
	</para>

      <para><indexterm>
	  <primary>authentication process</primary>
	</indexterm><indexterm>
	  <primary>logon process</primary>
	</indexterm><indexterm>
	  <primary>user identities</primary>
	</indexterm>
	<emphasis>Why is this important?</emphasis> &smbmdash; For starters, we must identify what
	components of the operating system and its environment must be configured. Also, it is necessary
	to recognize where the interdependencies between the various services to be used are.
	In particular, it is important to understand the operation of each critical part of the
	authentication process, the logon process, and how user identities get resolved and applied
	within the operating system and applications (like Samba) that depend on this and may
	actually contribute to it.
	</para>

	<para>
	So, while here we demonstrate how to implement the technology. It is done within a context of
	what type of service need must be fulfilled.
	</para>

	<sect2 id="sdcsdmldap">
		<title>Samba Domain with Samba Domain Member Server &smbmdash; Using LDAP</title>

	<para><indexterm>
	    <primary>ldapsam</primary>
	  </indexterm><indexterm>
	    <primary>ldapsam backend</primary>
	  </indexterm><indexterm>
	    <primary>IDMAP</primary>
	  </indexterm><indexterm>
	    <primary>mapping</primary>
	    <secondary>consistent</secondary>
	  </indexterm><indexterm>
	    <primary>winbindd</primary>
	  </indexterm><indexterm>
	    <primary>foreign SID</primary>
	  </indexterm>
	In this example, it is assumed that you have Samba PDC/BDC servers. This means you are using
	an LDAP ldapsam backend. In this example, we are adding to the LDAP backend database (directory)
	containers for use by the IDMAP facility. This makes it possible to have globally consistent
	mapping of SIDs to/from UIDs/GIDs. This means that you are running <command>winbindd</command>
	as part of your configuration. The primary purpose of running <command>winbindd</command> (within
	this operational context) is to permit mapping of foreign SIDs (those not originating from our 
	own Domain). Foreign SIDs can come from any external Domain or from Windows clients that do not 
	belong to a Domain.
	</para>

	<para><indexterm>
	    <primary>winbindd</primary>
	  </indexterm><indexterm>
	    <primary>getpwnam</primary>
	  </indexterm><indexterm>
	    <primary>NSS</primary>
	  </indexterm>
	If your installation is accessed only from clients that are members of your own domain, then
	it is not necessary to run <command>winbindd</command> as long as all users can be resolved
	locally via the <command>getpwnam()</command> system call. On NSS-enabled systems, this condition
	is met by having:
	</para>

	<itemizedlist>
	  <listitem><para><indexterm>
		<primary>/etc/passwd</primary>
	      </indexterm><indexterm>
		<primary>/etc/group</primary>
	      </indexterm>
		All accounts in <filename>/etc/passwd</filename> or in <filename>/etc/group</filename>.
		</para></listitem>

	  <listitem><para><indexterm>
		<primary>NSS</primary>
	      </indexterm><indexterm>
		<primary>compat</primary>
	      </indexterm><indexterm>
		<primary>compat</primary>
	      </indexterm><indexterm>
		<primary>ldap</primary>
	      </indexterm><indexterm>
		<primary>nis</primary>
	      </indexterm><indexterm>
		<primary>nisplus</primary>
	      </indexterm><indexterm>
		<primary>hesoid</primary>
	      </indexterm><indexterm>
		<primary>ldap</primary>
	      </indexterm><indexterm>
		<primary>nss_ldap</primary>
	      </indexterm><indexterm>
		<primary>PADL Software</primary>
	      </indexterm>
		Resolution via NSS. On NSS-enabled systems, there is usually a facility to resolve IDs
		via multiple methods. The methods typically include: <command>files, compat, db, ldap, 
		nis, nisplus, hesoid.</command>  When correctly installed, Samba adds to this list
		the <command>winbindd</command> facility. The ldap facility is frequently the nss_ldap
		tool provided by PADL Software.
		</para></listitem>
	</itemizedlist>

	<para><indexterm>
	    <primary>Identity resolution</primary>
	  </indexterm>
	The diagram in <link linkend="ch9-sambadc"/> demonstrates the relationship of samba and system 
	components that are involved in the Identity resolution process where Samba is used as a Domain
	Member server within a Samba Domain Control network.
	</para>

<figure id="ch9-sambadc">
	<title>Samba Domain: Samba Member Server</title>
	<mediaobject>
		<imageobject role="latex">
			<imagedata fileref="guide/images/chap9-SambaDC.png" scale="75" scalefit="1"/>
		</imageobject>
		<imageobject>
			<imagedata fileref="guide/images/chap9-SambaDC.png" scale="75" scalefit="1"/>
		</imageobject>
	</mediaobject>
</figure>

	<para><indexterm>
	    <primary>IDMAP</primary>
	  </indexterm><indexterm>
	    <primary>foreign</primary>
	  </indexterm>
	In this example configuration, Samba will directly search the LDAP-based passwd backend ldapsam
	to obtain authentication and user identity information. The IDMAP information is stored in the LDAP
	backend so that it can be shared by all Domain Member servers so that every user will have a
	consistent UID and GID across all of them. The IDMAP facility will be used for all foreign
	(i.e., not having the same SID as the Domain it is a member of) Domains. The configuration of 
	NSS will ensure that all unix processes will obtain a consistent UID/GID.
	</para>

	<para>
	The instructions given here apply to the Samba environment as shown in Chapters 6 and 7.
	If your network does not have an LDAP slave server (i.e., Chapter 6 configuration), you
	must change the target LDAP server from <constant>lapdc</constant> to <constant>massive.</constant>
	</para>

	<procedure>
	<title>Configuration of LDAP-Based Identity Resolution</title>

		<step><para>
		Create the &smb.conf; file as shown in <link linkend="ch9-sdmsdc"/>. Locate
		this file in the directory <filename>/etc/samba</filename>.
		</para></step>

	  <step><para><indexterm>
		<primary>ldap.conf</primary>
	      </indexterm>
		Configure the file that will be used by <constant>nss_ldap</constant> to
		locate and communicate with the LDAP server. This file is called <filename>ldap.conf</filename>.
		If your implementation of <constant>nss_ldap</constant> is consistent with
		the defaults suggested by PADL (the authors), it will be located in the
		<filename>/etc</filename> directory. On some systems, the default location is
		the <filename>/etc/openldap</filename> directory. Change the parameters inside
		the file that is located on your OS so it matches <link linkend="ch9-sdmlcnf"/>.
		To find the correct location of this file, you can obtain this from the
		library that will be used by executing the following:
<screen>
&rootprompt; strings /lib/libnss_ldap* | grep ldap.conf
/etc/ldap.conf
</screen>
		</para></step>

		<step><para>
		Configure the name service switch (NSS) control file so it matches the one shown
		in <link linkend="ch9-sdmnss"/>.
		</para></step>

	  <step><para><indexterm>
		<primary>Identity resolution</primary>
	      </indexterm><indexterm>
		<primary>getent</primary>
	      </indexterm>
		Before proceeding to configure Samba, validate the operation of the NSS Identity 
		resolution via LDAP by executing:
<screen>
&rootprompt; getent passwd
...
root:x:0:512:Netbios Domain Administrator:/root:/bin/false
nobody:x:999:514:nobody:/dev/null:/bin/false
bobj:x:1000:513:Robert Jordan:/home/bobj:/bin/bash
stans:x:1001:513:Stanley Soroka:/home/stans:/bin/bash
chrisr:x:1002:513:Christine Roberson:/home/chrisr:/bin/bash
maryv:x:1003:513:Mary Vortexis:/home/maryv:/bin/bash
jht:x:1004:513:John H Terpstra:/home/jht:/bin/bash
bldg1$:x:1006:553:bldg1$:/dev/null:/bin/false
temptation$:x:1009:553:temptation$:/dev/null:/bin/false
vaioboss$:x:1005:553:vaioboss$:/dev/null:/bin/false
fran$:x:1008:553:fran$:/dev/null:/bin/false
josephj:x:1007:513:Joseph James:/home/josephj:/bin/bash
</screen>
		You should notice the location of the users' home directories. First, make certain that
		the home directories exist on the Domain Member server; otherwise, the home directory
		share is not available. The home directories could be mounted off a domain controller
		using NFS, or by any other suitable means. Second, the absence of the Domain name in the
		home directory path is indicative that Identity resolution is not being done via Winbind.
<screen>
&rootprompt; getent group
...
Domain Admins:x:512:root,jht
Domain Users:x:513:bobj,stans,chrisr,maryv,jht,josephj
Domain Guests:x:514:
Accounts:x:1000:
Finances:x:1001:
PIOps:x:1002:
sammy:x:4321:
</screen>
	      <indexterm>
		<primary>secondary group</primary>
	      </indexterm><indexterm>
		<primary>primary group</primary>
	      </indexterm><indexterm>
		<primary>group membership</primary>
	      </indexterm>
		This shows that all is working as it should. Notice that in the LDAP database
		the users primary and secondary group memberships are identical. It is not
		necessary to add secondary group memberships (in the group database) if the
		user is already a member via primary group membership in the password database.
		When using winbind, it is in fact undesirable to do this as it results in
		doubling up of group memberships and may break winbind under certain conditions.
		</para></step>

	  <step><para><indexterm>
		<primary>slapcat</primary>
	      </indexterm>
		The LDAP directory must have a container object for IDMAP data. There are several ways you can
		check that your LDAP database is able to receive IDMAP information. One of the simplest is to
		execute:
<screen>
&rootprompt; slapcat | grep -i idmap
dn: ou=Idmap,dc=abmas,dc=biz
ou: idmap
</screen>
	      <indexterm>
		<primary>ldapadd</primary>
	      </indexterm>
	        If the execution of this command does not return IDMAP entries, you need to create an LDIF
		template file (see <link linkend="ch9-ldifadd"/>). You can add the required entries using the following command:
<screen>
&rootprompt; ldapadd -x -D "cn=Manager,dc=abmas,dc=biz" \
		-w not24get &lt; /etc/openldap/idmap.LDIF
</screen>
		Samba automatically populates this LDAP directory container when it needs to.
		</para></step>

	  <step><para><indexterm>
		<primary>net</primary>
		<secondary>rpc</secondary>
		<tertiary>join</tertiary>
	      </indexterm><indexterm>
		<primary>Domain join</primary>
	      </indexterm>
		The system is ready to join the Domain. Execute the following:
<screen>
net rpc join -U root%not24et
Joined domain MEGANET2.
</screen>
		This indicates that the Domain join succeeded.
		</para></step>

		<step><para>
		You may now start Samba in the usual manner and your Samba Domain Member server
		is ready for use. Just add shares as required.
		</para></step>

	</procedure>

<smbconfexample id="ch9-sdmsdc">
<title>Samba Domain Member in Samba Domain Control Context &smbmdash; &smb.conf; File</title>
<smbconfcomment>Global parameters</smbconfcomment>
<smbconfsection>[global]</smbconfsection>
<smbconfoption><name>unix charset</name><value>LOCALE</value></smbconfoption>
<smbconfoption><name>workgroup</name><value>MEGANET2</value></smbconfoption>
<smbconfoption><name>security</name><value>DOMAIN</value></smbconfoption>
<smbconfoption><name>username map</name><value>/etc/samba/smbusers</value></smbconfoption>
<smbconfoption><name>log level</name><value>10</value></smbconfoption>
<smbconfoption><name>syslog</name><value>0</value></smbconfoption>
<smbconfoption><name>log file</name><value>/var/log/samba/%m</value></smbconfoption>
<smbconfoption><name>max log size</name><value>50</value></smbconfoption>
<smbconfoption><name>smb ports</name><value>139 445</value></smbconfoption>
<smbconfoption><name>name resolve order</name><value>wins bcast hosts</value></smbconfoption>
<smbconfoption><name>printcap name</name><value>CUPS</value></smbconfoption>
<smbconfoption><name>wins server</name><value>192.168.2.1</value></smbconfoption>
<smbconfoption><name>ldap suffix</name><value>dc=abmas,dc=biz</value></smbconfoption>
<smbconfoption><name>ldap machine suffix</name><value>ou=People</value></smbconfoption>
<smbconfoption><name>ldap user suffix</name><value>ou=People</value></smbconfoption>
<smbconfoption><name>ldap group suffix</name><value>ou=Groups</value></smbconfoption>
<smbconfoption><name>ldap idmap suffix</name><value>ou=Idmap</value></smbconfoption>
<smbconfoption><name>ldap admin dn</name><value>cn=Manager,dc=abmas,dc=biz</value></smbconfoption>
<smbconfoption><name>idmap backend</name><value>ldap:ldap://lapdc.abmas.biz</value></smbconfoption>
<smbconfoption><name>idmap uid</name><value>10000-20000</value></smbconfoption>
<smbconfoption><name>idmap gid</name><value>10000-20000</value></smbconfoption>
<smbconfoption><name>winbind trusted domains only</name><value>Yes</value></smbconfoption>
<smbconfoption><name>printer admin</name><value>root</value></smbconfoption>
<smbconfoption><name>printing</name><value>cups</value></smbconfoption>

<smbconfsection>[homes]</smbconfsection>
<smbconfoption><name>comment</name><value>Home Directories</value></smbconfoption>
<smbconfoption><name>valid users</name><value>%S</value></smbconfoption>
<smbconfoption><name>read only</name><value>No</value></smbconfoption>
<smbconfoption><name>browseable</name><value>No</value></smbconfoption>

<smbconfsection>[printers]</smbconfsection>
<smbconfoption><name>comment</name><value>SMB Print Spool</value></smbconfoption>
<smbconfoption><name>path</name><value>/var/spool/samba</value></smbconfoption>
<smbconfoption><name>guest ok</name><value>Yes</value></smbconfoption>
<smbconfoption><name>printable</name><value>Yes</value></smbconfoption>
<smbconfoption><name>browseable</name><value>No</value></smbconfoption>

<smbconfsection>[print$]</smbconfsection>
<smbconfoption><name>comment</name><value>Printer Drivers</value></smbconfoption>
<smbconfoption><name>path</name><value>/var/lib/samba/drivers</value></smbconfoption>
<smbconfoption><name>admin users</name><value>root, Administrator</value></smbconfoption>
<smbconfoption><name>write list</name><value>root</value></smbconfoption>
</smbconfexample>

<example id="ch9-ldifadd">
<title>LDIF IDMAP Add-On Load File &smbmdash; File: /etc/openldap/idmap.LDIF</title>
<screen>
dn: ou=Idmap,dc=abmas,dc=biz
objectClass: organizationalUnit
ou: idmap
structuralObjectClass: organizationalUnit
</screen>
</example>

<example id="ch9-sdmlcnf">
<title>Configuration File for NSS LDAP Support &smbmdash; <filename>/etc/ldap.conf</filename></title>
<screen>
URI     ldap://massive.abmas.biz ldap://massive.abmas.biz:636
host    192.168.2.1
base    dc=abmas,dc=biz
binddn  cn=Manager,dc=abmas,dc=biz
bindpw  not24get

pam_password exop

nss_base_passwd ou=People,dc=abmas,dc=biz?one
nss_base_shadow ou=People,dc=abmas,dc=biz?one
nss_base_group  ou=Groups,dc=abmas,dc=biz?one
ssl     no
</screen>
</example>

<example id="ch9-sdmnss">
<title>NSS using LDAP for Identity Resolution &smbmdash; File: <filename>/etc/nsswitch.conf</filename></title>
<screen>
passwd:         compat ldap
group:          compat ldap

hosts:          files dns wins
networks:       files dns

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files
publickey:      files

bootparams:     files
automount:      files
aliases:        files
</screen>
</example>

	</sect2>

	<sect2 id="wdcsdm">
		<title>NT4/Samba Domain with Samba Domain Member Server &smbmdash; Using Winbind</title>

	<para>
	You need to use this method for creating a Samba Domain Member server if any of the following conditions
	prevail:
	</para>

	<itemizedlist>
		<listitem><para>
		LDAP support (client) is not installed on the system.
		</para></listitem>

		<listitem><para>
		There are mitigating circumstances forcing a decision not to use LDAP.
		</para></listitem>

		<listitem><para>
		The Samba Domain Member server must be part of a Windows NT4 Domain.
		</para></listitem>
	</itemizedlist>

	<para><indexterm>
	    <primary>Windows ADS Domain</primary>
	  </indexterm><indexterm>
	    <primary>Samba Domain</primary>
	  </indexterm><indexterm>
	    <primary>LDAP</primary>
	  </indexterm>
	Later in the chapter, you can see how to configure a Samba Domain Member server for a Windows ADS Domain.
	Right now your objective is to configure a Samba server that can be a member of a Windows NT4 style
	Domain and/or does not use LDAP.
	</para>

	<note><para><indexterm>
	      <primary>duplicate accounts</primary>
	    </indexterm>
	If you use <command>winbind</command> for Identity resolution, do make sure that there are no
	duplicate accounts.
	</para>

	  <para><indexterm>
	      <primary>/etc/passwd</primary>
	    </indexterm>
	For example, do not have more than one account that has UID=0 in the password database. If there 
	is an account called <constant>root</constant> in the <filename>/etc/passwd</filename> database, 
	it is okay to have an account called <constant>root</constant> in the LDAP ldapsam or in the 
	tdbsam. But if there are two accounts in the passdb backend that have the same UID, winbind will 
	break. This means that the <constant>Administrator</constant> account must be called 
	<constant>root</constant>.
	</para>

	  <para><indexterm>
	      <primary>/etc/passwd</primary>
	    </indexterm><indexterm>
	      <primary>ldapsam</primary>
	    </indexterm><indexterm>
	      <primary>tdbsam</primary>
	    </indexterm>
	Winbind will break if there is an account in <filename>/etc/passwd</filename> that has 
	the same UID as an account that is in LDAP ldapsam (or in tdbsam) but that differs in name only.
	</para></note>

	<para><indexterm>
	    <primary>credentials</primary>
	  </indexterm><indexterm>
	    <primary>traverse</primary>
	  </indexterm><indexterm>
	    <primary>wide-area</primary>
	  </indexterm><indexterm>
	    <primary>network</primary>
	    <secondary>wide-area</secondary>
	  </indexterm><indexterm>
	    <primary>tdbdump</primary>
	  </indexterm>
	The following configuration uses CIFS/SMB protocols alone to obtain user and group credentials.
	The winbind information is locally cached in the <filename>winbindd_cache.tdb winbindd_idmap.tdb</filename>
	files. This provides considerable performance benefits compared with the LDAP solution, particularly
	where the LDAP lookups must traverse wide-area network links. You may examine the contents of these
	files using the tool <command>tdbdump</command>, though you may have to build this from the Samba
	source code if it has not been supplied as part of a binary package distribution that you may be using.
	</para>

	<procedure>
	<title>Configuration of Winbind-Based Identity Resolution</title>

		<step><para>
		Using your favorite text editor, create the &smb.conf; file so it has the contents
		shown in <link linkend="ch0-NT4DSDM"/>.
		</para></step>

	  <step><para><indexterm>
		<primary>/etc/nsswitch.conf</primary>
	      </indexterm>
		Edit the <filename>/etc/nsswitch.conf</filename> so it has the entries shown in
		<link linkend="ch9-nsswbnd"/>.
		</para></step>

	  <step><para><indexterm>
		<primary>net</primary>
		<secondary>rpc</secondary>
		<tertiary>join</tertiary>
	      </indexterm>
		The system is ready to join the Domain. Execute the following:
<screen>
net rpc join -U root%not24et
Joined domain MEGANET2.
</screen>
                This indicates that the Domain join succeed.

		</para></step>

	  <step><para><indexterm>
		<primary>winbind</primary>
	      </indexterm><indexterm>
		<primary>wbinfo</primary>
	      </indexterm>
		Validate operation of <command>winbind</command> using the <command>wbinfo</command>
		tool as follows:
<screen>
&rootprompt; wbinfo -u
MEGANET2+root
MEGANET2+nobody
MEGANET2+jht
MEGANET2+maryv
MEGANET2+billr
MEGANET2+jelliott
MEGANET2+dbrady
MEGANET2+joeg
MEGANET2+balap
</screen>
		This shows that Domain users have been listed correctly.
<screen>
&rootprompt; wbinfo -g
MEGANET2+Domain Admins
MEGANET2+Domain Users
MEGANET2+Domain Guests
MEGANET2+Accounts
MEGANET2+Finances
MEGANET2+PIOps
</screen>
		This shows that Domain groups have been correctly obtained also.
		</para></step>

	  <step><para><indexterm>
		<primary>NSS</primary>
	      </indexterm><indexterm>
		<primary>getent</primary>
	      </indexterm><indexterm>
		<primary>winbind</primary>
	      </indexterm>
		The next step verifies that NSS is able to obtain this information
		correctly from <command>winbind</command> also.
<screen>
&rootprompt; getent passwd
...
MEGANET2+root:x:10000:10001:NetBIOS Domain Admin:
                      /home/MEGANET2/root:/bin/bash
MEGANET2+nobody:x:10001:10001:nobody:
                      /home/MEGANET2/nobody:/bin/bash
MEGANET2+jht:x:10002:10001:John H Terpstra:
                      /home/MEGANET2/jht:/bin/bash
MEGANET2+maryv:x:10003:10001:Mary Vortexis:
                      /home/MEGANET2/maryv:/bin/bash
MEGANET2+billr:x:10004:10001:William Randalph:
                      /home/MEGANET2/billr:/bin/bash
MEGANET2+jelliott:x:10005:10001:John G Elliott:
                      /home/MEGANET2/jelliott:/bin/bash
MEGANET2+dbrady:x:10006:10001:Darren Brady:
                      /home/MEGANET2/dbrady:/bin/bash
MEGANET2+joeg:x:10007:10001:Joe Green:
                      /home/MEGANET2/joeg:/bin/bash
MEGANET2+balap:x:10008:10001:Bala Pillay:
                      /home/MEGANET2/balap:/bin/bash
</screen>
		The user account information has been correctly obtained. This information has
		been merged with the winbind template information configured in the &smb.conf; file.
<screen>
&rootprompt;# getent group
...
MEGANET2+Domain Admins:x:10000:MEGANET2+root,MEGANET2+jht
MEGANET2+Domain Users:x:10001:MEGANET2+jht,MEGANET2+maryv,\
        MEGANET2+billr,MEGANET2+jelliott,MEGANET2+dbrady,\
        MEGANET2+joeg,MEGANET2+balap
MEGANET2+Domain Guests:x:10002:MEGANET2+nobody
MEGANET2+Accounts:x:10003:
MEGANET2+Finances:x:10004:
MEGANET2+PIOps:x:10005:
</screen>
		</para></step>

		<step><para>
		The Samba member server of a Windows NT4 Domain is ready for use.
		</para></step>
	</procedure>

<smbconfexample id="ch0-NT4DSDM">
<title>Samba Domain Member Server &smb.conf; File for NT4 Domain</title>
<smbconfcomment>Global parameters</smbconfcomment>
<smbconfsection>[global]</smbconfsection>
<smbconfoption><name>unix charset</name><value>LOCALE</value></smbconfoption>
<smbconfoption><name>workgroup</name><value>MEGANET2</value></smbconfoption>
<smbconfoption><name>security</name><value>DOMAIN</value></smbconfoption>
<smbconfoption><name>username map</name><value>/etc/samba/smbusers</value></smbconfoption>
<smbconfoption><name>log level</name><value>1</value></smbconfoption>
<smbconfoption><name>syslog</name><value>0</value></smbconfoption>
<smbconfoption><name>log file</name><value>/var/log/samba/%m</value></smbconfoption>
<smbconfoption><name>max log size</name><value>0</value></smbconfoption>
<smbconfoption><name>smb ports</name><value>139 445</value></smbconfoption>
<smbconfoption><name>name resolve order</name><value>wins bcast hosts</value></smbconfoption>
<smbconfoption><name>printcap name</name><value>CUPS</value></smbconfoption>
<smbconfoption><name>wins server</name><value>192.168.2.1</value></smbconfoption>
<smbconfoption><name>idmap uid</name><value>10000-20000</value></smbconfoption>
<smbconfoption><name>idmap gid</name><value>10000-20000</value></smbconfoption>
<smbconfoption><name>template primary group</name><value>"Domain Users"</value></smbconfoption>
<smbconfoption><name>template shell</name><value>/bin/bash</value></smbconfoption>
<smbconfoption><name>winbind separator</name><value>+</value></smbconfoption>
<smbconfoption><name>printer admin</name><value>root</value></smbconfoption>
<smbconfoption><name>hosts allow</name><value>192.168.2., 192.168.3., 127.</value></smbconfoption>
<smbconfoption><name>printing</name><value>cups</value></smbconfoption>

<smbconfsection>[homes]</smbconfsection>
<smbconfoption><name>comment</name><value>Home Directories</value></smbconfoption>
<smbconfoption><name>valid users</name><value>%S</value></smbconfoption>
<smbconfoption><name>read only</name><value>No</value></smbconfoption>
<smbconfoption><name>browseable</name><value>No</value></smbconfoption>

<smbconfsection>[printers]</smbconfsection>
<smbconfoption><name>comment</name><value>SMB Print Spool</value></smbconfoption>
<smbconfoption><name>path</name><value>/var/spool/samba</value></smbconfoption>
<smbconfoption><name>guest ok</name><value>Yes</value></smbconfoption>
<smbconfoption><name>printable</name><value>Yes</value></smbconfoption>
<smbconfoption><name>browseable</name><value>No</value></smbconfoption>

<smbconfsection>[print$]</smbconfsection>
<smbconfoption><name>comment</name><value>Printer Drivers</value></smbconfoption>
<smbconfoption><name>path</name><value>/var/lib/samba/drivers</value></smbconfoption>
<smbconfoption><name>admin users</name><value>root, Administrator</value></smbconfoption>
<smbconfoption><name>write list</name><value>root</value></smbconfoption>
</smbconfexample>

<example id="ch9-nsswbnd">
<title>Name Service Switch Control File: <filename>/etc/nsswitch.conf</filename></title>
<screen>
# /etc/nsswitch.conf

passwd:         compat winbind
group:          compat winbind

hosts:          files dns wins
networks:       files dns

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files
publickey:      files

bootparams:     files
automount:      files
aliases:        files
</screen>
</example>

	</sect2>

	<sect2 id="adssdm">
	<title>Active Directory Domain with Samba Domain Member Server</title>

	<para><indexterm>
	    <primary>Active Directory</primary>
	    <secondary>join</secondary>
	  </indexterm><indexterm>
	    <primary>Kerberos</primary>
	  </indexterm><indexterm>
	    <primary>Domain Member</primary>
	    <secondary>server</secondary>
	  </indexterm>
	One of the much-sought-after features new to Samba-3 is the ability to join an Active Directory
	Domain using Kerberos protocols. This makes it possible to operate an entire Windows network
	without the need to run NetBIOS over TCP/IP and permits more secure networking in general. An
	exhaustively complete discussion of the protocols is not possible in this book; perhaps a
	later book may explore the intricacies of the NetBIOS-less operation that Samba-3 can participate
	in. For now, we simply focus on how a Samba-3 server can be made a Domain Member server.
	</para>

	<para><indexterm>
	    <primary>Active Directory</primary>
	  </indexterm><indexterm>
	    <primary>LDAP</primary>
	  </indexterm><indexterm>
	    <primary>Identity resolution</primary>
	  </indexterm><indexterm>
	    <primary>Kerberos</primary>
	  </indexterm>
	The diagram in <link linkend="ch9-adsdc"/> demonstrates how Samba-3 interfaces with
	Microsoft Active Directory components. It should be noted that if Microsoft Windows Services
	for UNIX has been installed and correctly configured, it is possible to use client LDAP
	for Identity resolution just as can be done with Samba-3 when using an LDAP passdb backend.
	The UNIX tool that you need for this, as in the case of LDAP on UNIX/Linux, is the PADL
	Software nss_ldap tool-set. Compared with use of winbind and Kerberos, the use of 
	LDAP-based Identity resolution is a little less secure. In view of the fact that this solution
	requires additional software to be installed on the Windows 200x ADS Domain Controllers,
	and that means more management overhead, it is likely that most Samba-3 ADS client sites
	may elect to use winbind.
	</para>

	<para>
	Do not attempt to use this procedure if you are not 100 percent certain that the build of Samba-3
	you are using has been compiled and linked with all the tools necessary for this to work.
	Given the importance of this step, you must first validate that the Samba-3 message block
	daemon (<command>smbd</command>) has the necessary features.
	</para>

	<para>
	The hypothetical domain you are using in this example assumes that the Abmas London office
	decided to take their own lead (some would say this is a typical behavior in a global
	corporate world; besides, a little divergence and conflict makes for an interesting life).
	The Windows Server 2003 ADS Domain is called <constant>london.abmas.biz</constant> and the
	name of the server is <constant>W2K3S</constant>. In ADS realm terms, the Domain Controller
	is known as <constant>w2k3s.london.abmas.biz</constant>. In NetBIOS nomenclature, the
	Domain Name is <constant>LONDON</constant> and the server name is <constant>W2K3S</constant>.
	</para>

<figure id="ch9-adsdc">
	<title>Active Directory Domain: Samba Member Server</title>
	<mediaobject>
		<imageobject role="latex">
			<imagedata fileref="guide/images/chap9-ADSDC.png" scale="75" scalefit="1"/>
		</imageobject>
		<imageobject>
			<imagedata fileref="guide/images/chap9-SambaDC.png" scale="75" scalefit="1"/>
		</imageobject>
	</mediaobject>
</figure>

	<procedure>
	  <step><para><indexterm>
		<primary>smbd</primary>
	      </indexterm>
		Before you try to use Samba-3, you want to know for certain that your executables have
		support for Kerberos and for LDAP. Execute the following to identify whether or
		not this build is perhaps suitable for use:
<screen>
&rootprompt; cd /usr/sbin
&rootprompt; smbd -b | grep KRB
   HAVE_KRB5_H
   HAVE_ADDR_TYPE_IN_KRB5_ADDRESS
   HAVE_KRB5
   HAVE_KRB5_AUTH_CON_SETKEY
   HAVE_KRB5_GET_DEFAULT_IN_TKT_ETYPES
   HAVE_KRB5_GET_PW_SALT
   HAVE_KRB5_KEYBLOCK_KEYVALUE
   HAVE_KRB5_KEYTAB_ENTRY_KEYBLOCK
   HAVE_KRB5_MK_REQ_EXTENDED
   HAVE_KRB5_PRINCIPAL_GET_COMP_STRING
   HAVE_KRB5_SET_DEFAULT_IN_TKT_ETYPES
   HAVE_KRB5_STRING_TO_KEY
   HAVE_KRB5_STRING_TO_KEY_SALT
   HAVE_LIBKRB5
&rootprompt; smbd -b | grep LDAP
massive:/usr/sbin # smbd -b | grep LDAP
   HAVE_LDAP_H
   HAVE_LDAP
   HAVE_LDAP_DOMAIN2HOSTLIST
   HAVE_LDAP_INIT
   HAVE_LDAP_INITIALIZE
   HAVE_LDAP_SET_REBIND_PROC
   HAVE_LIBLDAP
   LDAP_SET_REBIND_PROC_ARGS
</screen>
		This does look promising; <command>smbd</command> has been built with Kerberos and LDAP
		support. You are relieved to know that it is safe to progress.
		</para></step>

	  <step><para><indexterm>
		<primary>Kerberos</primary>
		<secondary>libraries</secondary>
	      </indexterm><indexterm>
		<primary>MIT Kerberos</primary>
	      </indexterm><indexterm>
		<primary>Heimdal Kerberos</primary>
	      </indexterm><indexterm>
		<primary>Kerberos</primary>
		<secondary>MIT</secondary>
	      </indexterm><indexterm>
		<primary>Kerberos</primary>
		<secondary>Heimdal</secondary>
	      </indexterm><indexterm>
		<primary>Red Hat Linux</primary>
	      </indexterm><indexterm>
		<primary>SUSE Linux</primary>
	      </indexterm><indexterm>
		<primary>SerNet</primary>
	      </indexterm><indexterm>
		<primary>validated</primary>
	      </indexterm>
		The next step is to identify which version of the Kerberos libraries have been used.
		In order to permit Samba-3 to interoperate with Windows 2003 Active Directory, it is
		essential that it has been linked with either MIT Kerberos version 1.3.1 or later,
		or that it has been linked with Heimdal Kerberos 0.6 plus specific patches. You may
		identify what version of the MIT Kerberos libraries are installed on your system by
		executing (on Red Hat Linux):
<screen>
&rootprompt; rpm -q krb5
</screen>
		Or on SUSE Linux, execute:
<screen>
&rootprompt; rpm -q heimdal
</screen>
		Please note that the RPMs provided by the Samba-Team are known to be working and have
		been validated. Red Hat Linux RPMs may be obtained from the Samba FTP sites. SUSE
		Linux RPMs may be obtained from <ulink url="ftp://ftp.sernet.de">Sernet</ulink> in
		Germany.
		</para>

		<para>
		From this point on, you are certain that the Samba-3 build you are using has the
		necessary capabilities. You can now configure Samba-3 and the name service 
		switcher (NSS). 
		</para></step>

		<step><para>
		Using you favorite editor, configure the &smb.conf; file that is located in the 
		<filename>/etc/samba</filename> directory so that it has the contents shown 
		in <link linkend="ch9-adssdm"/>.
		</para></step>

		<step><para>
		Edit or create the NSS control file so it has the contents shown in <link linkend="ch9-nsswbnd"/>.
		</para></step>

	  <step><para><indexterm>
		<primary>/etc/samba/secrets.tdb</primary>
	      </indexterm>
		Delete the file <filename>/etc/samba/secrets.tdb</filename>, if it exists. Of course, you
		do keep a backup, don't you?
		</para></step>

		<step><para>
		Delete the tdb files that cache Samba information. You keep a backup of the old
		files, of course. You also remove all files to ensure that nothing can pollute your
		nice, new configuration. Execute the following (example is for SUSE Linux):
<screen>
&rootprompt; rm /var/lib/samba/*tdb
</screen>
		</para></step>

	  <step><para><indexterm>
		<primary>testparm</primary>
	      </indexterm>
		Validate your &smb.conf; file using <command>testparm</command> (as you have
		done previously). Correct all errors reported before proceeding. The command you
		execute is:
<screen>
&rootprompt; testparm -s | less
</screen>
		Now that you are satisfied that your Samba server is ready to join the Windows
		ADS Domain, let's move on.
		</para></step>

	  <step><para><indexterm>
		<primary>net</primary>
		<secondary>ads</secondary>
		<tertiary>join</tertiary>
	      </indexterm><indexterm>
		<primary>Kerberos</primary>
	      </indexterm>
		This is a good time to double-check everything and then execute the following
		command when everything you have done has checked out okay:
<screen>
&rootprompt; net ads join -UAdministrator%not24get
Using short domain name -- LONDON
Joined 'FRAN' to realm 'LONDON.ABMAS.BIZ'
</screen>
		You have successfully made your Samba-3 server a member of the ADS Domain
		using Kerberos protocols.
		</para>

	    <para><indexterm>
		<primary>silent return</primary>
	      </indexterm><indexterm>
		<primary>failed join</primary>
	      </indexterm>
		In the event that you receive no output messages, a silent return means that the
		Domain join failed. You should use <command>ethereal</command> to identify what
		may be failing. Common causes of a failed join include:

		<itemizedlist>
		<listitem><para><indexterm>
		      <primary>name resolution</primary>
		      <secondary>Defective</secondary>
		    </indexterm>
			Defective or misconfigured DNS name resolution.
			</para></listitem>

		<listitem><para><indexterm>
		      <primary>Restrictive security</primary>
		    </indexterm>
			Restrictive security settings on the Windows 200x ADS Domain controller
			preventing needed communications protocols. You can check this by searching
			the Windows Server 200x Event Viewer.
			</para></listitem>

			<listitem><para>
			Incorrectly configured &smb.conf; file settings.
			</para></listitem>

			<listitem><para>
			Lack of support of necessary Kerberos protocols because the version of MIT
			Kerberos (or Heimdal) in use is not up to date enough to support the necessary
			functionality.
			</para></listitem>
		</itemizedlist>
	      <indexterm>
		<primary>net</primary>
		<secondary>rpc</secondary>
		<tertiary>join</tertiary>
	      </indexterm><indexterm>
		<primary>RPC</primary>
	      </indexterm><indexterm>
		<primary>mixed mode</primary>
	      </indexterm>
		In any case, never execute the <command>net rpc join</command> command in an attempt
		to join the Samba server to the Domain, unless you wish not to use the Kerberos
		security protocols. Use of the older RPC-based Domain join facility requires that
		Windows Server 200x ADS has been configured appropriately for mixed mode operation.
		</para></step>

	  <step><para><indexterm>
		<primary>tdbdump</primary>
	      </indexterm><indexterm>
		<primary>/etc/samba/secrets.tdb</primary>
	      </indexterm>
		If the <command>tdbdump</command> is installed on your system (not essential),
		you can look inside the <filename>/etc/samba/secrets.tdb</filename> file. If
		you wish to do this, execute:
<screen>
&rootprompt; tdbdump secrets.tdb
{
key = "SECRETS/SID/LONDON"
data = "\01\04\00\00\00\00\00\05\15\00\00\00\EBw\86\F1\ED\BD\
   F6{\5C6\E5W\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
   00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
   00\00\00\00\00\00\00\00"
}
{
key = "SECRETS/MACHINE_PASSWORD/LONDON"
data = "le3Q5FPnN5.ueC\00"
}
{
key = "SECRETS/MACHINE_SEC_CHANNEL_TYPE/LONDON"
data = "\02\00\00\00"
}
{
key = "SECRETS/MACHINE_LAST_CHANGE_TIME/LONDON"
data = "E\89\F6?"
}
</screen>
		This is given to demonstrate to the skeptics that this process truly does work.
		</para></step>

		<step><para>
		It is now time to start Samba in the usual way (as has been done many time before
		in this book).	
		</para></step>

	  <step><para><indexterm>
		<primary>wbinfo</primary>
	      </indexterm>
		This is a good time to verify that everything is working. First, check that
		winbind is able to obtain the list of users and groups from the ADS Domain Controller.
		Execute the following:
<screen>
&rootprompt; wbinfo -u
LONDON+Administrator
LONDON+Guest
LONDON+SUPPORT_388945a0
LONDON+krbtgt
LONDON+jht
</screen>
		Good, the list of users was obtained. Now do likewise for group accounts:
<screen>
&rootprompt; wbinfo -g
LONDON+Domain Computers
LONDON+Domain Controllers
LONDON+Schema Admins
LONDON+Enterprise Admins
LONDON+Domain Admins
LONDON+Domain Users
LONDON+Domain Guests
LONDON+Group Policy Creator Owners
LONDON+DnsUpdateProxy
</screen>
		Excellent. That worked also, as expected.
		</para></step>

	  <step><para><indexterm>
		<primary>getent</primary>
	      </indexterm>
		Now repeat this via NSS to validate that full Identity resolution is
		functional as required. Execute:
<screen>
&rootprompt; getent passwd
...
LONDON+Administrator:x:10000:10000:Administrator:
             /home/LONDON/administrator:/bin/bash
LONDON+Guest:x:10001:10001:Guest:
             /home/LONDON/guest:/bin/bash
LONDON+SUPPORT_388945a0:x:10002:10000:SUPPORT_388945a0:
             /home/LONDON/support_388945a0:/bin/bash
LONDON+krbtgt:x:10003:10000:krbtgt:
             /home/LONDON/krbtgt:/bin/bash
LONDON+jht:x:10004:10000:John H. Terpstra:
             /home/LONDON/jht:/bin/bash
</screen>
		Okay, ADS user accounts are being resolved. Now you try group resolution as follows:
<screen>
&rootprompt; getent group
...
LONDON+Domain Computers:x:10002:
LONDON+Domain Controllers:x:10003:
LONDON+Schema Admins:x:10004:LONDON+Administrator
LONDON+Enterprise Admins:x:10005:LONDON+Administrator
LONDON+Domain Admins:x:10006:LONDON+jht,LONDON+Administrator
LONDON+Domain Users:x:10000:
LONDON+Domain Guests:x:10001:
LONDON+Group Policy Creator Owners:x:10007:LONDON+Administrator
LONDON+DnsUpdateProxy:x:10008:
</screen>
		This is very pleasing. Everything works as expected.
		</para></step>

	  <step><para><indexterm>
		<primary>net</primary>
		<secondary>ads</secondary>
		<tertiary>info</tertiary>
	      </indexterm><indexterm>
		<primary>Active Directory</primary>
		<secondary>server</secondary>
	      </indexterm><indexterm>
		<primary>Kerberos</primary>
	      </indexterm>
		You may now perform final verification that communications between Samba-3 winbind and
		the Active Directory server is using Kerberos protocols. Execute the following:
<screen>
&rootprompt; net ads info
LDAP server: 192.168.2.123
LDAP server name: w2k3s
Realm: LONDON.ABMAS.BIZ
Bind Path: dc=LONDON,dc=ABMAS,dc=BIZ
LDAP port: 389
Server time: Sat, 03 Jan 2004 02:44:44 GMT
KDC server: 192.168.2.123
Server time offset: 2
</screen>
		It should be noted that Kerberos protocols are time-clock critical. You should
		keep all server time clocks synchronized using the network time protocol (NTP).
		In any case, the output we obtained confirms that all systems are operational.
		</para></step>

	  <step><para><indexterm>
		<primary>net</primary>
		<secondary>ads</secondary>
		<tertiary>status</tertiary>
	      </indexterm>
		There is one more action you elect to take, just because you are paranoid and disbelieving,
		so you execute the following command:
<programlisting>
&rootprompt; net ads status -UAdministrator%not24get
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
cn: fran
distinguishedName: CN=fran,CN=Computers,DC=london,DC=abmas,DC=biz
instanceType: 4
whenCreated: 20040103092006.0Z
whenChanged: 20040103092006.0Z
uSNCreated: 28713
uSNChanged: 28717
name: fran
objectGUID: 58f89519-c467-49b9-acb0-f099d73696e
userAccountControl: 69632
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 127175965783327936
localPolicyFlags: 0
pwdLastSet: 127175952062598496
primaryGroupID: 515
objectSid: S-1-5-21-4052121579-2079768045-1474639452-1109
accountExpires: 9223372036854775807
logonCount: 13
sAMAccountName: fran$
sAMAccountType: 805306369
operatingSystem: Samba
operatingSystemVersion: 3.0.2-SUSE
dNSHostName: fran
userPrincipalName: HOST/fran@LONDON.ABMAS.BIZ
servicePrincipalName: CIFS/fran.london.abmas.biz
servicePrincipalName: CIFS/fran
servicePrincipalName: HOST/fran.london.abmas.biz
servicePrincipalName: HOST/fran
objectCategory: CN=Computer,CN=Schema,CN=Configuration,
                              DC=london,DC=abmas,DC=biz
isCriticalSystemObject: FALSE
-------------- Security Descriptor (revision: 1, type: 0x8c14)
owner SID: S-1-5-21-4052121579-2079768045-1474639452-512
group SID: S-1-5-21-4052121579-2079768045-1474639452-513
------- (system) ACL (revision: 4, size: 120, number of ACEs: 2)
------- ACE (type: 0x07, flags: 0x5a, size: 0x38, 
               mask: 0x20, object flags: 0x3)
access SID:  S-1-1-0
access type: AUDIT OBJECT
Permissions:
        [Write All Properties]
------- ACE (type: 0x07, flags: 0x5a, size: 0x38, 
               mask: 0x20, object flags: 0x3)
access SID:  S-1-1-0
access type: AUDIT OBJECT
Permissions:
        [Write All Properties]
------- (user) ACL (revision: 4, size: 1944, number of ACEs: 40)
------- ACE (type: 0x00, flags: 0x00, size: 0x24, mask: 0xf01ff)
access SID:  S-1-5-21-4052121579-2079768045-1474639452-512
access type: ALLOWED
Permissions: [Full Control]
------- ACE (type: 0x00, flags: 0x00, size: 0x18, mask: 0xf01ff)
access SID:  S-1-5-32-548
...
------- ACE (type: 0x05, flags: 0x12, size: 0x38, 
                mask: 0x10, object flags: 0x3)
access SID:  S-1-5-9
access type: ALLOWED OBJECT
Permissions:
        [Read All Properties]
-------------- End Of Security Descriptor
</programlisting>
		And now you have conclusive proof that your Samba-3 ADS Domain Member Server
		called <constant>FRAN</constant>, is able to communicate fully with the ADS
		Domain Controllers.
		</para></step>
	</procedure>


	<para>
	Your Samba-3 ADS Domain Member server is ready for use. During training sessions,
	you may be asked what is inside the <filename>winbindd_cache.tdb and winbindd_idmap.tdb</filename>
	files. Since curiosity just took hold of you, execute the following:
<programlisting>
&rootprompt; tdbdump /var/lib/samba/winbindd_idmap.tdb
{
key = "S-1-5-21-4052121579-2079768045-1474639452-501\00"
data = "UID 10001\00"
}
{
key = "UID 10005\00"
data = "S-1-5-21-4052121579-2079768045-1474639452-1111\00"
}
{
key = "GID 10004\00"
data = "S-1-5-21-4052121579-2079768045-1474639452-518\00"
}
{
key = "S-1-5-21-4052121579-2079768045-1474639452-502\00"
data = "UID 10003\00"
}
...

&rootprompt; tdbdump /var/lib/samba/winbindd_cache.tdb
{
key = "UL/LONDON"
data = "\00\00\00\00bp\00\00\06\00\00\00\0DAdministrator\0D
   Administrator-S-1-5-21-4052121579-2079768045-1474639452-500-
   S-1-5-21-4052121579-2079768045-1474639452-513\05Guest\05
   Guest-S-1-5-21-4052121579-2079768045-1474639452-501-
   S-1-5-21-4052121579-2079768045-1474639452-514\10
   SUPPORT_388945a0\10SUPPORT_388945a0.
   S-1-5-21-4052121579-2079768045-1474639452-1001-
   S-1-5-21-4052121579-2079768045-1474639452-513\06krbtgt\06
   krbtgt-S-1-5-21-4052121579-2079768045-1474639452-502-
   S-1-5-21-4052121579-2079768045-1474639452-513\03jht\10
   John H. Terpstra.S-1-5-21-4052121579-2079768045-1474639452-1110-
   S-1-5-21-4052121579-2079768045-1474639452-513"
}
{
key = "GM/S-1-5-21-4052121579-2079768045-1474639452-512"
data = "\00\00\00\00bp\00\00\02\00\00\00.
   S-1-5-21-4052121579-2079768045-1474639452-1110\03
   jht\01\00\00\00-S-1-5-21-4052121579-2079768045-1474639452-500\0D
   Administrator\01\00\00\00"
}
{
key = "SN/S-1-5-21-4052121579-2079768045-1474639452-513"
data = "\00\00\00\00xp\00\00\02\00\00\00\0CDomain Users"
}
{
key = "GM/S-1-5-21-4052121579-2079768045-1474639452-518"
data = "\00\00\00\00bp\00\00\01\00\00\00-
   S-1-5-21-4052121579-2079768045-1474639452-500\0D
   Administrator\01\00\00\00"
}
{
key = "SEQNUM/LONDON\00"
data = "xp\00\00C\92\F6?"
}
{
key = "U/S-1-5-21-4052121579-2079768045-1474639452-1110"
data = "\00\00\00\00xp\00\00\03jht\10John H. Terpstra.
   S-1-5-21-4052121579-2079768045-1474639452-1110-
   S-1-5-21-4052121579-2079768045-1474639452-513"
}
{
key = "NS/S-1-5-21-4052121579-2079768045-1474639452-502"
data = "\00\00\00\00bp\00\00-
   S-1-5-21-4052121579-2079768045-1474639452-502"
}
{
key = "SN/S-1-5-21-4052121579-2079768045-1474639452-1001"
data = "\00\00\00\00bp\00\00\01\00\00\00\10SUPPORT_388945a0"
}
{
key = "SN/S-1-5-21-4052121579-2079768045-1474639452-500"
data = "\00\00\00\00bp\00\00\01\00\00\00\0DAdministrator"
}
{
key = "U/S-1-5-21-4052121579-2079768045-1474639452-502"
data = "\00\00\00\00bp\00\00\06krbtgt\06krbtgt-
   S-1-5-21-4052121579-2079768045-1474639452-502-
   S-1-5-21-4052121579-2079768045-1474639452-513"
}
....
</programlisting>
	Now all is revealed. Your curiosity, as well as that of those with you, has been put at ease.
	May this server serve well all who happen upon it.
	</para>

<smbconfexample id="ch9-adssdm">
<title>Samba Domain Member &smb.conf; File for Active Directory Membership</title>
<smbconfcomment>Global parameters</smbconfcomment>
<smbconfsection>[global]</smbconfsection>
<smbconfoption><name>unix charset</name><value>LOCALE</value></smbconfoption>
<smbconfoption><name>workgroup</name><value>LONDON</value></smbconfoption>
<smbconfoption><name>realm</name><value>LONDON.ABMAS.BIZ</value></smbconfoption>
<smbconfoption><name>server string</name><value>Samba 3.0.2</value></smbconfoption>
<smbconfoption><name>security</name><value>ADS</value></smbconfoption>
<smbconfoption><name>username map</name><value>/etc/samba/smbusers</value></smbconfoption>
<smbconfoption><name>log level</name><value>1</value></smbconfoption>
<smbconfoption><name>syslog</name><value>0</value></smbconfoption>
<smbconfoption><name>log file</name><value>/var/log/samba/%m</value></smbconfoption>
<smbconfoption><name>max log size</name><value>50</value></smbconfoption>
<smbconfoption><name>printcap name</name><value>CUPS</value></smbconfoption>
<smbconfoption><name>ldap ssl</name><value>no</value></smbconfoption>
<smbconfoption><name>idmap uid</name><value>10000-20000</value></smbconfoption>
<smbconfoption><name>idmap gid</name><value>10000-20000</value></smbconfoption>
<smbconfoption><name>template primary group</name><value>"Domain Users"</value></smbconfoption>
<smbconfoption><name>template shell</name><value>/bin/bash</value></smbconfoption>
<smbconfoption><name>winbind separator</name><value>+</value></smbconfoption>
<smbconfoption><name>printing</name><value>cups</value></smbconfoption>

<smbconfsection>[homes]</smbconfsection>
<smbconfoption><name>comment</name><value>Home Directories</value></smbconfoption>
<smbconfoption><name>valid users</name><value>%S</value></smbconfoption>
<smbconfoption><name>read only</name><value>No</value></smbconfoption>
<smbconfoption><name>browseable</name><value>No</value></smbconfoption>

<smbconfsection>[printers]</smbconfsection>
<smbconfoption><name>comment</name><value>SMB Print Spool</value></smbconfoption>
<smbconfoption><name>path</name><value>/var/spool/samba</value></smbconfoption>
<smbconfoption><name>guest ok</name><value>Yes</value></smbconfoption>
<smbconfoption><name>printable</name><value>Yes</value></smbconfoption>
<smbconfoption><name>browseable</name><value>No</value></smbconfoption>

<smbconfsection>[print$]</smbconfsection>
<smbconfoption><name>comment</name><value>Printer Drivers</value></smbconfoption>
<smbconfoption><name>path</name><value>/var/lib/samba/drivers</value></smbconfoption>
<smbconfoption><name>admin users</name><value>root, Administrator</value></smbconfoption>
<smbconfoption><name>write list</name><value>root</value></smbconfoption>
</smbconfexample>

	</sect2>

	<sect2>
	<title>UNIX/Linux Client Domain Member</title>

	<para><indexterm>
	    <primary>user credentials</primary>
	  </indexterm>
	So far this chapter has been mainly concerned with the provision of file and print
	services for Domain Member servers. However, an increasing number of UNIX/Linux
	workstations are being installed that do not act as file or print servers to anyone
	other than a single desktop user. The key demand for desktop systems is to be able
	to log onto any UNIX/Linux or Windows desktop using the same network user credentials.
	</para>

	<para><indexterm>
	    <primary>Single Sign-On</primary>
	    <see>SOS</see>
	  </indexterm>
	The ability to use a common set of user credential across a variety of network systems
	is generally regarded as a Single Sign-On (SOS) solution. SOS systems are sold by a
	large number of vendors and include a range of technologies such as:
	</para>

	<itemizedlist>
		<listitem><para>
		Proxy sign-on
		</para></listitem>

		<listitem><para>
		Federated directory provisioning
		</para></listitem>

		<listitem><para>
		Meta-directory server solutions
		</para></listitem>

		<listitem><para>
		Replacement authentication systems
		</para></listitem>
	</itemizedlist>

	<para><indexterm>
	    <primary>Identity management</primary>
	  </indexterm>
	There are really only three solutions that provide integrated authentication and
	user Identity management facilities:
	</para>

	<itemizedlist>
                <listitem><para>
		Samba Winbind (free)
                </para></listitem>

                <listitem><para>
		<ulink url="http://www.padl.com">PADL</ulink> PAM and LDAP Tools (free)
                </para></listitem>

                <listitem><para>
		<ulink url="http://www.vintela.com">Vintela</ulink> Authentication Services (Commercial)
                </para></listitem>
        </itemizedlist>

	<para>
	The following guidelines are pertinent in respect of the deployment of winbind-based authentication
	and Identity resolution with the express purpose of allowing users to log onto UNIX/Linux desktops
	using Windows network Domain user credentials (username and password).
	</para>

	<para>
	You should note that it is possible to use LDAP-based PAM and NSS tools to permit distributed
	systems logons (SSO) providing user and group accounts are stored in an LDAP directory. This
	provides logon services for UNIX/Linux users, while Windows users obtain their sign-on
	support via Samba-3.
	</para>

	<para><indexterm>
	    <primary>Windows Services for UNIX</primary>
	    <see>SUS</see>
	  </indexterm>
	On the other hand, if the authentication and Identity resolution backend must be provided by
	a Windows NT4 style Domain or from an Active Directory Domain that does not have the Microsoft
	Windows Services for UNIX (SUS) installed, winbind is your best friend. Specific guidance for these
	situations now follows.
	</para>

	<para><indexterm>
	    <primary>PAM</primary>
	  </indexterm><indexterm>
	    <primary>Identity resolution</primary>
	  </indexterm><indexterm>
	    <primary>NSS</primary>
	  </indexterm>
	To permit users to log onto a Linux system using Windows network credentials, you need to
	configure Identity resolution (NSS) and PAM. This means that the basic steps include those
	outlined above with the addition of PAM configuration. Given that most workstations (desktop/client)
	usually do not need to provide file and print services to a group of users, the configuration
	of shares and printers is generally less important. Often this allows the share specifications
	to be entirely removed from the &smb.conf; file. That is obviously an administrator decision.
	</para>

		<sect3>
		<title>NT4 Domain Member</title>

		<para>
		The following steps provide a Linux system that users can log onto using
		Windows NT4 Domain (or Samba-3) Domain network credentials:
		</para>

		<procedure>
			<step><para>
			Follow the steps outlined in <link linkend="wdcsdm"/> and ensure that
			all validation tests function as shown.
			</para></step>

			<step><para>
			Identify what services users must log onto. On Red Hat Linux, if it is
			intended that the user shall be given access to all services, it may be
			most expeditious to simply configure the file 
			<filename>/etc/pam.d/system-auth</filename>.
			</para></step>

			<step><para>
			Carefully make a backup copy of all PAM configuration files before you
			begin making changes. If you break the PAM configuration, please note
			that you may need to use an emergency boot process to recover your Linux
			system. It is possible to break the ability to log into the system if
			PAM files are incorrectly configured. The entire directory 
			<filename>/etc/pam.d</filename> should be backed up to a safe location.
			</para></step>

			<step><para>
			If you require only console login support, edit the <filename>/etc/pam.d/login</filename>
			so it matches <link linkend="ch9-pamwnbdlogin"/>.
			</para></step>

			<step><para>
			To provide the ability to log onto the graphical desktop interface, you must edit
			the files <filename>gdm</filename> and <filename>xdm</filename> in the 
			<filename>/etc/pam.d</filename> directory.
			</para></step>

			<step><para>
			Edit only one file at a time. Carefully validate its operation before attempting
			to reboot the machine.
			</para></step>
		</procedure>

		</sect3>

		<sect3>
		<title>ADS Domain Member</title>

		<para>
		This procedure should be followed to permit a Linux network client (workstation/desktop)
		to permit users to log on using Microsoft Active Directory based user credentials.
		</para>

		<procedure>
			<step><para>
			Follow the steps outlined in <link linkend="adssdm"/> and ensure that
			all validation tests function as shown.
			</para></step>

			<step><para>
			Identify what services users must log onto. On Red Hat Linux, if it is
			intended that the user shall be given access to all services, it may be
			most expeditious to simply configure the file 
			<filename>/etc/pam.d/system-auth</filename> as shown in <link linkend="ch9-rhsysauth"/>.
			</para></step>

			<step><para>
			Carefully make a backup copy of all PAM configuration files before you
			begin making changes. If you break the PAM configuration, please note
			that you may need to use an emergency boot process to recover your Linux
			system. It is possible to break the ability to log into the system if
			PAM files are incorrectly configured. The entire directory 
			<filename>/etc/pam.d</filename> should be backed up to a safe location.
			</para></step>

			<step><para>
			If you require only console login support, edit the <filename>/etc/pam.d/login</filename>
			so it matches <link linkend="ch9-pamwnbdlogin"/>.
			</para></step>

			<step><para>
			To provide the ability to log onto the graphical desktop interface, you must edit
			the files <filename>gdm</filename> and <filename>xdm</filename> in the 
			<filename>/etc/pam.d</filename> directory.
			</para></step>

			<step><para>
			Edit only one file at a time. Carefully validate its operation before attempting
			to reboot the machine.
			</para></step>
		</procedure>

		</sect3>

<example id="ch9-pamwnbdlogin">
<title>SUSE: PAM <filename>login</filename> Module Using Winbind</title>
<screen>
# /etc/pam.d/login

#%PAM-1.0
auth sufficient pam_unix2.so    nullok
auth sufficient pam_winbind.so use_first_pass use_authtok
auth required   pam_securetty.so
auth required   pam_nologin.so
auth required   pam_env.so
auth required   pam_mail.so
account sufficient      pam_unix2.so
account sufficient      pam_winbind.so user_first_pass use_authtok
password required       pam_pwcheck.so  nullok
password sufficient     pam_unix2.so    nullok use_first_pass use_authtok
password sufficient     pam_winbind.so  use_first_pass use_authtok
session sufficient      pam_unix2.so    none
session sufficient      pam_winbind.so  use_first_pass use_authtok
session required        pam_limits.so
</screen>
</example>

<example id="ch9-pamwbndxdm">
<title>SUSE: PAM <filename>xdm</filename> Module Using Winbind</title>
<screen>
# /etc/pam.d/gdm (/etc/pam.d/xdm)

#%PAM-1.0
auth     sufficient     pam_unix2.so     nullok
auth     sufficient     pam_winbind.so   use_first_pass use_authtok
account  sufficient     pam_unix2.so
account  sufficient     pam_winbind.so   use_first_pass use_authtok
password sufficient     pam_unix2.so
password sufficient     pam_winbind.so   use_first_pass use_authtok
session  sufficient     pam_unix2.so
session  sufficient     pam_winbind.so   use_first_pass use_authtok
session  required       pam_dev perm.so
session  required       pam_resmgr.so
</screen>
</example>

<example id="ch9-rhsysauth">
<title>Red Hat 9: PAM System Authentication File: <filename>/etc/pam.d/system-auth</filename> Module Using Winbind</title>
<screen>
#%PAM-1.0
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so
account     sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass

password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
# Note: The above line is complete. There is nothing following the '='
password    sufficient    /lib/security/$ISA/pam_unix.so \
                                             nullok use_authtok md5 shadow
password    sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     sufficient    /lib/security/$ISA/pam_unix.so
session     sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
</screen>
</example>

	</sect2>

	<sect2>
		<title>Key Points Learned</title>

		<para>
		The addition of UNIX/Linux Samba servers and clients is a common requirement. In this chapter, you
		learned how to integrate such servers so that the UID/GID mappings they use can be consistent
		across all Domain Member servers. You also discovered how to implement the ability to use Samba
		or Windows Domain account credentials to log onto a UNIX/Linux client.
		</para>

		<para>
		The following are key points noted:
		</para>

		<itemizedlist>
			<listitem><para>
			Domain Controllers are always authoritative for the Domain.
			</para></listitem>

			<listitem><para>
			Domain Members may have local accounts and must be able to resolve the identity of 
			Domain user accounts. Domain user account identity must map to a local UID/GID. That 
			local UID/GID can be stored in LDAP. This way, it is possible to share the IDMAP data 
			across all Domain Member machines.
			</para></listitem>

			<listitem><para>
			Resolution of user and group identities on Domain Member machines may be implemented 
			using direct LDAP services or using winbind.
			</para></listitem>

			<listitem><para>
			On NSS/PAM enabled UNIX/Linux systems, NSS is responsible for Identity management 
			and PAM is responsible for authentication of logon credentials (user name and password).
			</para></listitem>
		</itemizedlist>

	</sect2>

</sect1>

<sect1>
	<title>Questions and Answers</title>

	<para>
	The following questions were obtained from the mailing list and also from private discussions
	with Windows network administrators.
	</para>

	<qandaset defaultlabel="chap09qa" type="number">
	<qandaentry>
	<question>

		<para>
		We use NIS for all UNIX accounts. Why do we need winbind?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>NIS</primary>
	      </indexterm><indexterm>
		<primary>encrypted passwords</primary>
	      </indexterm><indexterm>
		<primary>smbpasswd</primary>
	      </indexterm><indexterm>
		<primary>tdbsam</primary>
	      </indexterm><indexterm>
		<primary>passdb backend</primary>
	      </indexterm><indexterm>
		<primary>Winbind</primary>
	      </indexterm>
		You can use NIS for your UNIX accounts. NIS does not store the Windows encrypted
		passwords that need to be stored in one of the acceptable passdb backends.
		Your choice of backend is limited to <parameter>smbpasswd</parameter> or
		<parameter>tdbsam</parameter>. Winbind is needed to handle the resolution of
		SIDs from trusted domains to local UID/GID values.
		</para>

	    <para><indexterm>
		<primary>winbind trusted domains only</primary>
	      </indexterm><indexterm>
		<primary>getpwnam()</primary>
	      </indexterm>
		On a Domain Member server, you effectively map Windows Domain users to local users
		that are in your NIS database by specifying the <parameter>winbind trusted domains
		only</parameter>. This causes user and group account lookups to be routed via
		the <command>getpwnam()</command> family of systems calls. On an NIS-enabled client,
		this pushes the resolution of users and groups out through NIS.
		</para>

		<para>
		As a general rule, it is always a good idea to run winbind on all Samba servers.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		Our IT management people do not like LDAP, but are looking at Microsoft Active Directory. 
	      Which is better?<indexterm>
		<primary>Active Directory</primary>
	      </indexterm>
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>LDAP</primary>
		<secondary>server</secondary>
	      </indexterm><indexterm>
		<primary>Kerberos</primary>
	      </indexterm><indexterm>
		<primary>schema</primary>
	      </indexterm>
		Microsoft Active Directory is an LDAP server that is intricately tied to a Kerberos
		infrastructure. Most IT managers who object to LDAP do so because of the fact that
		an LDAP server is most often supplied as a raw tool that needs to be configured, and
		for which the administrator must create the schema, create the administration tools and
		devise the backup and recovery facilities in a site dependent manner. LDAP servers
		in general are seen as a high-energy, high-risk facility.
		</para>

	    <para><indexterm>
		<primary>management</primary>
	      </indexterm>
		Microsoft Active Directory by comparison is easy to install, configure, and
		is supplied with all tools necessary to implement and manage the directory. For sites
		that lack a lot of technical competence, Active Directory is a good choice. For sites
		that have the technical competence to handle Active Directory well, LDAP is a good
		alternative. The real issue that needs to be addressed is what type of solution does
		the site want? If management wants a choice to use an alternative, they may want to
		consider the options. On the other hand, if management just wants a solution that works,
		Microsoft Active Directory is a good solution.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		We want to implement a Samba PDC, four Samba BDCs, and 10 Samba servers. Is it possible 
		to use NIS in place of LDAP?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>NIS</primary>
	      </indexterm><indexterm>
		<primary>LDAP</primary>
	      </indexterm><indexterm>
		<primary>encrypted passwords</primary>
	      </indexterm><indexterm>
		<primary>synchronized</primary>
	      </indexterm><indexterm>
		<primary>secure account password</primary>
	      </indexterm><indexterm>
		<primary>PDC</primary>
	      </indexterm><indexterm>
		<primary>BDC</primary>
	      </indexterm>
		Yes, it is possible to use NIS in place of LDAP, but there may be problems with keeping
		the Windows (SMB) encrypted passwords database correctly synchronized across the entire
		network. Workstations (Windows client machines) periodically change their Domain
		Membership secure account password. How can you keep changes that are on remote BDCs
		synchronized on the PDC?
		</para>

	    <para><indexterm>
		<primary>centralized storage</primary>
	      </indexterm><indexterm>
		<primary>management</primary>
	      </indexterm><indexterm>
		<primary>network Identities</primary>
	      </indexterm>
		LDAP is a more elegant solution because it permits centralized storage and management
		of all network Identities (user, group and machine accounts) together with all information
		Samba needs to provide to network clients and their users.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		Are you suggesting that users should not log onto a Domain Member server? If so, why?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>security</primary>
	      </indexterm><indexterm>
		<primary>data</primary>
		<secondary>integrity</secondary>
	      </indexterm><indexterm>
		<primary>mapped drives</primary>
	      </indexterm>
		Many UNIX administrators mock the model that the Personal Computer industry has adopted
		as normative since the early days of Novell Netware. One may well argue that the old
		perception of the necessity to keep users off file and print servers was a result of
		fears concerning the security and integrity of data. It was a simple and generally
		effective measure to keep users away from servers, except through mapped drives.
		</para>

	    <para><indexterm>
		<primary>user logins</primary>
	      </indexterm><indexterm>
		<primary>risk</primary>
	      </indexterm><indexterm>
		<primary>user errors</primary>
	      </indexterm><indexterm>
		<primary>strategy</primary>
	      </indexterm><indexterm>
		<primary>policy</primary>
	      </indexterm>
		UNIX administrators are fully correct in asserting that UNIX servers and workstations
		are identical in terms of the software that is installed. They correctly assert that
		in a well secured environment it is safe to store files on a system that has hundreds
		of users. But all network administrators must factor into the decision to allow or
		reject general user logins to a UNIX system that is principally a file and print
		server. One must take account of the risk to operations through simple user errors.
		Only then can one begin to appraise the best strategy and adopt a site-specific
		policy that best protects the needs of users and of the organization alike.
		</para>

	    <para><indexterm>
		<primary>system level logins</primary>
	      </indexterm>
		From experience, it is my recommendation to keep general system level logins to a
		practical minimum and to eliminate them if possible. This should not be taken as a
		hard rule, though. The better question is, what works best for the site?
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>winbind enable local accounts</primary>
	      </indexterm><indexterm>
		<primary>/etc/passwd</primary>
	      </indexterm><indexterm>
		<primary>options list</primary>
	      </indexterm><indexterm>
		<primary>ACL</primary>
	      </indexterm><indexterm>
		<primary>share</primary>
	      </indexterm>
		In my &smb.conf; file, I enabled the parameter <parameter>winbind enable local accounts
		</parameter> on all Domain Member servers, but it does not work. The accounts I put in 
		<filename>/etc/passwd</filename> do not show up in the options list when I try to set an
		ACL on a share. What have I done wrong?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>local users</primary>
	      </indexterm><indexterm>
		<primary>local groups</primary>
	      </indexterm><indexterm>
		<primary>UNIX account</primary>
	      </indexterm><indexterm>
		<primary>getpwnam()</primary>
	      </indexterm><indexterm>
		<primary>getgrgid()</primary>
	      </indexterm><indexterm>
		<primary>Identity resolution</primary>
	      </indexterm><indexterm>
		<primary>failure</primary>
	      </indexterm><indexterm>
		<primary>Domain</primary>
	      </indexterm>
		The manual page for this &smb.conf; file parameter clearly says, <quote>This parameter 
		controls whether or not winbindd will act as a stand in replacement for the various 
		account management hooks in smb.conf (for example, add user script). If enabled, winbindd 
		will support the creation of local users and groups as another source of UNIX account 
		information available via getpwnam() or getgrgid(), etc...</quote> By default this
		parameter is already enabled; therefore, the action you are seeing is a result of a failure
		of Identity resolution in the Domain.
		</para>

	    <para><indexterm>
		<primary>Domain logons</primary>
	      </indexterm><indexterm>
		<primary>Identity resolution</primary>
	      </indexterm><indexterm>
		<primary>Domain</primary>
		<secondary>user</secondary>
	      </indexterm><indexterm>
		<primary>Domain</primary>
		<secondary>group</secondary>
	      </indexterm><indexterm>
		<primary>UID</primary>
	      </indexterm><indexterm>
		<primary>GID</primary>
	      </indexterm>
		These are the accounts that are available for Windows network Domain logons. Providing 
		Identity resolution has been correctly configured on the Domain Controllers, as well as 
		on Domain Member servers. The Domain user and group identities automatically map 
		to a valid local UID and GID pair.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>trusted domains</primary>
	      </indexterm><indexterm>
		<primary>domain</primary>
		<secondary>trusted</secondary>
	      </indexterm><indexterm>
		<primary>winbind trusted domains only</primary>
	      </indexterm><indexterm>
		<primary>domain members</primary>
	      </indexterm>
		We want to ensure that only users from our own domain plus from trusted domains can use our
		Samba servers. In the &smb.conf; file on all servers, we have enabled the <parameter>winbind
		trusted domains only</parameter> parameter. We now find that users from trusted domains 
		cannot access our servers, and users from Windows clients that are not domain members
		can also access our servers. Is this a Samba bug?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>distributed</primary>
	      </indexterm><indexterm>
		<primary>NIS</primary>
	      </indexterm><indexterm>
		<primary>rsync</primary>
	      </indexterm><indexterm>
		<primary>LDAP</primary>
	      </indexterm><indexterm>
		<primary>winbindd</primary>
	      </indexterm><indexterm>
		<primary>/etc/passwd</primary>
	      </indexterm>
		The manual page for this <parameter>winbind trusted domains only</parameter> parameter says,
		<quote>This parameter is designed to allow Samba servers that are members of a Samba controlled 
		domain to use UNIX accounts distributed vi NIS, rsync, or LDAP as the UIDs for winbindd users 
		in the hosts primary domain. Therefore,  the user <constant>SAMBA\user1</constant> would be 
		mapped to the account <constant>user1</constant> in <filename>/etc/passwd</filename> instead 
		of allocating a new UID for him or her.</quote> This would clearly suggest that you are trying
		to use this parameter inappropriately.
		</para>

	    <para><indexterm>
		<primary>valid users</primary>
	      </indexterm>
		A far better solution would be to use the <parameter>valid users</parameter> by specifying
		precisely the Domain users and groups that should be permitted access to the shares. You could, 
		for example, set the following parameters:
<screen>
[demoshare]
	path = /export/demodata
	valid users = @"Domain Users", @"OTHERDOMAIN\Domain Users"
</screen>
		</para>


	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		What are the benefits of using LDAP for my Domain Member servers?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>LDAP</primary>
	      </indexterm><indexterm>
		<primary>benefit</primary>
	      </indexterm><indexterm>
		<primary>UID</primary>
	      </indexterm><indexterm>
		<primary>GID</primary>
	      </indexterm><indexterm>
		<primary>Domain Controllers</primary>
	      </indexterm><indexterm>
		<primary>Domain Member servers</primary>
	      </indexterm><indexterm>
		<primary>copy</primary>
	      </indexterm><indexterm>
		<primary>replicate</primary>
	      </indexterm><indexterm>
		<primary>identity</primary>
	      </indexterm>
		The key benefit of using LDAP is that the UID of all users and the GID of all groups
		are globally consistent on Domain Controllers as well as on Domain Member servers.
		This means that it is possible to copy/replicate files across servers without
		loss of identity.
		</para>

	    <para><indexterm>
		<primary>Identity resolution</primary>
	      </indexterm><indexterm>
		<primary>winbind</primary>
	      </indexterm><indexterm>
		<primary>IDMAP backend</primary>
	      </indexterm><indexterm>
		<primary>LDAP</primary>
	      </indexterm><indexterm>
		<primary>Domain Controllers</primary>
	      </indexterm><indexterm>
		<primary>Domain Member</primary>
		<secondary>servers</secondary>
	      </indexterm><indexterm>
		<primary>Posix</primary>
	      </indexterm><indexterm>
		<primary>account information</primary>
	      </indexterm>
		When use is made of account Identity resolution via winbind, even when an IDMAP backend
		is stored in LDAP, the UID/GID on Domain Member servers is consistent, but differs
		from the ID that the user/group has on Domain Controllers. The winbind allocated UID/GID
		that is stored in LDAP (or locally) will be in the numeric range specified in the <parameter>
		idmap uid/gid</parameter> in the &smb.conf; file. On Domain Controllers, the UID/GID is
		that of the Posix value assigned in the LDAP directory as part of the Posix account information.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		Is proper DNS operation necessary for Samba-3 plus LDAP? If so, what must I put into
		my DNS configuration?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>DNS</primary>
		<secondary>configuration</secondary>
	      </indexterm><indexterm>
		<primary>DNS</primary>
		<secondary>lookup</secondary>
	      </indexterm><indexterm>
		<primary>hosts</primary>
	      </indexterm><indexterm>
		<primary>/etc/nsswitch.conf</primary>
	      </indexterm><indexterm>
		<primary>NSS</primary>
	      </indexterm><indexterm>
		<primary>/etc/hosts</primary>
	      </indexterm><indexterm>
		<primary>WINS</primary>
		<secondary>lookup</secondary>
	      </indexterm>
		Samba depends on correctly functioning resolution of host names to their IP address. Samba
		makes no direct DNS lookup calls, but rather redirects all name to address calls via the
		<command>getXXXbyXXX()</command> function calls. The configuration of the <constant>hosts</constant>
		entry in the NSS <filename>/etc/nsswitch.conf</filename> file determines how the underlying
		resolution process is implemented. If the <constant>hosts</constant> entry in your NSS
		control file says:
<screen>
hosts: files dns wins
</screen>
		This means that a host name lookup first tries the <filename>/etc/hosts</filename>.
		If this fails to resolve, it attempts a DNS lookup and if that fails, it tries a
		WINS lookup.
		</para>

	    <para><indexterm>
		<primary>NetBIOS</primary>
	      </indexterm><indexterm>
		<primary>TCP/IP</primary>
	      </indexterm><indexterm>
		<primary>name resolution</primary>
	      </indexterm>
		The addition of the WINS-based name lookup makes sense only if NetBIOS over TCP/IP has
		been enabled on all Windows clients. Where NetBIOS over TCP/IP has been disabled, DNS
		is the preferred name resolution technology. This usually makes most sense when Samba
		is a client of an Active Directory Domain, where NetBIOS use has been disabled. In this
		case, the Windows 200x auto-registers all locator records it needs with its own DNS
		server/s.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		Our Windows 2003 Server Active Directory Domain runs with NetBIOS disabled. Can we
		use Samba-3 with that configuration?
		</para>

	</question>
	<answer>

		<para>
		Yes.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>net</primary>
		<secondary>ads</secondary>
		<tertiary>join</tertiary>
	      </indexterm><indexterm>
		<primary>net</primary>
		<secondary>rpc</secondary>
		<tertiary>join</tertiary>
	      </indexterm>
		When I tried to execute <quote>net ads join</quote>, I got no output. It did not work, so
		I think that it failed. I then executed <quote>net rpc join</quote> and that worked fine.
		That is okay, isn't it?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>Kerberos</primary>
	      </indexterm><indexterm>
		<primary>authentication</primary>
	      </indexterm>
		No. This is not okay. It means that your Samba-3 client has joined the ADS Domain as
		a Windows NT4 client, and Samba-3 will not be using Kerberos-based authentication.
		</para>

	</answer>
	</qandaentry>

	</qandaset>

</sect1>

</chapter>