summaryrefslogtreecommitdiff
path: root/docs-xml/Samba3-ByExample/SBE-KerberosFastStart.xml
blob: 4fef217249098d1aa6ec4ea0bdcba244bfb45157 (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
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
<chapter id="kerberos">
  <title>Active Directory, Kerberos, and Security</title>

    <para><indexterm>
	<primary>experiment</primary>
      </indexterm>
	By this point in the book, you have been exposed to many Samba-3 features and capabilities.
	More importantly, if you have implemented the examples given, you are well on your way to becoming 
	a Samba-3 networking guru who knows a lot about Microsoft Windows. If you have taken the time to 
	practice, you likely have thought of improvements and scenarios with which you can experiment. You 
	are rather well plugged in to the many flexible ways Samba can be used.
	</para>

    <para><indexterm>
	<primary>criticism</primary>
      </indexterm>
	This is a book about Samba-3. Understandably, its intent is to present it in a positive light. 
	The casual observer might conclude that this book is one-eyed about Samba. It is &smbmdash; what 
	would you expect? This chapter exposes some criticisms that have been raised concerning 
	the use of Samba. For each criticism, there are good answers and appropriate solutions.
	</para>

	<para>
	Some criticism always comes from deep inside ranks that one would expect to be supportive of a particular 
	decision. Criticism can be expected from the outside. Let's see how the interesting dynamic of 
	criticism develops with respect to Abmas.
	</para>

    <para><indexterm>
	<primary>straw-man</primary>
      </indexterm>
	This chapter provides a shameless self-promotion of Samba-3. The objections raised were not pulled
	out of thin air. They were drawn from comments made by Samba users and from criticism during 
	discussions with Windows network administrators. The tone of the objections reflects as closely 
	as possible that of the original. The case presented is a straw-man example that is designed to 
	permit each objection to be answered as it might occur in real life.
	</para>

<sect1>
	<title>Introduction</title>

      <para><indexterm>
	  <primary>acquisitions</primary>
	</indexterm><indexterm>
	  <primary>risk</primary>
	</indexterm><indexterm>
	  <primary>assessment</primary>
	</indexterm><indexterm>
	  <primary>Active Directory</primary>
	</indexterm><indexterm>
	  <primary>Windows 2003 Serve</primary>
	</indexterm>
	Abmas is continuing its meteoric growth with yet further acquisitions. The investment community took
	note of the spectacular projection of Abmas onto the global business stage. Abmas is building an
	interesting portfolio of companies that includes accounting services, financial advice, investment
	portfolio management, property insurance, risk assessment, and the recent addition of a a video rental
	business. The pieces do not always appear to fit together, but Mr. Meany is certainly executing an 
	interesting business growth and development plan. Abmas Video Rentals was recently acquired. 
	During the time that the acquisition was closing, the Video Rentals business upgraded its Windows 
	NT4-based network to Windows 2003 Server and Active Directory.
	</para>

      <para><indexterm>
	  <primary>Active Directory</primary>
	</indexterm>
	You have accepted the fact that Abmas Video Rentals will use Microsoft Active Directory.
	The IT team, led by Stan Soroka, is committed to Samba-3 and to maintaining a uniform technology platform. 
	Stan Soroka's team voiced its disapproval over the decision to permit this business to continue to 
	operate with a solution that is viewed by Christine and her group as <quote>an island of broken 
	technologies.</quote> This comment was made by one of Christine's staff as they were installing a new 
	Samba-3 server at the new business.
	</para>


      <para><indexterm>
	  <primary>consultant</primary>
	</indexterm><indexterm>
	  <primary>hypothetical</primary>
	</indexterm>
	Abmas Video Rentals' head of IT heard of this criticism. He was offended that a junior engineer
	should make such a comment. He felt that he had to prepare in case he might be criticized for his 
	decision to use Active Directory. He decided he would defend his decision by hiring the services 
	of an outside security systems consultant to report<footnote><para>This report is entirely fictitious. 
			Any resemblance to a factual report is purely coincidental.</para></footnote> on his unit's operations 
	and to investigate the role of Samba at his site. Here are key extracts from this hypothetical 
	report:
	</para>

      <blockquote><para><indexterm>
	    <primary>vulnerabilities</primary>
	  </indexterm><indexterm>
	    <primary>integrity</primary>
	  </indexterm><indexterm>
	    <primary>practices</primary>
	  </indexterm><indexterm>
	    <primary>Active Directory</primary>
	  </indexterm>
	... the implementation of Microsoft Active Directory at the Abmas Video Rentals, Bamingsham site,
	 has been examined. We find no evidence to support a notion that vulnerabilities exist at your site.  
	... we took additional steps to validate the integrity of the installation and operation of Active 
	Directory and are pleased that your staff are following sound practices.
	</para>

	<para>
	...
	</para>

	<para><indexterm>
	    <primary>accounts</primary>
	    <secondary>user</secondary>
	  </indexterm><indexterm>
	    <primary>accounts</primary>
	    <secondary>group</secondary>
	  </indexterm><indexterm>
	    <primary>Backup</primary>
	  </indexterm><indexterm>
	    <primary>disaster recovery</primary>
	  </indexterm><indexterm>
	    <primary>validated</primary>
	  </indexterm><indexterm>
	    <primary>off-site storage</primary>
	  </indexterm>
	User and group accounts, and respective privileges, have been well thought out. File system shares are
	appropriately secured. Backup and disaster recovery plans are well managed and validated regularly, and
	effective off-site storage practices are considered to exceed industry norms.
	</para>

	<para><indexterm>
	    <primary>compromise</primary>
	  </indexterm><indexterm>
	    <primary>secure</primary>
	  </indexterm><indexterm>
	    <primary>network</primary>
	    <secondary>secure</secondary>
	  </indexterm>
	Your staff are justifiably concerned that the use of Samba may compromise their good efforts to maintain
	a secure network. 
	</para>

	<para><indexterm>
	    <primary>winbind</primary>
	  </indexterm><indexterm>
	    <primary>security</primary>
	  </indexterm><indexterm>
	    <primary>secure</primary>
	  </indexterm><indexterm>
	    <primary>network</primary>
	    <secondary>management</secondary>
	  </indexterm>
	The recently installed Linux file and application server uses a tool called <command>winbind</command> 
	that is indiscriminate about security. All user accounts in Active Directory can be used to access data 
	stored on the Linux system. We are alarmed that secure information is accessible to staff who should 
	not even be aware that it exists. We share the concerns of your network management staff who have gone 
	to great lengths to set fine-grained controls that limit information access to those who need access. 
	It seems incongruous to us that Samba winbind should be permitted to be used considering that it voids this fine work.
	</para>

	<para><indexterm>
	    <primary>isolated</primary>
	  </indexterm><indexterm>
	    <primary>firewall</primary>
	  </indexterm><indexterm>
	    <primary>best practices</primary>
	  </indexterm>
	Graham Judd [head of network administration] has locked down the security of all systems and is following 
	the latest Microsoft guidelines. ... null session connections have been disabled ... the internal network 
	is isolated from the outside world, the [product name removed] firewall is under current contract 
	maintenance support from [the manufacturer].  ... our attempts to penetrate security of your systems 
	failed to find problems common to Windows networking sites. We commend your staff on their attention to 
	detail and for following Microsoft recommended best practices.
	</para>

	<para>
	...
	</para>

	<para><indexterm>
	    <primary>security</primary>
	  </indexterm><indexterm>
	    <primary>disable</primary>
	  </indexterm><indexterm>
	    <primary>essential</primary>
	  </indexterm><indexterm>
	    <primary>trusted computing</primary>
	  </indexterm>
	Regarding the use of Samba, we offer the following comments: Samba is in use in nearly half of
	all sites we have surveyed. ... It is our opinion that Samba offers no better security than Microsoft
	... what worries us regarding Samba is the need to disable essential Windows security features such as
	secure channel support, digital sign'n'seal on all communication traffic, and running Active Directory in
	mixed mode so that Samba clients and servers can authenticate all of it. Additionally, we are concerned that
	Samba is not at the full capabilities of Microsoft Windows NT4 server. Microsoft has moved well beyond that
	with trusted computing initiatives that the Samba developers do not participate in.
	</para>

	<para><indexterm>
	    <primary>integrity</primary>
	  </indexterm><indexterm>
	    <primary>hackers</primary>
	  </indexterm><indexterm>
	    <primary>accountable</primary>
	  </indexterm><indexterm>
	    <primary>flaws</primary>
	  </indexterm><indexterm>
	    <primary>updates</primary>
	  </indexterm><indexterm>
	    <primary>bug fixes</primary>
	  </indexterm><indexterm>
	    <primary>alarm</primary>
	  </indexterm>
	One wonders about the integrity of an open source program that is developed by a team of hackers 
	who cannot be held accountable for the flaws in their code. The sheer number of updates and bug
	fixes they have released should ring alarm bells in any business.
	</para>

	<para><indexterm>
	    <primary>employment</primary>
	  </indexterm><indexterm>
	    <primary>jobs</primary>
	  </indexterm><indexterm>
	    <primary>risk</primary>
	  </indexterm>
	Another factor that should be considered is that buying Microsoft products and services helps to 
	provide employment in the IT industry. Samba and Open Source software place those jobs at risk.
	</para></blockquote>

      <para><indexterm>
	  <primary>Active Directory</primary>
	</indexterm><indexterm>
	  <primary>independent expert</primary>
	</indexterm>
	This is also a challenge to rise above the trouble spot. You call Stan's team together for a simple 
	discussion, but it gets further out of hand.  When you return to your office, you find the following 
	email in your in-box:
	</para>

	<para>
	Good afternoon,
	</para>

	<blockquote><attribution>Stan</attribution><para>
	I apologize for the leak of internal discussions to the new business. It reflects poorly on our 
	professionalism and has put you in an unpleasant position. I regret the incident.
	</para>

	<para>
	I also wish to advise that two of the recent recruits want to implement Kerberos authentication 
	across all systems. I concur with the desire to improve security. One of the new guys who is championing
	the move to Kerberos was responsible for the comment that caused the embarrassment.
	</para>

	<para><indexterm>
	    <primary>Kerberos</primary>
	  </indexterm><indexterm>
	    <primary>OpenLDAP</primary>
	  </indexterm><indexterm>
	    <primary>Active Directory</primary>
	  </indexterm><indexterm>
	    <primary>consultant</primary>
	  </indexterm>
	I am experiencing difficulty in handling the sharp push for Kerberos. He claims that Kerberos, OpenLDAP, 
	plus Samba-3 will seamlessly replace Microsoft Active Directory. I am a little out of my depth with respect 
	to the feasibility of such a move, but have taken steps to pull both of them into line. With your consent, 
	I would like to hire the services of a well-known Samba consultant to set the record straight.
	</para>

	<para><indexterm>
	    <primary>criticism</primary>
	  </indexterm><indexterm>
	    <primary>policy</primary>
	  </indexterm><indexterm>
	    <primary>Windows Servers</primary>
	  </indexterm><indexterm>
	    <primary>Active Directory</primary>
	  </indexterm><indexterm>
	    <primary>budgetted</primary>
	  </indexterm><indexterm>
	    <primary>financial responsibility</primary>
	  </indexterm>
	I intend to use this report to answer the criticism raised and would like to establish a policy that we
	will approve the use of Microsoft Windows Servers (and Active Directory) subject to all costs being covered 
	out of the budget of the division that wishes to go its own way. I propose that dissenters will still remain
	responsible to meet the budgeted contribution to IT operations as a whole. I believe we should not coerce 
	use of any centrally proposed standards, but make all noncompliance the financial responsibility of the 
	out-of-step division. Hopefully, this will encourage all divisions to walk with us and not alone.
	</para></blockquote>

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

		<para>
		You agreed with Stan's recommendations and hired a consultant to help defuse the powder
		keg. The consultant's task is to provide a tractable answer to each of the issues raised. The consultant must be able
		to support his or her claims, keep emotions to the side, and answer technically.
		</para>

	</sect2>
</sect1>

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

      <para><indexterm>
	  <primary>tool</primary>
	</indexterm><indexterm>
	  <primary>benefit</primary>
	</indexterm><indexterm>
	  <primary>choice</primary>
	</indexterm><indexterm>
	  <primary>consultant</primary>
	</indexterm><indexterm>
	  <primary>installation</primary>
	</indexterm><indexterm>
	  <primary>income</primary>
	</indexterm><indexterm>
	  <primary>employment</primary>
	</indexterm>
	Samba-3 is a tool. No one is pounding your door to make you use Samba. That is a choice that you are free to 
	make or reject. It is likely that your decision to use Samba can greatly benefit your company. 
	The Samba Team obviously believes that the Samba software is a worthy choice. 
	If you hire a consultant to assist with the installation and/or deployment of Samba, or if you hire 
	someone to help manage your Samba installation, you can create income and employment. Alternately, 
	money saved by not spending in the IT area can be spent elsewhere in the business. All money saved 
	or spent creates employment.
	</para>

      <para><indexterm>
	  <primary>economically sustainable</primary>
	</indexterm><indexterm>
	  <primary>inter-operability</primary>
	</indexterm><indexterm>
	  <primary>file and print service</primary>
	</indexterm><indexterm>
	  <primary>cost</primary>
	</indexterm><indexterm>
	  <primary>alternative</primary>
	</indexterm>
	In the long term, the use of Samba must be economically sustainable. In some situations, Samba is adopted
	purely to provide file and print service interoperability on platforms that otherwise cannot provide 
	access to data and to printers for Microsoft Windows clients. Samba is used by some businesses to
	effect a reduction in the cost of providing IT services. Obviously, it is also used by some as an 
	alternative to the use of a Microsoft file and print serving platforms with no consideration of costs.
	</para>

      <para><indexterm>
	  <primary>documentation</primary>
	</indexterm><indexterm>
	  <primary>responsibility</primary>
	</indexterm><indexterm>
	  <primary>fix</primary>
	</indexterm><indexterm>
	  <primary>broken</primary>
	</indexterm>
	It would be foolish to adopt a technology that might put any data or users at risk. Security affects 
	everyone. The Samba-Team is fully cognizant of the responsibility they have to their users. 
	The Samba documentation clearly reveals that full responsibility is accepted to fix anything 
	that is broken.
	</para>

      <para><indexterm>
	  <primary>commercial</primary>
	</indexterm><indexterm>
	  <primary>software</primary>
	</indexterm><indexterm>
	  <primary>commercial software</primary>
	</indexterm><indexterm>
	  <primary>End User License Agreement</primary>
	  <see>EULA</see>
	</indexterm><indexterm>
	  <primary>accountable</primary>
	</indexterm><indexterm>
	  <secondary>liability</secondary>
	</indexterm><indexterm>
	  <primary>accepts liability</primary>
	</indexterm><indexterm>
	  <primary>price paid</primary>
	</indexterm><indexterm>
	  <primary>product defects</primary>
	</indexterm><indexterm>
	  <primary>reimburse</primary>
	</indexterm><indexterm>
	  <primary>extent</primary>
	</indexterm>
	There is a mistaken perception in the IT industry that commercial software providers are fully 
	accountable for the defects in products. Open Source software comes with no warranty, so it is 
	often assumed that its use confers a higher degree of risk. Everyone should read commercial software 
	End User License Agreements (EULAs). You should determine what real warranty is offered and the 
	extent of liability that is accepted. Doing so soon dispels the popular notion that
	commercial software vendors are willingly accountable for product defects. In many cases, the
	commercial vendor accepts liability only to reimburse the price paid for the software. 
	</para>

      <para><indexterm>
	  <primary>consumer</primary>
	</indexterm><indexterm>
	  <primary>EULA</primary>
	</indexterm><indexterm>
	  <primary>track record</primary>
	</indexterm><indexterm>
	  <primary>commercial software</primary>
	</indexterm><indexterm>
	  <primary>support</primary>
	</indexterm><indexterm>
	  <primary>vendor</primary>
	</indexterm>
	The real issues that a consumer (like you) needs answered are What is the way of escape from technical 
	problems, and how long will it take? The average problem turnaround time in the Open Source community is 
	approximately 48 hours. What does the EULA offer? What is the track record in the commercial software 
	industry? What happens when your commercial vendor decides to cease providing support?
	</para>

      <para><indexterm>
	  <primary>source code</primary>
	</indexterm><indexterm>
	  <primary>Open Source</primary>
	</indexterm><indexterm>
	  <primary>hire</primary>
	</indexterm><indexterm>
	  <primary>programmer</primary>
	</indexterm><indexterm>
	  <primary>solve</primary>
	</indexterm><indexterm>
	  <primary>fix</primary>
	</indexterm><indexterm>
	  <secondary>problem</secondary>
	</indexterm>
	Open Source software at least puts you in possession of the source code. This means that when
	all else fails, you can hire a programmer to solve the problem.
	</para>

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

		<para>
		Each issue is now discussed and, where appropriate, example implementation steps are
		provided.
		</para>

	<variablelist>
		<varlistentry>
			<term>Winbind and Security</term>
	    <listitem><para><indexterm>
		  <primary>Winbind</primary>
		</indexterm><indexterm>
		  <primary>Security</primary>
		</indexterm><indexterm>
		  <primary>network</primary>
		  <secondary>administrators</secondary>
		</indexterm><indexterm>
		  <primary>Domain users</primary>
		</indexterm><indexterm>
		  <secondary>Domain account</secondary>
		</indexterm><indexterm>
		  <primary>credentials</primary>
		</indexterm><indexterm>
		  <primary>Network Neighborhood</primary>
		</indexterm><indexterm>
		  <primary>UNIX/Linux server</primary>
		</indexterm><indexterm>
		  <primary>browse</primary>
		</indexterm><indexterm>
		  <primary>shares</primary>
		</indexterm>
				Windows network administrators may be dismayed to find that <command>winbind</command> 
				exposes all domain users so that they may use their domain account credentials to 
				log on to a UNIX/Linux system. The fact that all users in the domain can see the 
				UNIX/Linux server in their Network Neighborhood and can browse the shares on the 
				server seems to excite them further.
				</para>

	      <para><indexterm>
		  <primary>Domain Member server</primary>
		</indexterm><indexterm>
		  <primary>familiar</primary>
		</indexterm><indexterm>
		  <primary>fear</primary>
		</indexterm><indexterm>
		  <primary>unknown</primary>
		</indexterm>
				<command>winbind</command> provides for the UNIX/Linux domain member server or 
				client, the same as one would obtain by adding a Microsoft Windows server or 
				client to the domain. The real objection is the fact that Samba is not MS Windows 
				and therefore requires handling a little differently from the familiar Windows systems.
				One must recognize fear of the unknown.
				</para>

	      <para><indexterm>
		  <primary>network administrators</primary>
		</indexterm><indexterm>
		  <primary>recognize</primary>
		</indexterm><indexterm>
		  <primary>winbind</primary>
		</indexterm><indexterm>
		  <primary>over-ride</primary>
		</indexterm><indexterm>
		  <primary>Active Directory</primary>
		  <secondary>management tools</secondary>
		</indexterm><indexterm>
		  <primary>fears</primary>
		</indexterm>
				Windows network administrators need to recognize that <command>winbind</command> does
				not, and cannot, override account controls set using the Active Directory management
				tools. The control is the same. Have no fear.
				</para>

	      <para><indexterm>
		  <primary>ADS Domain</primary>
		</indexterm><indexterm>
		  <primary>account</primary>
		  <secondary>ADS Domain</secondary>
		</indexterm><indexterm>
		  <primary>winbind</primary>
		</indexterm><indexterm>
		  <primary>browsing</primary>
		</indexterm><indexterm>
		  <primary>permits</primary>
		</indexterm><indexterm>
		  <primary>access</primary>
		</indexterm><indexterm>
		  <primary>drive mapping</primary>
		</indexterm><indexterm>
		  <primary>protected</primary>
		</indexterm><indexterm>
		  <primary>security controls</primary>
		</indexterm><indexterm>
		  <primary>access controls</primary>
		</indexterm>
				Where Samba and the ADS domain account information obtained through the use of
				<command>winbind</command> permits access, by browsing or by the drive mapping to
				a share, to data that should be better protected. This can only happen when security
				controls have not been properly implemented. Samba permits access controls to be set
				on:
				</para>

				<itemizedlist>
					<listitem><para>Shares themselves (i.e., the logical share itself)</para></listitem>
					<listitem><para>The share definition in &smb.conf;</para></listitem>
					<listitem><para>The shared directories and files using UNIX permissions</para></listitem>
                                        <listitem><para>Using Windows 2000 ACLs &smbmdash; if the file system is POSIX enabled</para></listitem>
				</itemizedlist>

				<para>
				Examples of each are given in <link linkend="ch10expl"/>.
				</para>
				</listitem>
		</varlistentry>

		<varlistentry>
			<term>User and Group Controls</term>
	    <listitem><para><indexterm>
		  <primary>User and Group Controls</primary>
		</indexterm><indexterm>
		  <primary>management</primary>
		  <secondary>User</secondary>
		</indexterm><indexterm>
		  <primary>management</primary>
		  <secondary>group</secondary>
		</indexterm><indexterm>
		  <primary>ADS</primary>
		</indexterm><indexterm>
		  <primary>permissions</primary>
		</indexterm><indexterm>
		  <primary>privileges</primary>
		</indexterm><indexterm>
		  <primary>flexibility</primary>
		</indexterm><indexterm>
		  <primary>access controls</primary>
		</indexterm><indexterm>
		  <primary>share definition</primary>
		</indexterm>
				User and group management facilities as known in the Windows ADS environment may be
				used to provide equivalent access control constraints or to provide equivalent
				permissions and privileges on Samba servers. Samba offers greater flexibility in the
				use of user and group controls because it has additional layers of control compared to
				Windows 200x/XP. For example, access controls on a Samba server may be set within
				the share definition in a manner for which Windows has no equivalent.
				</para>

	      <para><indexterm>
		  <primary>analysis</primary>
		</indexterm><indexterm>
		  <primary>system security</primary>
		</indexterm><indexterm>
		  <primary>safe-guards</primary>
		</indexterm><indexterm>
		  <primary>permissions</primary>
		  <secondary>excessive</secondary>
		</indexterm><indexterm>
		  <primary>file system</primary>
		</indexterm><indexterm>
		  <primary>shared resource</primary>
		</indexterm><indexterm>
		  <primary>share definition</primary>
		</indexterm>
				In any serious analysis of system security, it is important to examine the safeguards
				that remain when all other protective measures fail. An administrator may inadvertently
				set excessive permissions on the file system of a shared resource, or he may set excessive
				privileges on the share itself. If that were to happen in a Windows 2003 Server environment,
				the data would indeed be laid bare to abuse. Yet, within a Samba share definition, it is
				possible to guard against that by enforcing controls on the share definition itself. You
				see a practical example of this a little later in this chapter.
				</para>

	      <para><indexterm>
		  <primary>diligence</primary>
		</indexterm><indexterm>
		  <primary>weakness</primary>
		</indexterm>
				The report that is critical of Samba really ought to have exercised greater due
				diligence: the real weakness is on the side of a Microsoft Windows environment.
				</para></listitem>
		</varlistentry>

		<varlistentry>
			<term>Security Overall</term>
	    <listitem><para><indexterm>
		  <primary>defects</primary>
		</indexterm>
				Samba is designed in such a manner that weaknesses inherent in the design of
				Microsoft Windows networking ought not to expose the underlying UNIX/Linux file
				system in any way. All software has potential defects, and Samba is no exception.
				What matters more is how defects that are discovered get dealt with.
				</para>

	      <para><indexterm>
		  <primary>security</primary>
		</indexterm><indexterm>
		  <primary>protection</primary>
		</indexterm><indexterm>
		  <primary>compromise</primary>
		</indexterm><indexterm>
		  <primary>consequential risk</primary>
		</indexterm>
				The Samba Team totally agrees with the necessity to observe and fully implement
				every security facility to provide a level of protection and security that is necessary
				and that the end user (or network administrator) needs. Never would the Samba Team
				recommend a compromise to system security, nor would deliberate defoliation of
				security be publicly condoned; yet this is the practice by many Windows network
				administrators just to make happy users who have no notion of consequential risk.
				</para>

	      <para><indexterm>
		  <primary>condemns</primary>
		</indexterm><indexterm>
		  <primary>security fixes</primary>
		</indexterm><indexterm>
		  <primary>updates</primary>
		</indexterm><indexterm>
		  <primary>development</primary>
		</indexterm><indexterm>
		  <primary>documentation</primary>
		</indexterm><indexterm>
		  <primary>security updates</primary>
		</indexterm><indexterm>
		  <primary>turn-around time</primary>
		</indexterm>
				The report condemns Samba for releasing updates and security fixes, yet Microsoft
				online updates need to be applied almost weekly. The answer to the criticism 
				lies in the fact that Samba development is continuing, documentation is improving, 
				user needs are being increasingly met or exceeded, and security updates are issued 
				with a short turnaround time.
				</para>

	      <para><indexterm>
		  <primary>modularization</primary>
		</indexterm><indexterm>
		  <primary>next generation</primary>
		</indexterm><indexterm>
		  <primary>responsible</primary>
		</indexterm><indexterm>
		  <primary>dependability</primary>
		</indexterm><indexterm>
		  <primary>road-map</primary>
		  <secondary>published</secondary>
		</indexterm>
				The release of Samba-4 is expected around late 2004 to early 2005 and involves a near 
				complete rewrite to permit extensive modularization and to prepare Samba for new 
				functionality planned for addition during the next-generation series. The Samba Team 
				is responsible and can be depended upon; the history to date suggests a high 
				degree of dependability and on charter development consistent with published 
				roadmap projections.
				</para>

	      <para><indexterm>
		  <primary>foundation members</primary>
		</indexterm><indexterm>
		  <primary>Common Internet File System</primary>
		  <see>CIFS</see>
		</indexterm><indexterm>
		  <primary>network attached storage</primary>
		  <see>NAS</see>
		</indexterm><indexterm>
		  <primary>conferences</primary>
		</indexterm><indexterm>
		  <primary>presence and leadership</primary>
		</indexterm><indexterm>
		  <primary>leadership</primary>
		</indexterm><indexterm>
		  <primary>inter-operability</primary>
		</indexterm>
				Not well published is the fact that Microsoft was a foundation member of
				the Common Internet File System (CIFS) initiative, together with the participation 
				of the network attached storage (NAS) industry. Unfortunately, for the past few years,
				Microsoft has been absent from active involvement at CIFS conferences and has
				not exercised the leadership expected of a major force in the networking technology
				space. The Samba Team has maintained consistent presence and leadership at all
				CIFS conferences and at the interoperability laboratories run concurrently with
				them.
				</para></listitem>
		</varlistentry>

		<varlistentry>
			<term>Cryptographic Controls (schannel, sign'n'seal)</term>
	    <listitem><para><indexterm>
		  <primary>Cryptographic</primary>
		</indexterm><indexterm>
		  <primary>schannel</primary>
		</indexterm><indexterm>
		  <primary>digital sign'n'seal</primary>
		</indexterm>
				The report correctly mentions that Samba did not support the most recent
				<constant>schannel</constant> and <constant>digital sign'n'seal</constant> features
				of Microsoft Windows NT/200x/XPPro products. This is one of the key features 
				of the Samba-3 release. Market research reports take so long to generate that they are
				seldom a reflection of current practice, and in many respects reports are like a
				pathology report &smbmdash; they reflect accurately (at best) status at a snapshot in time.
				Meanwhile, the world moves on.
				</para>

	      <para><indexterm>
		  <primary>public specifications</primary>
		</indexterm><indexterm>
		  <primary>protocols</primary>
		</indexterm><indexterm>
		  <primary>algorithm</primary>
		</indexterm><indexterm>
		  <primary>compatible</primary>
		</indexterm><indexterm>
		  <primary>network</primary>
		  <secondary>traffic</secondary>
		  <tertiary>observation</tertiary>
		</indexterm><indexterm>
		  <primary>defensible standards</primary>
		</indexterm><indexterm>
		  <primary>secure networking</primary>
		</indexterm>
				It should be pointed out that had clear public specifications for the protocols
				been published, it would have been much easier to implement these features and would have
				taken less time to do. The sole mechanism used to find an algorithm that is compatible
				with the methods used by Microsoft has been based on observation of network traffic
				and trial-and-error implementation of potential techniques. The real value of public
				and defensible standards is obvious to all and would have enabled more secure networking
				for everyone.
				</para>

	      <para><indexterm>
		  <primary>Critics</primary>
		</indexterm><indexterm>
		  <primary>digital sign'n'seal</primary>
		</indexterm>
				Critics of Samba often ignore fundamental problems that may plague (or may have plagued)
				the users of Microsoft's products also. Those who are first to criticize Samba
				for not rushing into release of <constant>digital sign'n'seal</constant> support
				often dismiss the problems that Microsoft has 
				<ulink url="http://support.microsoft.com/default.aspx?kbid=321733">acknowledged</ulink>
				and for which a fix was provided. In fact,
				<ulink url="http://www.tangent-systems.com/support/delayedwrite.html">Tangent Systems</ulink> 
				have documented a significant problem with delays writes that can be connected with the
				implementation of sign'n'seal. They provide a work-around that is not trivial for many
				Windows networking sites. From notes such as this it is clear that there are benefits
				from not rushing new technology out of the door too soon.
				</para>

	      <para><indexterm>
		  <primary>secure networking protocols</primary>
		</indexterm><indexterm>
		  <primary>refereed standards</primary>
		</indexterm><indexterm>
		  <primary>proprietary</primary>
		</indexterm><indexterm>
		  <primary>digital rights</primary>
		</indexterm><indexterm>
		  <primary>protection</primary>
		</indexterm><indexterm>
		  <primary>networking protocols</primary>
		</indexterm><indexterm>
		  <primary>diffusion</primary>
		</indexterm><indexterm>
		  <primary>consumer</primary>
		</indexterm><indexterm>
		  <primary>choice</primary>
		</indexterm>
				One final comment is warranted. If companies want more secure networking protocols,
				the most effective method by which this can be achieved is by users seeking
				and working together to help define open and publicly refereed standards. The
				development of closed source, proprietary methods that are developed in a
				clandestine framework of secrecy, under claims of digital rights protection, does
				not favor the diffusion of safe networking protocols and certainly does not
				help the consumer to make a better choice.
				</para></listitem>
		</varlistentry>

		<varlistentry>
			<term>Active Directory Replacement with Kerberos, LDAP, and Samba
				        <indexterm>
		  <primary>Active Directory</primary>
		  <secondary>Replacement</secondary>
		</indexterm><indexterm>
		  <primary>Kerberos</primary>
		</indexterm><indexterm>
		  <primary>LDAP</primary>
		</indexterm><indexterm>
		  <primary>remote procedure call</primary>
		  <see>RPC</see>
		</indexterm>

			</term>
				<listitem><para>
				<literallayout>    </literallayout>
				The Microsoft networking protocols extensively make use of remote procedure call (RPC)
				technology. Active Directory is not a simple mixture of LDAP and Kerberos together
				with file and print services, but rather is a complex, intertwined implementation
				of them that uses RPCs that are not supported by any of these component technologies
				and yet by which they are made to interoperate in ways that the components do not
				support.
				</para>

	      <para><indexterm>
		  <primary>Active Directory</primary>
		  <secondary>Server</secondary>
		</indexterm><indexterm>
		  <primary>OpenLDAP</primary>
		</indexterm><indexterm>
		  <primary>Kerberos</primary>
		</indexterm><indexterm>
		  <primary>project maintainers</primary>
		</indexterm><indexterm>
		  <primary>LDAP</primary>
		</indexterm>
				In order to make the popular request for Samba to be an Active Directory Server a
				reality, it is necessary to add to OpenLDAP, Kerberos, as well as Samba, RPC calls
				that are not presently supported. The Samba Team has not been able to gain critical
				overall support for all project maintainers to work together on the complex
				challenge of developing and integrating the necessary technologies. Therefore, if
				the Samba Team does not make it a priority to absorb Kerberos and LDAP functionality
				into the Samba project, this dream request cannot become a reality.
				</para>

	      <para><indexterm>
		  <primary>missing RPC's</primary>
		</indexterm><indexterm>
		  <primary>road-map</primary>
		</indexterm><indexterm>
		  <primary>ADS</primary>
		  <secondary>server</secondary>
		</indexterm><indexterm>
		  <primary>MMC</primary>
		</indexterm><indexterm>
		  <primary>managed</primary>
		</indexterm>
				At this time, the integration of LDAP, Kerberos, and the missing RPCs is not on the
				Samba development roadmap. If it is not on the published roadmap, it cannot be delivered
				anytime soon. Ergo, ADS server support is not a current goal for Samba development.
				The Samba Team is most committed to permitting Samba to be a full ADS domain member
				that is increasingly capable of being managed using Microsoft Windows MMC tools.
				</para></listitem>
		</varlistentry>
	</variablelist>

	<sect3>
	<title>Kerberos Exposed</title>

	  <para><indexterm>
	      <primary>kerberos</primary>
	    </indexterm><indexterm>
	      <primary>unauthorized activities</primary>
	    </indexterm><indexterm>
	      <primary>authorized location</primary>
	    </indexterm>
	Kerberos is a network authentication protocol that provides secure authentication for 
	client-server applications by using secret-key cryptography. Firewalls are an insufficient 
	barrier mechanism in today's networking world; at best they only restrict incoming network 
	traffic but cannot prevent network traffic that comes from authorized locations from 
	performing unauthorized activities.
	</para>

	  <para><indexterm>
	      <primary>strong cryptography</primary>
	    </indexterm><indexterm>
	      <primary>identity</primary>
	    </indexterm><indexterm>
	      <primary>integrity</primary>
	    </indexterm>
	Kerberos was created by MIT as a solution to network security problems. The Kerberos protocol uses 
	strong cryptography so that a client can prove its identity to a server (and vice versa) across an 
	insecure network connection. After a client and server has used Kerberos to prove their identity, 
	they can also encrypt all of their communications to assure privacy and data integrity as they go 
	about their business.
	</para>

	  <para><indexterm>
	      <primary>trusted third-party</primary>
	    </indexterm><indexterm>
	      <primary>principals</primary>
	    </indexterm><indexterm>
	      <primary>trusting</primary>
	    </indexterm><indexterm>
	      <primary>kerberos</primary>
	      <secondary>server</secondary>
	    </indexterm><indexterm>
	      <primary>secret</primary>
	    </indexterm>
	Kerberos is a trusted third-party service. That means that there is a third party (the kerberos 
	server) that is trusted by all the entities on the network (users and services, usually called 
	principals). All principals share a secret password (or key) with the kerberos server and this 
	enables principals to verify that the messages from the kerberos server are authentic. Therefore, 
	trusting the kerberos server, users and services can authenticate each other.
	</para>

	<para>
	<indexterm><primary>restricted export</primary></indexterm>
	<indexterm><primary>MIT Kerberos</primary></indexterm>
	<indexterm><primary>Heimdal Kerberos</primary></indexterm>
	Kerberos was, until recently, a technology that was restricted from being exported from the United States.
	For many years that hindered global adoption of more secure networking technologies both within the United States
	and abroad. A free and unencumbered implementation of MIT Kerberos has been produced in Europe
	and is available from the <ulink url="http://www.pdc.kth.se/heimdal/">Royal Institute</ulink> of
	Technology (KTH), Sweden. It is known as the Heimdal Kerberos project.  In recent times the U.S. government
	has removed sanctions affecting the global distribution of MIT Kerberos.  It is likely that there will be a
	significant surge forward in the development of Kerberos-enabled applications and in the general deployment
	and use of Kerberos across the spectrum of the information technology industry.
	</para>

	<para>
	<indexterm><primary>Kerberos</primary><secondary>interoperability</secondary></indexterm>
	A storm has broken out concerning interoperability between MIT Kerberos and Microsofts' implementation
	of it. For example, a 2002
	<ulink url="http://www.idg.com.sg/idgwww.nsf/0/5DDA8D153A7505A748256BAB000D992A?OpenDocument">IDG</ulink>
	report<footnote><para>Note: This link is no longer active. The same article is still
			available from <ulink url="http://199.105.191.226/Man/2699/020430msdoj/">ITWorld.com</ulink> (July 5, 2005)</para></footnote> by
	states:
	</para>

	<blockquote><para>
	A Microsoft Corp. executive testified at the software giant's remedy hearing that the company goes to 
	great lengths to disclose interfaces and protocols that allow third-party software products to interact 
	with Windows. But a lawyer with the states suing Microsoft pointed out that when it comes to the company's 
	use of the Kerberos authentication specification, not everyone agrees.
	</para>

	<para>
	<indexterm><primary>Kerberos</primary><secondary>unspecified fields</secondary></indexterm>
	Robert Short, vice president of Windows core technology at Microsoft, wrote in his direct testimony prepared 
	before his appearance that non-Microsoft operating systems can disregard the portion of the Kerberos version 
	5 specification that Windows clients use for proprietary purposes and still achieve interoperability with 
	the Microsoft OS. Microsoft takes advantage of unspecified fields in the Kerberos specification for storing 
	Windows-specific authorization data, Short wrote. The designers of Kerberos left these fields undefined so 
	that software developers could add their own authorization information, he said.
	</para></blockquote>

	<para>
	<indexterm><primary>DCE</primary></indexterm>
	<indexterm><primary>RPC</primary></indexterm>
	It so happens that Microsoft Windows clients depend on and expect the contents of the <emphasis>unspecified
	fields</emphasis> in the Kerberos 5 communications data stream for their Windows interoperability,
	particularly when Samba is expected to emulate a Windows Server 200x domain controller. But the interoperability
	issue goes far deeper than this. In the domain control protocols that are used by MS Windows XP Professional,
	there is a tight interdependency between the Kerberos protocols and the Microsoft distributed computing environment
	(DCE) RPCs that themselves are an integral part of the SMB/CIFS protocols as used by
	Microsoft.
	</para>

	<para>
	Microsoft makes the following comment in a reference in a
	<ulink url="http://www.microsoft.com/technet/itsolutions/interop/mgmt/kerberos.asp">
	technet</ulink> article:
	</para>

	  <blockquote><para><indexterm>
		<primary>Privilege Attribute Certificates</primary>
		<see>PAC</see>
	      </indexterm><indexterm>
		<primary>access control</primary>
	      </indexterm>
	The DCE Security Services are also layered on the Kerberos protocol. DCE authentication services use RPC 
	representation of Kerberos protocol messages. In addition, DCE uses the authorization data field in Kerberos 
	tickets to convey Privilege Attribute Certificates (PACs) that define user identity and group membership. 
	The DCE PAC is used in a similar manner as Windows NT Security IDs for user authorization and access control. 
	Windows NT services will not be able to translate DCE PACs into Windows NT user and group identifiers. This 
	is not an issue with Kerberos interoperability, but rather an issue of interoperability between DCE and 
	Windows NT access control information.
	</para></blockquote>

	</sect3>

	</sect2>

</sect1>

<sect1 id="ch10expl">
	<title>Implementation</title>

	<para>
	The following procedures outline the implementation of the security measures discussed so far.
	</para>

	<sect2>
	<title>Share Access Controls</title>

	<para><indexterm>
	    <primary>Share Access Controls</primary>
	  </indexterm><indexterm>
	    <primary>filter</primary>
	  </indexterm><indexterm>
	    <primary>connection</primary>
	  </indexterm>
	Access control entries placed on the share itself act as a filter at the time a when CIFS/SMB client (such as
	Windows XP Pro) attempts to make a connection to the Samba server.
	</para>

	<procedure>
	<title>Create/Edit/Delete Share ACLs</title>
	  <step><para><indexterm>
		<primary>Domain Administrator</primary>
	      </indexterm><indexterm>
		<primary>account</primary>
	      </indexterm>
		From a Windows 200x/XP Professional workstation, log on to the domain using the Domain Administrator 
		account (on Samba domains, this is usually the account called <constant>root</constant>).
		</para></step>

		<step><para>
		Click 
		<menuchoice>
			<guimenu>Start</guimenu>
			<guimenuitem>Settings</guimenuitem>
			<guimenuitem>Control Panel</guimenuitem>
			<guimenuitem>Administrative Tools</guimenuitem>
			<guimenuitem>Computer Management</guimenuitem>
		</menuchoice>.
		</para></step>

		<step><para>
		In the left panel,
		<menuchoice>
			<guimenu>[Right mouse menu item] Computer Management (Local)</guimenu>
			<guimenuitem>Connect to another computer ...</guimenuitem>
			<guimenuitem>Browse...</guimenuitem>
			<guimenuitem>Advanced</guimenuitem>
			<guimenuitem>Find Now</guimenuitem>
		</menuchoice>. In the lower panel, click on the name of the server you wish to
		administer. Click <menuchoice>
				<guimenu>OK</guimenu>
				<guimenuitem>OK</guimenuitem>
				<guimenuitem>OK</guimenuitem>
	      </menuchoice>.<indexterm>
		<primary>Computer Management</primary>
	      </indexterm>
		In the left panel, the entry <guimenu>Computer Management (Local)</guimenu> should now reflect
		the change made. For example, if the server you are administering is called <constant>FRODO</constant>,
		the Computer Management entry should now say <guimenu>Computer Management (FRODO)</guimenu>.
		</para></step>

		<step><para>
		In the left panel, click <menuchoice>
			<guimenu>Computer Management (FRODO)</guimenu>
			<guimenuitem>[+] Shared Folders</guimenuitem>
			<guimenuitem>Shares</guimenuitem>
		</menuchoice>.
		</para></step>

	  <step><para><indexterm>
		<primary>ACLs</primary>
	      </indexterm><indexterm>
		<primary>Share Permissions</primary>
	      </indexterm>
		In the right panel, double-click on the share on which you wish to set/edit ACLs. This
		will bring up the Properties panel. Click the <guimenu>Share Permissions</guimenu> tab.
		</para></step>

	  <step><para><indexterm>
		<primary>access control settings</primary>
	      </indexterm><indexterm>
		<primary>Everyone</primary>
	      </indexterm><indexterm>
		<primary>full control</primary>
	      </indexterm><indexterm>
		<primary>over-rule</primary>
	      </indexterm><indexterm>
		<primary>permissions</primary>
	      </indexterm><indexterm>
		<primary>rejected</primary>
	      </indexterm>
		You may now edit/add/remove access control settings. Be very careful. Many problems have been
		created by people who decided that everyone should be rejected but one particular group should
		have full control. This is a catch-22 situation because members of that particular group also
		belong to the group <constant>Everyone</constant>, which therefore overrules any permissions
		set for the permitted group.
		</para></step>

		<step><para>
		When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu>
		buttons.
		</para></step>
	</procedure>

	</sect2>

	<sect2>
	<title>Share Definition Controls</title>

	<para><indexterm>
	    <primary>Share Definition</primary>
	    <secondary>Controls</secondary>
	  </indexterm><indexterm>
	    <primary>check-point</primary>
	  </indexterm><indexterm>
	    <primary>pile-driver</primary>
	  </indexterm><indexterm>
	    <primary>credential</primary>
	  </indexterm><indexterm>
	    <primary>powers</primary>
	  </indexterm><indexterm>
	    <primary>privileges</primary>
	  </indexterm>
	Share-definition-based access controls can be used like a checkpoint or like a pile-driver. Just as a
	checkpoint can be used to require someone who wants to get through to meet certain requirements, so
	it is possible to require the user (or group the user belongs to) to meet specified credential-related 
	objectives. It can be likened to a pile-driver by overriding default controls in that having met the 
	credential-related objectives, the user can be granted powers and privileges that would not normally be 
	available under default settings.
	</para>

	<para><indexterm>
	    <primary>access controls</primary>
	  </indexterm><indexterm>
	    <primary>ACLs</primary>
	  </indexterm><indexterm>
	    <primary>share definition controls</primary>
	  </indexterm><indexterm>
	    <primary>hierarchy of control</primary>
	  </indexterm>
	It must be emphasized that the controls discussed here can act as a filter or give rights of passage
	that act as a superstructure over normal directory and file access controls. However, share-level
	ACLs act at a higher level than do share definition controls because the user must filter through the
	share-level controls to get to the share-definition controls. The proper hierarchy of controls implemented
	by Samba and Windows networking consists of:
	</para>

	<orderedlist>
		<listitem><para>Share-level ACLs</para></listitem>
		<listitem><para>Share-definition controls</para></listitem>
		<listitem><para>Directory and file permissions</para></listitem>
		<listitem><para>Directory and file POSIX ACLs</para></listitem>
	</orderedlist>

	<sect3>
	<title>Checkpoint Controls</title>

	  <para><indexterm>
	      <primary>Checkpoint Controls</primary>
	    </indexterm>
	Consider the following extract from a &smb.conf; file defining the share called <constant>Apps</constant>:
<screen>
[Apps]
	comment = Application Share
	path = /data/apps
	read only = Yes
	valid users = @Employees
</screen>
	This definition permits only those who are members of the group called <constant>Employees</constant> to 
	access the share.
	</para>

	  <note><para><indexterm>
		<primary>Domain Member</primary>
		<secondary>servers</secondary>
	      </indexterm><indexterm>
		<primary>winbind use default domain</primary>
	      </indexterm><indexterm>
		<primary>fully qualified</primary>
	      </indexterm><indexterm>
		<primary>valid users</primary>
	      </indexterm><indexterm>
		<primary>delimiter</primary>
	      </indexterm>
	On domain member servers and clients, even when the <parameter>winbind use default domain</parameter> has
	been specified, the use of domain accounts in security controls requires fully qualified domain specification,
	for example, <smbconfoption name="valid users">@"MEGANET\Northern Engineers"</smbconfoption>. 
	Note the necessity to use the double quotes to avoid having the space in the Windows group name interpreted as a
	delimiter. 
	</para></note>

	  <para><indexterm>
	      <primary>ACL</primary>
	    </indexterm><indexterm>
	      <primary>access</primary>
	    </indexterm><indexterm>
	      <primary>validate</primary>
	    </indexterm>
	If there is an ACL on the share itself to permit read/write access for all <constant>Employees</constant>
	as well as read/write for the group <constant>Doctors</constant>, both groups are permitted through
	to the share. However, at the moment an attempt is made to set up a connection to the share, a member of
	the group <constant>Doctors</constant>, who is not also a member of the group <constant>Employees</constant>,
	would immediately fail to validate.
	</para>

	  <para><indexterm>
	      <primary>share definition controls</primary>
	    </indexterm>
	Consider another example. In this case, you want to permit all members of the group <constant>Employees</constant>
	except the user <constant>patrickj</constant> to access the <constant>Apps</constant> share. This can be
	easily achieved by setting a share-level ACL permitting only <constant>Employees</constant> to access the share,
	and then in the share definition controls excluding just <constant>patrickj</constant>. Here is how that might
	be done:
<screen>
[Apps]
        comment = Application Share
        path = /data/apps
        read only = Yes
        invalid users = patrickj
</screen>
	    <indexterm>
	      <primary>permissions</primary>
	    </indexterm>
	Let us assume that you want to permit the user <constant>gbshaw</constant> to manage any file in the
	UNIX/Linux file system directory <filename>/data/apps</filename>, but you do not want to grant any write
	permissions beyond that directory tree. Here is one way this can be done:
<screen>
[Apps]
        comment = Application Share
        path = /data/apps
        read only = Yes
        invalid users = patrickj
        admin users = gbshaw
</screen>
	    <indexterm>
	      <primary>administrative rights</primary>
	    </indexterm>
	Now we have a set of controls that permits only <constant>Employees</constant> who are also members of
	the group <constant>Doctors</constant>, excluding the user <constant>patrickj</constant>, to have 
	read-only privilege, but the user <constant>gbshaw</constant> is granted administrative rights.
	The administrative rights conferred upon the user <constant>gbshaw</constant> permit operation as
	if that user has logged in as the user <constant>root</constant> on the UNIX/Linux system and thus,
	for access to the directory tree that has been shared (exported), permit the user to override controls
	that apply to all other users on that resource.
	</para>

	<para>
	There are additional checkpoint controls that may be used. For example, if for the same share we now
	want to provide the user <constant>peters</constant> with the ability to write to one directory to
	which he has write privilege in the UNIX file system, you can specifically permit that with the
	following settings:
<screen>
[Apps]
        comment = Application Share
        path = /data/apps
        read only = Yes
        invalid users = patrickj
        admin users = gbshaw
        write list = peters
</screen>
	    <indexterm>
	      <primary>check-point controls</primary>
	    </indexterm>
	This is a particularly complex example at this point, but it begins to demonstrate the possibilities.
	You should refer to the online manual page for the &smb.conf; file for more information regarding
	the checkpoint controls that Samba implements.
	</para>

	</sect3>

	<sect3>
	<title>Override Controls</title>

	  <para><indexterm>
	      <primary>over-ride controls</primary>
	    </indexterm>
	Override controls implemented by Samba permit actions like the adoption of a different identity 
	during file system operations, the forced overwriting of normal file and directory permissions,
	and so on. You should refer to the online manual page for the &smb.conf; file for more information regarding
        the override controls that Samba implements.
	</para>

	<para>
	In the following example, you want to create a Windows networking share that any user can access.
	However, you want all read and write operations to be performed as if the user <constant>billc</constant>
	and member of the group <constant>Mentors</constant> read/write the files. Here is one way this
	can be done:
<screen>
[someshare]
	comment = Some Files Everyone May Overwrite
	path = /data/somestuff
	read only = No
	force user = billc
	force group = Mentors
</screen>
	    <indexterm>
	      <primary>forced settings</primary>
	    </indexterm><indexterm>
	      <primary>overheads</primary>
	    </indexterm>
	That is all there is to it. Well, it is almost that simple. The downside of this method is that
	users are logged onto the Windows client as themselves, and then immediately before accessing the
	file, Samba makes system calls to change the effective user and group to the forced settings
	specified, completes the file transaction, and then reverts to the actually logged-on identity.
	This imposes significant overhead on Samba. The alternative way to effectively achieve the same result
	(but with lower system CPU overheads) is described next.
	</para>

	  <para><indexterm>
	      <primary>force user</primary>
	    </indexterm><indexterm>
	      <primary>force group</primary>
	    </indexterm><indexterm>
	      <primary>opportunistic</primary>
	      <secondary>locking</secondary>
	    </indexterm><indexterm>
	      <primary>oplock break</primary>
	    </indexterm><indexterm>
	      <primary>performance degradation</primary>
	    </indexterm>
	The use of the <parameter>force user</parameter> or the <parameter>force group</parameter> may
	also have a severe impact on system (particularly on Windows client) performance. If opportunistic
	locking is enabled on the share (the default), it causes an <constant>oplock break</constant> to be
	sent to the client even if the client has not opened the file. On networks that have high traffic
	density, or on links that are routed to a remote network segment, <constant>oplock breaks</constant>
	can be lost. This results in possible retransmission of the request, or the client may time-out while
	waiting for the file system transaction (read or write) to complete. The result can be a profound
	apparent performance degradation as the client continually attempts to reconnect to overcome the
	effect of the lost <constant>oplock break</constant>, or time-out.
	</para>
	
	</sect3>

	</sect2>

	<sect2>
	<title>Share Point Directory and File Permissions</title>

	<para><indexterm>
	    <primary>security</primary>
	  </indexterm><indexterm>
	    <primary>privilege controls</primary>
	  </indexterm><indexterm>
	    <primary>permission</primary>
	  </indexterm><indexterm>
	    <primary>share definition controls</primary>
	  </indexterm>
	Samba has been designed and implemented so that it respects as far as is feasible the security and
	user privilege controls that are built into the UNIX/Linux operating system. Samba does nothing
	with respect to file system access that violates file system permission settings, unless it is
	explicitly instructed to do otherwise through share definition controls. Given that Samba obeys
	UNIX file system controls, this chapter does not document simple information that can be obtained
	from a basic UNIX training guide. Instead, one common example of a typical problem is used
	to demonstrate the most effective solution referred to in the immediately preceding paragraph.
	</para>

	<para><indexterm>
	    <primary>Microsoft Office</primary>
	  </indexterm><indexterm>
	    <primary>Word</primary>
	  </indexterm><indexterm>
	    <primary>Excel</primary>
	  </indexterm>
	One of the common issues that repeatedly pops up on the Samba mailing lists involves the saving of
	Microsoft Office files (Word and Excel) to a network drive. Here is the typical sequence:
	</para>

	<orderedlist>
		<listitem><para>
		A user opens a Work document from a network drive. The file was owned by user <constant>janetp</constant>
		and <constant>users</constant>, and was set read/write-enabled for everyone.
		</para></listitem>

		<listitem><para>
		File changes and edits are made.
		</para></listitem>

		<listitem><para>
		The file is saved, and MS Word is closed.
		</para></listitem>

		<listitem><para>
		The file is now owned by the user <constant>billc</constant> and group <constant>doctors</constant>,
		and is set read/write by <constant>billc</constant>, read-only by <constant>doctors</constant>, and
		no access by everyone.
		</para></listitem>

		<listitem><para>
		The original owner cannot now access her own file and is <quote>justifiably</quote> upset.
		</para></listitem>
	</orderedlist>

	<para>
	There have been many postings over the years that report the same basic problem. Frequently Samba users
	want to know when this <quote>bug</quote> will be fixed. The fact is, this is not a bug in Samba at all.
	Here is the real sequence of what happens in this case.
	</para>

	<para><indexterm>
	    <primary>MS Word</primary>
	  </indexterm><indexterm>
	    <primary>ownership</primary>
	  </indexterm><indexterm>
	    <primary>permissions</primary>
	  </indexterm>
	When the user saves a file, MS Word creates a new (temporary) file. This file is naturally owned
	by the user who creates the file (<constant>billc</constant>) and has the permissions that follow
	that user's default settings within the operating system (UNIX/Linux). When MS Word has finished writing
	the file to disk, it then renames the new (temporary) file to the name of the old one. MS Word does not
	change the ownership or permissions to what they were on the original file. The file is thus a totally
	new file, and the old one has been deleted in the process.
	</para>

	<para>
	Samba received a request to create a new file, and then to rename the file to a new name. The old file that
	has the same name is now automatically deleted. Samba has no way of knowing that the new file should
	perhaps have the same ownership and permissions as the old file. To Samba, these are entirely independent
	operations.
	</para>

	<para>
	The question is, <quote>How can we solve the problem?</quote>
	</para>

	<para>
	The solution is simple. Use UNIX file system permissions and controls to your advantage. Follow these
	simple steps to create a share in which all files will consistently be owned by the same user and the
	same group:
	</para>


	<procedure>
	<title>Using Directory Permissions to Force File User and Group Ownership</title>
		<step><para>
		Change your share definition so that it matches this pattern:
<screen>
[finance]
        path = /usr/data/finance
        browseable = Yes
        read only = No
</screen>
		</para></step>

	  <step><para><indexterm>
		<primary>permissions</primary>
		<secondary>user</secondary>
	      </indexterm><indexterm>
		<primary>permissions</primary>
		<secondary>group</secondary>
	      </indexterm>
		Set consistent user and group permissions recursively down the directory tree as shown here:
<screen>
&rootprompt; chown -R janetp.users /usr/data/finance
</screen>
		</para></step>

	  <step><para><indexterm>
		<primary>accessible</primary>
	      </indexterm>
		Set the files and directory permissions to be read/write for owner and group, and not accessible
		to others (everyone), using the following command:
<screen>
&rootprompt; chmod ug+rwx,o-rwx /usr/data/finance
</screen>
		</para></step>

	  <step><para><indexterm>
		<primary>SGID</primary>
	      </indexterm>
		Set the SGID (supergroup) bit on all directories from the top down. This means all files 
		can be created with the permissions of the group set on the directory. It means all users 
		who are members of the group <constant>finance</constant> can read and write all files in 
		the directory. The directory is not readable or writable by anyone who is not in the 
		<constant>finance</constant> group. Simply follow this example:
<screen>
&rootprompt; find /usr/data/finance -type d -exec chmod ug+s {}\;
</screen>

		</para></step>

	  <step><para><indexterm>
		<primary>group membership</primary>
	      </indexterm><indexterm>
		<primary>primary group</primary>
	      </indexterm><indexterm>
		<primary>/etc/passwd</primary>
	      </indexterm>
		Make sure all users that must have read/write access to the directory have 
		<constant>finance</constant> group membership as their primary group, 
		for example, the group they belong to in <filename>/etc/passwd</filename>.
		</para></step>
	</procedure>

	</sect2>

	<sect2>
	<title>Managing Windows 200x ACLs</title>

	<para><indexterm>
	    <primary>translate</primary>
	  </indexterm><indexterm>
	    <primary>Windows 2000 ACLs</primary>
	  </indexterm><indexterm>
	    <primary>Posix ACLs</primary>
	  </indexterm><indexterm>
	    <primary>side effects</primary>
	  </indexterm>
	Samba must translate Windows 2000 ACLs to UNIX POSIX ACLs. This has some interesting side effects because
	there is not a one-to-one equivalence between them. The as-close-as-possible ACLs match means
	that some transactions are not possible from MS Windows clients. One of these is to reset the ownership
	of directories and files. If you want to reset ownership, this must be done from a UNIX/Linux login.
	</para>

	<para>
	There are two possible ways to set ACLs on UNIX/Linux file systems from a Windows network workstation,
	either via File Manager or via the Microsoft Management Console (MMC) Computer Management interface.
	</para>

	<sect3>
	<title>Using the MMC Computer Management Interface</title>

	<procedure>
		<step><para>
		From a Windows 200x/XP Professional workstation, log on to the domain using the Domain Administrator 
		account (on Samba domains, this is usually the account called <constant>root</constant>).
		</para></step>

		<step><para>
		Click 
		<menuchoice>
			<guimenu>Start</guimenu>
			<guimenuitem>Settings</guimenuitem>
			<guimenuitem>Control Panel</guimenuitem>
			<guimenuitem>Administrative Tools</guimenuitem>
			<guimenuitem>Computer Management</guimenuitem>
		</menuchoice>.
		</para></step>

		<step><para>
		In the left panel,
		<menuchoice>
			<guimenu>[Right mouse menu item] Computer Management (Local)</guimenu>
			<guimenuitem>Connect to another computer ...</guimenuitem>
			<guimenuitem>Browse...</guimenuitem>
			<guimenuitem>Advanced</guimenuitem>
			<guimenuitem>Find Now</guimenuitem>
		</menuchoice>. In the lower panel, click on the name of the server you wish to
		administer. Click <menuchoice>
				<guimenu>OK</guimenu>
				<guimenuitem>OK</guimenuitem>
				<guimenuitem>OK</guimenuitem>
		</menuchoice>.
		In the left panel, the entry <guimenu>Computer Management (Local)</guimenu> should now reflect
		the change made. For example, if the server you are administering is called <constant>FRODO</constant>,
		the Computer Management entry should now say: <guimenu>Computer Management (FRODO)</guimenu>.
		</para></step>

		<step><para>
		In the left panel, click <menuchoice>
			<guimenu>Computer Management (FRODO)</guimenu>
			<guimenuitem>[+] Shared Folders</guimenuitem>
			<guimenuitem>Shares</guimenuitem>
		</menuchoice>.
		</para></step>

	    <step><para><indexterm>
		  <primary>Security</primary>
		</indexterm><indexterm>
		  <primary>Properties</primary>
		</indexterm><indexterm>
		  <primary>Permissions</primary>
		</indexterm><indexterm>
		  <primary>Samba Domain server</primary>
		</indexterm>
		In the right panel, double-click on the share on which you wish to set/edit ACLs. This
		brings up the Properties panel. Click the <guimenu>Security</guimenu> tab. It is best
		to edit ACLs using the <constant>Advanced</constant> editing features. Click the 
		<guimenu>Advanced</guimenu> button. This opens a panel that has four tabs. Only the 
		functionality under the <constant>Permissions</constant> tab can be utilized with respect 
		to a Samba domain server.
		</para></step>

	    <step><para><indexterm>
		  <primary>access control</primary>
		</indexterm><indexterm>
		  <primary>permitted group</primary>
		</indexterm>
		You may now edit/add/remove access control settings. Be very careful. Many problems have been
		created by people who decided that everyone should be rejected but one particular group should
		have full control. This is a catch-22 situation because members of that particular group also
		belong to the group <constant>Everyone</constant>, which therefore overrules any permissions
		set for the permitted group.
		</para></step>

		<step><para>
		When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu>
		buttons until the last panel closes.
		</para></step>
	</procedure>
	
	</sect3>

	<sect3>
	<title>Using MS Windows Explorer (File Manager)</title>

	<para>
	The following alternative method may be used from a Windows workstation. In this example we work
	with a domain called <constant>MEGANET</constant>, a server called <constant>MASSIVE</constant>, and a
	share called <constant>Apps</constant>. The underlying UNIX/Linux share point for this share is
	<filename>/data/apps</filename>.
	</para>

	<procedure>
		<step><para>
		Click <menuchoice>
			<guimenu>Start</guimenu>
			<guimenuitem>[right-click] My Computer</guimenuitem>
			<guimenuitem>Explore</guimenuitem>
			<guimenuitem>[left panel] [+] My Network Places</guimenuitem>
			<guimenuitem>[+] Entire Network</guimenuitem>
			<guimenuitem>[+] Microsoft Windows Network</guimenuitem>
			<guimenuitem>[+] Meganet</guimenuitem>
			<guimenuitem>[+] Massive</guimenuitem>
			<guimenuitem>[right-click] Apps</guimenuitem>
			<guimenuitem>Properties</guimenuitem>
			<guimenuitem>Security</guimenuitem>
			<guimenuitem>Advanced</guimenuitem>
		</menuchoice>. This opens a panel that has four tabs. Only the functionality under the 
		<constant>Permissions</constant> tab can be utilized for a Samba domain server.
		</para></step>

	    <step><para><indexterm>
		  <primary>full control</primary>
		</indexterm><indexterm>
		  <primary>over-rule</primary>
		</indexterm>
                You may now edit/add/remove access control settings. Be very careful. Many problems have been
                created by people who decided that everyone should be rejected but one particular group should
                have full control. This is a catch-22 situation because members of that particular group also
                belong to the group <constant>Everyone</constant>, which therefore overrules any permissions
                set for the permitted group.
                </para></step>

                <step><para>
                When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu>
                buttons until the last panel closes.
                </para></step>
	</procedure>

	</sect3>

	<sect3>
	<title>Setting Posix ACLs in UNIX/Linux</title>

	  <para><indexterm>
	      <primary>desired security setting</primary>
	    </indexterm><indexterm>
	      <primary>shared resource</primary>
	    </indexterm>
	Yet another alternative method for setting desired security settings on the shared resource files and
	directories can be achieved by logging into UNIX/Linux and setting POSIX ACLs directly using command-line
	tools. Here is an example session on the same resource as in the immediately preceding example on a SUSE 9
	Linux system:
	</para>

	<procedure>
		<step><para>
		Log into the Linux system as the user <constant>root</constant>.
		</para></step>

		<step><para>
		Change directory to the location of the exported (shared) Windows file share (Apps), which is in
		the directory <filename>/data</filename>. Execute the following:
<screen>
&rootprompt; cd /data
</screen>
		Retrieve the existing POSIX ACLs entry by executing:
<screen>
&rootprompt; getfacl apps
# file: apps
# owner: root
# group: root
user::rwx
group::rwx
other::r-x
</screen>
		</para></step>

	    <step><para><indexterm>
		  <primary>recursively</primary>
		</indexterm>
		You want to add permission for <constant>AppsMgrs</constant> to enable them to
		manage the applications (apps) share. It is important to set the ACL recursively
		so that the AppsMgrs have this capability throughout the directory tree that is 
		being shared. This is done using the <constant>-R</constant> option as shown.
		Execute the following:
<screen>
&rootprompt; setfacl -m -R group:AppsMgrs:rwx /data/apps
</screen>
		Because setting an ACL does not provide a response, you immediately validate the command executed
		as follows:
<screen>
&rootprompt; getfacl /data/apps
# file: apps
# owner: root
# group: root
user::rwx
group::rwx
group:AppsMgrs:rwx
mask::rwx
other::r-x
</screen>
		This confirms that the change of POSIX ACL permissions has been effective.
		</para></step>

	    <step><para><indexterm>
		  <primary>setfacl</primary>
		</indexterm><indexterm>
		  <primary>getfacl</primary>
		</indexterm><indexterm>
		  <primary>directory tree</primary>
		</indexterm><indexterm>
		  <primary>Windows ACLs</primary>
		</indexterm><indexterm>
		  <primary>inheritance</primary>
		</indexterm>
		It is highly recommended that you read the online manual page for the <command>setfacl</command>
		and <command>getfacl</command> commands. This provides information regarding how to set/read the default
		ACLs and how that may be propagated through the directory tree. In Windows ACLs terms, this is the equivalent
		of setting <constant>inheritance</constant> properties.
		</para></step>
	</procedure>

	</sect3>

	</sect2>

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

		<para>
		The mish-mash of issues were thrown together into one chapter because it seemed like a good idea.
		Looking back, this chapter could be broken into two, but it's too late now. It has been done.
		The highlights covered are as follows:
		</para>

		<itemizedlist>
	  <listitem><para><indexterm>
		<primary>Winbind</primary>
	      </indexterm><indexterm>
		<primary>Active Directory</primary>
	      </indexterm><indexterm>
		<primary>password change</primary>
	      </indexterm><indexterm>
		<primary>logon hours</primary>
	      </indexterm>
			Winbind honors and does not override account controls set in Active Directory.
			This means that password change, logon hours, and so on, are (or soon will be) enforced
			by Samba winbind. At this time, an out-of-hours login is denied and password
			change is enforced. At this time, if logon hours expire, the user is not forcibly
			logged off. That may be implemented at some later date.
			</para></listitem>

	  <listitem><para><indexterm>
		<primary>Sign'n'seal</primary>
	      </indexterm><indexterm>
		<primary>schannel</primary>
	      </indexterm>
			Sign'n'seal (plus schannel support) has been implemented in Samba-3. Beware of potential
			problems acknowledged by Microsoft as having been fixed but reported by some as still
			possibly an open issue.
			</para></listitem>

	  <listitem><para><indexterm>
		<primary>Kerberos</primary>
	      </indexterm><indexterm>
		<primary>OpenLDAP</primary>
	      </indexterm><indexterm>
		<primary>Active Directory</primary>
	      </indexterm><indexterm>
		<primary>inter-operability</primary>
	      </indexterm>
			The combination of Kerberos 5, plus OpenLDAP, plus Samba, cannot replace Microsoft
			Active Directory. The possibility to do this is not planned in the current Samba-3
			roadmap. Samba-3 does aim to provide further improvements in interoperability so that
			UNIX/Linux systems may be fully integrated into Active Directory domains.
			</para></listitem>

			<listitem><para>
			This chapter reviewed mechanisms by which Samba servers may be kept secure. Each of
			the four key methodologies was reviewed with specific reference to example deployment
			techniques.
			</para></listitem>
		</itemizedlist>

	</sect2>

</sect1>

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

	<para>
	</para>

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

	    <para><indexterm>
		<primary>Sign'n'seal</primary>
	      </indexterm><indexterm>
		<primary>registry hacks</primary>
	      </indexterm>
		Does Samba-3 require the <constant>Sign'n'seal</constant> registry hacks needed by Samba-2?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>schannel</primary>
	      </indexterm><indexterm>
		<primary>Sign'n'seal</primary>
	      </indexterm><indexterm>
		<primary>registry change</primary>
	      </indexterm>
		No. Samba-3 fully supports <constant>Sign'n'seal</constant> as well as <constant>schannel</constant>
		operation. The registry change should not be applied when Samba-3 is used as a domain controller.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		Does Samba-3 support Active Directory?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>Active Directory</primary>
	      </indexterm>
		Yes. Samba-3 can be a fully participating native mode Active Directory client. Samba-3 does not
		provide Active Directory services. It cannot be used to replace a Microsoft Active Directory
		server implementation. Samba-3 can function as an Active Directory client (workstation) toolkit,
		and it can function as an Active Directory domain member server.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>mixed-mode</primary>
	      </indexterm>
		When Samba-3 is used with Active Directory, is it necessary to run mixed-mode operation, as was
		necessary with Samba-2?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>native</primary>
	      </indexterm>
		No. Samba-3 can be used with NetBIOS over TCP/IP disabled, just as can be done with Windows 200x
		Server and 200x/XPPro client products. It is no longer necessary to run mixed-mode operation,
		because Samba-3 can join a native Windows 2003 Server ADS domain.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>share level access controls</primary>
	      </indexterm>
		Is it safe to set share-level access controls in Samba?
		</para>

	</question>
	<answer>

		<para>
		Yes. Share-level access controls have been supported since early versions of Samba-2. This is
		very mature technology. Not enough sites make use of this powerful capability, neither on
		Windows server or with Samba servers.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>share ACLs</primary>
	      </indexterm>
		Is it mandatory to set share ACLs to get a secure Samba-3 server?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>file system security</primary>
	      </indexterm><indexterm>
		<primary>Windows 200x ACLs</primary>
	      </indexterm><indexterm>
		<primary>share definition controls</primary>
	      </indexterm><indexterm>
		<primary>share level ACL</primary>
	      </indexterm><indexterm>
		<primary>security</primary>
	      </indexterm>
		No. Samba-3 honors UNIX/Linux file system security, supports Windows 200x ACLs, and provides 
		means of securing shares through share definition controls in the &smb.conf; file. The additional
		support for share-level ACLs is like frosting on the cake. It adds to security but is not essential
		to it.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>valid users</primary>
	      </indexterm>
		The <parameter>valid users</parameter> did not work on the <smbconfsection name="[homes]"/>.
		Has this functionality been restored yet?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>meta-service</primary>
	      </indexterm>
		Yes. This was fixed in Samba-3.0.2. The use of this parameter is strongly recommended as a safeguard
		on the <smbconfsection name="[homes]"/> meta-service. The correct way to specify this is:
		<smbconfoption name="valid users">%S</smbconfoption>.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>force user</primary>
	      </indexterm><indexterm>
		<primary>force group</primary>
	      </indexterm><indexterm>
		<primary>bias</primary>
	      </indexterm>
		Is the bias against use of the <parameter>force user</parameter> and <parameter>force group</parameter>
		really warranted?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>performance</primary>
	      </indexterm>
		There is no bias. There is a determination to recommend the right tool for the task at hand.
		After all, it is better than putting users through performance problems, isn't it?
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		The example given for file and directory access control forces all files to be owned by one
		particular user. I do not like that. Is there any way I can see who created the file?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>SUID</primary>
	      </indexterm>
		Sure. You do not have to set the SUID bit on the directory. Simply execute the following command
		to permit file ownership to be retained by the user who created it:
<screen>
&rootprompt; find /usr/data/finance -type d -exec chmod g+s {}\;
</screen>
		Note that this required no more than removing the <constant>u</constant> argument so that the
		SUID bit is not set for the owner.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>Computer Management</primary>
	      </indexterm>
		In the book, <quote>The Official Samba-3 HOWTO and Reference Guide</quote>, you recommended use
		of the Windows NT4 Server Manager (part of the <filename>SRVTOOLS.EXE</filename>) utility. Why
		have you mentioned only the use of the Windows 200x/XP MMC Computer Management utility?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>MMC</primary>
	      </indexterm><indexterm>
		<primary>SRVTOOLS.EXE</primary>
	      </indexterm>
		Either tool can be used with equal effect. There is no benefit of one over the other, except that
		the MMC utility is present on all Windows 200x/XP systems and does not require additional software
		to be downloaded and installed. Note that if you want to manage user and group accounts in your
		Samba-controlled domain, the only tool that permits that is the NT4 Domain User Manager, which
		is provided as part of the <filename>SRVTOOLS.EXE</filename> utility.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>valid users</primary>
	      </indexterm><indexterm>
		<primary>Active Directory</primary>
	      </indexterm><indexterm>
		<primary>Domain Member server</primary>
	      </indexterm>
		I tried to set <parameter>valid users = @Engineers</parameter>, but it does not work. My Samba
		server is an Active Directory domain member server. Has this been fixed now?
		</para>

	</question>
	<answer>

		<para>
		The use of this parameter has always required the full specification of the domain account, for
		example, <parameter>valid users = @"MEGANET2\Domain Admins"</parameter>.
		</para>

	</answer>
	</qandaentry>

	</qandaset>

</sect1>

</chapter>